Building Apps
Create Apps in Operations Studio → Apps. App design, publication and assignment are separate permissions in the selected site/environment. A new custom App owns its React interface, navigation, questions, conditions and action timing. Konnie or an external agent can edit that ordinary source; useful customer choices can be exposed as App settings.
Define the job and audience
Write the intended task and saved result before designing the screen. For example: “An operator requests a material and sees the confirmed request; the office updates its handling status.” Choose the destination: a Table, contextual evidence or a canonical domain action. A Table write does not reserve stock or report production.
Decide whether the audience is an office user or shop-floor account and which workplace applies. App audience, account assignment, published capabilities and resource restrictions all matter. An office preview does not prove shop-floor access. Station views should use the native production-station/customer-order fulfillment capability without granting commercial customer-order access merely to show an operator queue.
Create the draft
- Open Apps and choose the create action or an available source starter.
- Give it a task-focused name, such as “Material requests”.
- Ask Konnie for the complete interface and name the exact existing Table, workplace or other destination. Alternatively edit the source directly.
- Open the generated settings and expose only useful operational configuration. Inputs, validation and layout remain ordinary source.
- Connect named data sources, optional Automation actions and the required domain capabilities.
- Save and inspect the actual saved draft. Publication is a separate action.
A source starter creates independently editable source. Review every identifier, connection and default for your workspace. Existing component-based Apps and Blueprints can remain editable through their existing layout/configuration controls; their compatibility does not require a new React App to embed those business components. There is no separate Form editor or required Form publication for new input flows.
Design a usable screen
Keep the first useful action visible. For a station, combine the selected work, instructions, essential specifications and reporting action. Use a short position row with quantity and status; expand details when needed. Keep secondary notes optional. Avoid repeating the same identifier, dimensions and status in several sections.
Use responsive React layouts, readable text, clear labels and reachable touch controls. Preserve selection and unsent input while data refreshes. Use the existing SDK for saved records, media/evidence and operational actions; presentation does not bypass native quantities, permissions or concurrent-change rules.
For data entry, save private working drafts when the task is long. Show Saving, Saved, Not saved, error and conflict states accurately. Keep the same pending invocation and inputs after a lost response. Native browser form submission is blocked in the App sandbox; SDK writes use explicit buttons. See Data entry in Apps.
Preview the complete task
Check both languages and desktop/narrow layouts. Exercise:
- Loading, a genuinely empty result and a denied/failed read as different states.
- Required inputs, conditional questions, keyboard/touch controls and long text.
- Saving, reopening a draft, conflict and lost-response recovery.
- One controlled action and the actual destination record after reloading.
- Intended operator access and a separate denied account.
A preview action can write real data. Use an agreed test scope and fictional records. Record the App publication, workplace, account type and what actually passed. Compilation checks source validity; it does not establish an accepted business result.
Publish and assign
Wait for saving to complete, choose Publish, review requested capabilities and add a useful release note. Where authorized, assign the intended shop-floor accounts. Inspect audience and assignment separately.
Open the published App as its intended user and repeat the main task. New publications can refresh a running App; preserve ongoing work before disruptive changes. If publication fails, inspect validation and dependencies. Use History to restore earlier content into a draft, review and publish it separately. See Publishing and governance.