Custom Tables
Existing Custom Tables and the Apps that use them remain supported. Use a Model for a new record type.
| Need | Use |
|---|---|
| New shared record type | Model. Use writes: "actions" when state changes follow rules. |
| Extra attribute or link on an existing Ennea record | Custom field or relationship extension |
| Observation, photo or measurement attached to production work | App evidence |
| Existing Custom Table and its Apps | Keep the Custom Table |
Define inputs in the App and bind the Model's create action when rules govern creation.
A Custom Table stores structured operational records for tasks such as requests, measurements and handovers. Manage its schema in Operations Studio → Tables and connect records to App-owned interfaces. Existing component-based Apps can retain Custom Table views. Studio's record preview is read-only.
Apps can also connect a table as an App data source. This supports direct record creation, reading, filtering, summaries, editing and deletion through native data views or custom Blueprint interfaces. Choose the operations and ownership policy on the App connection; a visible Custom Table component or a Form submission is not required for this path.
Create the schema
- Open Tables and select your Table. If you need to create a Table, give it a clear name and purpose.
- Add columns with a stable key, label and type.
- Set required flags and choice values only where the task needs them.
- Configure available defaults, then order the columns for readability.
- Choose Save table and reopen it to verify the saved schema.
| Type | Stores |
|---|---|
| Text / Long text | Short identifiers or longer comments. |
| Number | A numeric quantity or measurement. |
| Checkbox | A boolean result. |
| Date / Date and time / Time | A typed date, timestamp or time value. |
| Dropdown / Multiple choices | One or several configured choices. |
| Email / URL | A validated contact address or link. |
| Record identifier | An opaque identifier such as a Material number. |
Record identifier does not perform an entity lookup or grant access to the referenced record. Multimedia columns are not available; use authorized evidence/file APIs for media.
Collect records
Connect this Table as a named App data source. Ordinary React inputs write directly through the connection, using exact column keys and typed values. The App owns its questions, conditions and validation; no separate Form or mandatory Automation is needed. Several Apps can share the same Table with their own presentation and authorized operations.
Use private resumable drafts and stable request identities for uncertain submissions. Add a manual Automation only when a separate process is required. See Collecting data with Apps and App data sources.
Configure an App view
Add a Custom Table component, select the Table and configure:
- Show only my reports for a personal view.
- Allow editing records and deletion only for the intended processing audience.
- Filter tabs for useful queues, such as New, In progress and Done.
Filter rules support typed equality, empty-value checks, literal text matches and numeric/date/time comparisons. Combine rules with AND/OR. Multiple-choice equality tests option membership. Configure at most 20 tabs and 20 rules per tab. Selecting a different Table clears schema-dependent filter rules.
The published component defines the permitted filters and actions. Filter counts and matching records are calculated before pagination. The search box filters the currently loaded page of 50 records, so use configured filter tabs when you need a complete queue.
Personal and team access
An office view can show the team's records when its audience/access permits it. Shop-floor accounts are always restricted to their own records by the server, including when Show only my reports is off. App tabs share an App audience; a “Team queue” tab name does not restrict it to a different role.
Editing permits the row's configured values, rather than only its Status. Use separate requester and office Apps when requesters should submit/view their own records and only the office should edit the queue. Publish and verify each App's audience with separate allowed/denied accounts.
Work with records and refresh
Visible table views refresh every three seconds and immediately after local mutations. Allow the next visible refresh when checking another device. Edit a record, save and reload it to confirm the stored result.
Schema and record changes use version checks. If another editor saved first, reload the current record, compare and reapply the intended change. New optional columns, label/order changes and compatible choice additions can be allowed; incompatible key/type/required changes are rejected when records would no longer satisfy the schema.
Deletion removes the operational row, subject to applicable processing restrictions. Deleting the Table also affects its associated records and requires explicit confirmation. A retry of an earlier submission cannot restore a deleted result. Start a new submission only when another record is intended.
Troubleshoot
| Problem | Check |
|---|---|
| Table absent in a selector | Site/environment, saved schema and your access. |
| Required mapping rejected | Explicit field/fixed value and source/destination types. |
| Unexpected empty view | Table selection, filter tab, ownership and submission action result. |
| Another device shows old values | Visible refresh, connection and current scope. |
| Schema change rejected | Existing records and compatibility of the proposed columns. |
| Need a relationship in Nexus | Custom Tables currently have no direct Table/record relationship view there. Use the App's authorized view. |
Use Material requests for an example with separate requester and office access.