Your first data collection App

Build a small material-request screen backed by a Custom Table. Submit one fictional request, reopen it, and inspect the saved row. You need a Test workspace, Table creation/schema access, App authoring/publication access and permission to run the published App. Allow about 20 minutes.

This tutorial practices the Table-backed starter path in a Test workspace. For a new shared record type in your operation, use a Model and bind its create action when rules govern creation; existing Tables and their Apps remain supported.

Define the stored record

In Operations Studio → Tables, create Documentation requests with these columns. Keep the keys exactly as written:

Key	Label	Type	Required	Default / choices
material_number	Material number	Text	Yes	None
quantity	Quantity	Number	Yes	None
notes	Notes	Long text	No	None
status	Status	Dropdown	Yes	Default open; choices open, done

Choose Save table, reopen the schema and check the keys and default. The Table has no separate publication step. A material number here is text: the request does not reserve inventory or create production.

Connect and build the App

1. Create an App named Documentation material request. In Data, choose Connect table, select Documentation requests, and set the connection name to requests before connecting it. Confirm the generated logical ID shown under the connection name is requests.

2. Enable Read and Create. Keep own-record filtering on. Leave update/delete disabled for this requester App.

3. Ask Konnie in the App's authoring context:

   Build a compact React material-request screen using the existing requests data source. Collect required material_number text, positive quantity and optional notes. Create a row with status: "open" using the current Table version. Use an explicit button, retain input after errors and preserve one invocation ID and unchanged values for a lost-response retry. Show the created record ID and a list of my saved requests. Provide English and German labels. Save a draft; I will publish it after review.

4. Inspect the saved source and preview. Field names must match the Table keys. Keep workflow status out of the operator inputs. A separate Form definition or Automation is unnecessary for this direct save.

5. Verify the App has not acquired update/delete access merely because a generated screen includes such controls. Review errors instead of treating a failed query as an empty list.

Code authors can use the complete data-source examples. The data-entry starter provides a starting point for the interface and draft recovery.

Run the acceptance example

1. Preview with material_number DOCS-PLATE, quantity 3, and notes Fictional documentation request.
2. Try a blank material number and quantity 0 first. Expect validation with no created row. Correct them and click the explicit save/request button once.
3. Expect a successful result with a record ID. Open the App's saved-request list and verify one row containing those values and status open.
4. Reopen the App and confirm the row remains. A successful compilation or preview alone does not establish a saved record.
5. Switch English/German and inspect labels, validation and the narrow layout. With a separate authorized test user, check that this own-record App does not show the first user's row.

Publish and hand over

Save the reviewed draft, publish it and assign its audience. Open the published App through My Apps as the intended user and submit a distinct request with notes Published App check. Expect one additional row with a new ID. Keep preview and published test records distinct.

For an office team queue, create a separate App with the appropriate audience, read/update access and permitted shared-record policy. Do not grant broader rights through a tab label. Shop-floor accounts remain restricted to their own records.

Recover without duplicates

Situation	Expected handling
Validation fails	Retain input, explain the field, create no row.
Permission denied	Check source operations, current user access and App audience.
Response is lost	Use Check or retry for the same pending invocation and unchanged input.
Row saved but follow-up failed	Preserve the row; retry only the follow-up process.
Table schema changed	Reload the current schema, compare fields and review the pending input before retrying.

A Table row records a request. If the business process later requires stock issue or order creation, add the supported operational action with its own authorization and result. See Material requests and Custom App operations.