Skip to content

Design the Application Workspace #

A Product Application can give each customer an isolated Application Workspace around its Product Instance. The workspace combines customer records and Process work without exposing OEM engineering tools.

Define record models in Build. Then open Access > Presentation to choose customer pages and describe how Processes should appear. Presentation changes remain draft-only until you publish.

Silo outload Access Presentation section showing nine configured workspace pages and the page type, data model, order, and edit controls
Presentation is the authoring surface for customer workspace pages and Process-facing language.

Start from customer decisions #

Write the operating questions before adding pages:

  1. What needs attention now?
  2. What work is active or recently completed?
  3. Which records does the operator maintain?
  4. Does location change the decision?
  5. Which details belong in device Controls instead?

Keep Remote Shell, fleet logs, release controls, raw traces, and authoring diagnostics in the OEM workspace.

Choose page types deliberately #

PageUse it for
OverviewA concise application landing page and bounded aggregate status
WorkCustomer-readable Process executions and their current state
ExceptionsWork and alerts that match needs-attention rules
RecordsA curated list for one Product Record model
MapLocation-aware records, devices, and work where spatial context is useful

The underlying workspace also supports list and detail page contracts for model-backed navigation. Prefer the named workspace pages above when they match the operator's task.

Page order controls navigation order. Role visibility can restrict a page to named customer roles. An omitted restriction does not replace the model, operation, and tenant permission checks underneath it.

Design Overview #

Overview should answer whether the product is operating normally and where the operator should go next. Use bounded record aggregates for useful counts, totals, averages, minimums, maximums, groups, or time buckets.

Do not turn Overview into an unbounded analytics system. Aggregates are permission-aware and intentionally limited. Use a reporting integration when the customer needs broad historical analysis or joins across external systems.

Dark customer Silo outload Overview showing zero load tickets, exceptions, and settled work, no active alerts, bay-controller publication state, and the Request outload action
The customer Overview combines bounded status, alerts, synchronisation state, and deliberate actions without exposing OEM tools.

Design Work and Exceptions together #

Work presents Process executions using customer language. Customers can filter work by state, Process, attention, subject, activity, and time within their instance and role boundary.

Exceptions is the focused queue. It uses Process presentation rules and alert state to collect work that needs attention. Define what the operator should do next instead of exposing an internal failure code as the whole experience.

Dark customer Silo outload Work page in its true empty state, stating that process work will appear when Processes run
A true zero state explains what belongs on Work instead of showing an empty content table.
Dark customer Silo outload Exceptions page in its true empty state, stating that nothing needs attention
Exceptions gives a direct all-clear when no Process work or alerts need attention.

An execution's technical status and safety state remain distinct. A failed run may be compensated; another may need reconciliation.

Curate Records #

Each Records page selects one model. Configure:

  • a customer-readable title
  • navigation order
  • role visibility
  • the columns needed for the decision
  • useful empty-state title and guidance
Silo outload workspace page editor showing a model-backed list page with its page type, Silo data model, title, order, role visibility, and columns fields
A model-backed Records page defines its customer title, order, visibility, and curated columns.
Customer Portal load ticket record showing a settled 27.45 tonne outload for synthetic vehicle Harvester HX-204 with read-only identity, timestamp, quantity, silo, and status fields
A populated Product Record presents the customer outcome and its curated read-only fields without exposing Process internals.

Model permissions still govern list, create, edit, archive, and delete behaviour. Do not display secrets, internal identifiers, or fields that exist only for orchestration unless the customer needs them.

Use Device Class streams for continuous device values. Do not copy every sample into Product Records merely to show it in a table.

Use Map only when location matters #

Map can combine available location-aware records, devices, alerts, and work for the instance. Add it when proximity, route, region, or site context changes the operator's decision.

Do not infer a location the product did not report or the customer did not assign. Provide a useful non-map path for records without coordinates and for users who cannot use a visual map.

Dark customer Silo outload Site map showing filters, two devices with known locations, no devices without locations, and the marker-detail panel
The map keeps location coverage and filtering visible before the customer selects a device marker.

Author Process presentation #

Presentation overlays customer language on a Process without changing its execution graph. For each Process, configure:

  • singular and plural names
  • a customer-facing description
  • labels for internal states
  • statuses that count as needs attention
  • list summary fields
  • role visibility

Keep labels stable and action-oriented. A state label should tell the customer what is happening, while the execution debugger retains the exact technical state for OEM investigation.

Preview the complete boundary #

Before publishing:

  1. Sign in as a customer viewer and operator.
  2. Confirm page and Process role visibility.
  3. Verify true empty states and filtered no-match states.
  4. Test long names and narrow screens.
  5. Follow an exception into the associated work and record.
  6. Confirm another customer cannot see the instance, records, work, or map points.
  7. Keep one-device controls on the Device Class page and site-wide work in the Application Workspace.