Collecting data with Apps
Build the input screen in the App and connect it to the result that people need. A material-request App can create a Model record. An inspection App can save evidence on its selected order.
1. Define the stored result
For a new shared queue, use a Model for its records, such as material requests or shift handovers. For an existing Table queue, keep the Custom Table and give any added columns stable keys and suitable types. Show team-maintained values such as status on the operator's input screen only when the operator needs to choose them.
Save checks, notes and photos about an existing authorized object as evidence on that object. Use the operational APIs for native stock, production and maintenance changes.
2. Create the App
Ask Konnie to build a React App for the task, or author it directly. Connect the Model and bind its create action when rules govern creation. For an existing Table, connect it as a named App data source. The connection determines the permitted operations and which records the App can access.
The Data entry starter demonstrates direct submission to a Table with a material number, positive quantity and optional notes. It includes editable inputs, saved working drafts and submission recovery. If you use it with an existing Table, adapt its controls and column keys to that Table.
3. Build the complete user task
Use a compact input screen with clear labels, meaningful validation, keyboard support and reachable touch controls. Add a team queue or personal history only when useful. Separate requester and team Apps when their rights differ: tabs do not have separate access policies.
The App owns its conditions, calculations, required answers and action timing. Optional configuration uses normal App settings. Save draft input privately for the signed-in person and display its real save status. Do not put answers into shared App settings.
4. Add separate processing when needed
If the task needs a separate reusable process, connect an active manual Automation through a named App automation action. Show its actual run state.
Saving and starting processing are two operations. If saving succeeds and processing fails, keep the saved record and retry processing only. Never create the record again to recover a later action. A Table row alone does not reserve stock, create an order or approve a quality result.
5. Verify and publish
Check the saved Model or Table schema and its App connection, both languages, required and conditional inputs, intended account access and a narrow viewport. Reopen a saved draft. Test a controlled online submission and confirm one stored record. After a lost response, retry the same request.
Save and preview the App draft, then publish it separately. Compilation, saved configuration, published App, accepted submission and completed processing are distinct states. See the material-request example and Data entry in Apps.