A screen defines what a person sees at a step: a layout of components such as text boxes, grids, charts, dropdowns, buttons and pop-ups, for desktop and for mobile.
Three levels, dragged into place.
A layout divides the screen into regions: a header, columns, tabs, a side panel, a footer. Components sit in the regions: a text box, a number, a date, a dropdown bound to a list, a grid bound to a data handler, a chart, a button, a pop-up, a file upload, a signature pad, a map. Elements are the parts of a component: the label, the value, the help text, the validation message. A screen is drafted by dragging components into a layout, and the studio can draft it for you from the fields of the data handlers the step needs.
The same screen definition renders for desktop and for mobile: the layout has a mobile arrangement, and components have mobile behaviour, for example a barcode scan on a serial number field or a camera on a photo upload. A count on the warehouse floor and its review at a desk are one screen.
| Component | Bound to | Typical use |
|---|---|---|
| Text, number, date, time | a field of a handler, a variable or an expression | serial number, quantity, new delivery date |
| Dropdown, radio, checkbox | a list from a handler or a constant list | reason codes, plants, decision options |
| Grid | rows of a data handler, with filters, sort and inline edit | late order lines, count differences, journal lines |
| Chart | a query handler or the grid's rows | claims per month, cover by plant |
| Button | actions | look up, approve, escalate, submit |
| Pop-up and panel | a second screen or a section shown on demand | line detail, supplier history |
| Upload, photo, scan, signature | files and captures stored with the instance | certificates, fault photos, sign-offs |
| Portal frame | the same components delivered to an outside login | supplier reply, customer claim |
Any property can be read or set through the ID, from anywhere in the app.
Each component in an app has a unique ID across all its screens, such as grd_claims or btn_approve. Every property of the component, including its value, is reachable by that ID from expressions, actions and other components: btn_approve.enabled, grd_claims.selected.status, txt_note.value. That is how a screen behaves: a button enables when a note is present, a panel fills when a row is selected, a chart follows the grid's filter.
Properties are set in five ways: a constant, a variable (screen, app, global or system), a data handler (a field of the current row, or a list), an expression written in the editor, or a function. Validation is a property too: required, range, pattern, and a custom expression with its message. A component's value can be instantiated at load, on an event, or when another component changes.
idUnique across the app; used everywhere the component is referencedlabel · help · placeholderText elements, translatable per languagevalueConstant · variable · handler field · expression · functionvisible · enabled · requiredBooleans, usually expressions on other components or on the rolevalidationRequired, range, pattern, custom expression and messageformatNumber, currency, date, unit; per user localemobileScan, camera, location, offline capture where allowedactionsZero or more trigger → action → outcome chainsstylePrimary, secondary, warning; density; width in the layoutStart from a draft, then adjust.
The studio drafts screens in three ways. From data handlers: point at the objects a step needs and it lays out the fields, with the right component per type and the grid for the rows. From rules: a data-quality rule or a contract on a record becomes the correction screen with exactly the fields the rule names, so the steward's screen exists the moment the rule does. From hierarchies: a collaborative app gets a screen per level, with the fields that level decides on and a summary of the levels below.
A draft is an ordinary screen: every component has its ID, its properties and its actions, and it passes the same validation and preview as a screen built by hand. AI-assisted configuration explains what a plain-language description adds.
Yes. Colours, type and spacing are a theme applied to every screen; component styles map to your tokens. Screens stay readable on light backgrounds by default.
Components that allow offline capture keep values on the device and submit when connected; the log records the capture time and the submit time separately.
Yes: visibility and enabled properties are expressions on the role, so a customer and an agent can share a claim screen with different parts visible and editable.
With the instance, in the platform's store, referenced from the log; a retention rule decides how long they stay.
Bring one process and the systems it touches. In the first session we register the data handlers, draw the levels or the lanes and run the first screen on your live rows.