Material requests

This example lets a worker request material and a team review the saved requests. It collects information; it does not reserve stock, create a purchase order or move inventory.

This walkthrough is a Table-backed starter example for an existing material-request Table. For a new shared request queue, use a Model: define the inputs in the App and, when rules govern creation, bind the Model's create action and call it on submission. Existing Tables and the Apps that use them remain supported. The Data entry and Konnie-assisted data entry starters still submit to a Table.

Prepare the existing Table

In Operations Studio → Tables, select the existing material-request Table. A minimal schema matching the data-entry starter is:

Key	Type	Required
material_number	Text	Yes
quantity	Number	Yes
notes	Long text	No

Add team-maintained status, priority or other columns only when the workflow needs them. Use real schema keys and configured choices. Saving a Table and publishing an App are separate actions.

Build the requester App

Ask Konnie:

Build a material-request App using this Table. Ask for material number and a positive quantity, with optional notes. Save directly to the Table. Keep my draft when I reload, show whether it is saved, and let me check or retry an unconfirmed request without creating duplicates. Use English and German copy and a compact tablet layout.

Konnie can start from Data entry ordinary React source, connect the actual Table under a named source such as requests, and adapt its exact keys. No separate Form, Form publication or submission Automation is needed. The App owns its questions and validation. General requests do not require an order or work center.

Review the App's connection permissions and own-record filtering. A requester should receive only the access needed for requesting and, if offered, viewing their own requests.

Give the team a queue

Use the same Table in a team App with the permitted reads and edits. Show useful information, allow the team to update the agreed handling fields and preserve concurrent changes. If requesters and handlers have different rights, use separately assigned Apps; tabs do not separate permissions.

Add an optional manual Automation only for a separately required process. Keep the saved row ID and actual processing state. A failed later process is retried without submitting the request again.

Test the real task

1. Confirm the exact Table schema and named App connection.
2. Try empty input, a zero/negative quantity and a normal request.
3. Enter values, wait for Draft saved, reload and continue.
4. Submit once and confirm one row in the team queue.
5. Simulate a lost response and use Check or retry request. The same pending identity must resolve to the same accepted request.
6. Test German/English copy, a narrow screen and the intended requester/team accounts.
7. Publish the reviewed App separately and repeat the main task as its intended user.

An accepted request is information received, not a physical replenishment confirmation. See Data entry in Apps, App data sources and Collecting data with Apps.