Configuring Blueprints

Ask Konnie to expose the useful choices in a custom view as editable settings. For example: “Create a machine view with a configurable heading, filter height, and status display. Provide English and German labels.” Konnie generates the view, its controls, and working defaults together.

Select the Blueprint in the App editor and open Configuration. Under Blueprint settings, change the values you need. The preview updates and the normal draft save stores them. Different placements keep independent values, even when their code and defaults are identical.

Text, number, checkbox, switch, dropdown, radio, and multiple-selection controls are supported. Settings may be grouped. Konnie selects controls appropriate to the view and gives each setting a valid default. A Blueprint without generated settings continues to work as before.

Using default means the placement has no custom value. Custom value means the placement has its own override. Use Reset beside a setting to restore its default, or Reset all settings to restore every default. Resetting a setting does not rewrite the Blueprint code.

If an input is invalid, its message explains the problem and the saved setting stays unchanged. Correct the value or press Escape to discard the unfinished input. Code-only changes preserve custom values. A changed definition must remain compatible with those values; incompatible changes are rejected.

Preview and publish through the normal App workflow. Published versions keep the code, settings definition, and placement values together. Editing the next draft does not change the current published App.

Edit settings definition is an advanced JSON editor. Konnie normally creates this definition; everyday configuration requires no code or JSON editing.

When a technical check cannot finish

Konnie checks generated code before saving it. If the compiler times out, it automatically retries the same proposed change once. A temporary compiler failure keeps the last saved draft intact and is shown separately from an error in the code. If recovery still fails, Konnie keeps the proposed change in the conversation and explains that it has not been saved. A successful check and save still require reviewing the actual preview and its interactions.

Combine records and workflows

A Blueprint can be a complete working interface over persistent App data: a request form beside a queue, a selected record with editing controls, or a chart with workflow buttons. It does not need a visible table component to access connected records.

Ask Konnie to discover the actual table schema and automation in the selected site and environment, then connect both to the App. For example: “Build a request workspace using our Requests table. Show open requests as cards, let users create and edit their own requests, and start the active Review request workflow from a separate button for the selected record. Keep the entered values on failure and show the workflow's progress. Provide English and German text.” Use names from your workspace; Konnie must resolve the real IDs and column keys before generating the interface.

The App's Data connections enable the required read/create/update/delete operations and ownership policy. Its Automations connections define stable workflow action IDs. The Blueprint uses ennea.dataSources and ennea.automations with those logical IDs; the platform resolves the table and workflow from the App configuration. Connecting a workflow or reading a record does not start it. See App data sources and Automations in Apps for the SDK contracts and recovery behavior.

Konnie's JSX editor receives the current named connections, authorized table schemas and actual workflow input paths. These connection details exclude record values, table defaults and configured workflow literals. Input paths identify workflow references; they do not declare required fields or types. Unavailable or omitted context means Konnie must explain the missing setup rather than guess a schema or input mapping. Large connection sets can omit details to keep the authoring context bounded.

Creating a record and starting a workflow are separate operations. Show their results separately. If the record was saved and the workflow response is uncertain, retain the saved record and retry only that workflow with its original invocation key and unchanged input. Do not create another record or a new workflow intent to hide a partial result. A returned run can still be running, waiting or awaiting approval; show completion only when its receipt confirms it.

Review the generated draft, its connections and requested capabilities before publication. Test record access and edits with agreed test data; connected automations execute only from a published App. Verify the published interface as the intended user, including unavailable access, duplicate clicks, concurrent edits, a lost response and reload. Authoring, staging and compiling do not establish publication or a successful operational result.

Customer orders and position reporting

A station Blueprint can read native customer fulfillment with data.query('customerOrders', {workCenterId, scope: 'planned', skip: 0, limit: 25}) or ennea.customerOrders.list(...). Check ok, then use data.customerOrders, totalCount, and hasMore; advance skip by the returned limit for each page. The maximum page size is 50. The read requires customer-order and production-order read access in the selected site and environment.

Each header contains stable lines; each line contains its linked root productionOrders, including every operation and execution split. Keep positions and their units separate. Component suborders do not fulfil another customer position. data.get('customerOrders', idOrOrderNumber) returns data.customerOrder. Production-order detail reads include complete steps and splits with quantityProduced; list reads can request the same execution detail with includeExecution: true; a split's remainingQuantity is null when its produced quantity is unknown. Oversized execution graphs fail explicitly instead of returning incomplete progress. Split lists support productionOrderId/productionOrderIds, scope: 'all', skip, limit, and hasMore. ennea.splits.get(splitId) always resolves that exact split.

For a native report control inside each collapsible position, configure a ProductionProgressReport embedded adapter and render:

<ProductionProgressReport
  id="position-report"
  orderContext={{
    order: { _id: order._id },
    splitContext: { splitId: split._id },
  }}
/>

The control rereads the scoped order and split, verifies their relationship and the bound station, then enables the normal reporting workflow. It never switches the App's shared active order. Explicit orderContext without splitContext means order-level reporting; it never inherits the shared split. Without orderContext, the existing active-order behavior applies. Reading or expanding a position does not book progress. Test reports with agreed local test records; saving or compiling the App does not prove an operational result.

For a custom button that finishes all remaining work on one split, use the existing action with its explicit atomic completion option:

const result = await ennea.splits.updateProgress(splitId, {
  completeToPlanned: true,
  expectedQuantity: displayedSplit.quantity,
});

Call it only after an operator click, on a deployment that supports this option. expectedQuantity must be the finite positive plan shown for that exact split. It is a precondition, not a quantity to write. Omit quantityProduced and status. The server reads the current stored values atomically, keeps the greater of produced and planned quantity, and marks the split completed. Thus 3 / 1 stays 3 / 1; 2 / 2 with a queued status becomes completed. An already completed full split returns unchanged: true without another save or event. Unknown quantities are not zero: a missing or invalid planned/produced quantity fails with invalid_completion_quantity. An invalid expectedQuantity fails with invalid_expected_quantity; a changed stored plan fails with 409 split_quantity_changed before any write. Refresh the changed plan and obtain a new operator confirmation; never silently adopt the new plan.

The ordinary quantityProduced option sets an absolute cumulative quantity; it does not add a delta. Do not emulate completion by reading a quantity in the App and writing it back, because another report may arrive between those calls. Check result.ok and the exact split's returned result.data.split status and quantity, then refresh the fulfillment graph. Reads return data.split (data.item is an alias); updates return data.split, data.step, and data.order. Reconcile a timeout with a fresh scoped read before retrying; do not show success from the displayed quantity alone. The same published App capability, assigned and bound station, and progress prerequisites apply; this option needs no additional permission grants.