Running Apps

Open an assigned App from My Apps, your shop-floor workspace or the authorized operational record. App publication, audience/account assignment, current workspace and action permissions determine what is available.

Start the task

1. Check the account, site/environment and workplace.
2. Open the intended published App. If an order or material is required, select or scan its exact identifier.
3. Read the instructions and complete the App's inputs. A successful scan selects or fills data; it does not submit a request or report production.
4. Use the explicit save/report/submit action and inspect its result.
5. Confirm the resulting record, quantity, evidence or workflow state before moving on.

New custom Apps own their layout and navigation. Existing Apps can offer tabs, native controls or Blueprints. The configured interface determines which controls you see. Inputs do not require a separate Form definition.

Understand the controls

Control or result	What to verify
Order or scan selection	Correct record and eligible workplace operation.
Input/checklist/photo	Required values, conditions, upload completion and saved draft state.
Production or stock action	Exact operation, quantity, unit and persisted result.
Table/list/card	Filters, pagination and own-record restrictions. Empty and denied are different.
Automation action	The returned run state; accepted dispatch is not completed processing.
Report or file	Correct subject, revision and readable downloaded artifact.

When offered, the floating view control switches an App between its ordinary presentation and focused window/fullscreen modes. It changes presentation, not the App version or permission. Move it away from important content where needed.

Check completion and recover

A saved input draft, uploaded file, business record and later Automation are separate effects. If the record saved but processing failed, keep the record and retry only processing. Do not submit another record to repair a later action.

Use the App's saved-state indicator. A resumable draft is available only when the App implements it. Browser reads, saves and uploads need connectivity; there is no general offline submission queue. Keep the original pending request and unchanged inputs after a lost response, inspect its status and use Check or retry or the offered recovery. Start a new request only for a distinct intended submission.

For a conflict, preserve your values, load the current record and compare before saving again. New publication can refresh the runtime; if the new version cannot load, reopen it and contact the owner rather than continuing under an obsolete version.

Resolve common problems

Symptom	First checks
App missing	Correct scope, publication, audience, account and device assignment.
No order	Exact identifier, filters, workplace assignment and lifecycle eligibility.
Action denied	Required input, published App capabilities and current domain permission.
No table rows	Scope, filters, own-record setting and actual saved result.
Workflow pending or uncertain	Existing request/run and saved effects before retrying.
Camera/audio unavailable	Device permissions, actual hardware and enabled App inputs.
A historical Form link cannot capture	New capture is retired; use the current App workflow. Authorized historical reports remain separate.

Report App name, publication, scope, record and request/run ID to support. See device prerequisites and data-entry recovery.