Apps overview
An App brings the information and actions for one job into a working interface. Operators can select an order, follow instructions, complete an inspection, report progress or submit a request without moving between several administration screens.
Apps use the same operational records and permissions as the rest of Ennea. A button that reports production changes the actual order; a request interface saves the request to its connected destination. Choose the intended outcome and storage target before designing the interface.
Find the right starting point
| You want to… | Start here |
|---|---|
| Use an existing interface | Running Apps |
| Design or change an interface | Building Apps |
| Collect structured information for a team queue | Collecting data with Apps |
| Create a request and track its processing | Material requests |
| Report issues and execute maintenance work | Maintenance |
| Calculate and display operational metrics | Dashboards and widgets |
| Run a process after an event or button press | Automations |
| Issue a document from operational information | Working with reports |
How the pieces fit
A custom App is an ordinary React interface. Its source owns the layout, inputs, validation, conditions and action timing. Konnie, an external agent or a developer can create and change that source. The App can display orders, work instructions, Table records and charts, and call the authorized operational APIs needed for its task.
Connections and reusable definitions are maintained in Operations Studio. A Table defines stored columns, an Automation defines processing steps and a document template defines an output layout. Questions and collection rules belong to the App's source. Publishing the App does not publish an unpublished dependency or activate an inactive Automation.
For example, a replenishment App can scan a material identifier, collect a quantity and note, and save the request directly to a connected Table. It can show the current user's requests and processing status. A second App can give the office authorized status editing over the same Table. Add an Automation when the workflow needs further processing.
Konnie can help operate a connected App from the regular chat or drawer. An App can also offer its own text, recorded-voice and attachment controls. The App defines its available actions and decides when to submit; its published configuration and the current account's permissions govern access.
Understand access and versions
An author edits a draft. Publish creates the version operators can run. Further draft changes remain separate until the next publication. History lets authors inspect earlier versions and restore content for a new publication.
App access, shop-floor account assignment and permission to perform an operational action are separate controls. An App may be visible while a particular action is unavailable. A restricted App should be tested with its intended operator account, including a separate account that should have no access.
Before changing an App already in use, review its dependencies and test representative records in the intended site and environment. Use publishing and governance to distinguish saving, publication, activation and environment promotion.
A practical design rule
Give each App a clear job and an observable result. For a production station, keep order selection, instructions and production reporting together. For a request workflow, make submission and processing status easy to see. Use a separate App when another audience needs different records or editing authority.
Start with ordinary App source and connect the records and actions the task needs. See App source and libraries for source guidance and data entry in Apps for drafts and submission recovery. Check the published App on the devices people actually use before assigning it broadly.