Five groups: building an app, screens, actions and expressions, data, running and governing.
An application configured in Lima for a business process: screens, people, data handlers and a flow, published as a version and run on live data.
An app built by defining functions and their levels first, attaching a screen to each level, assigning the people at each level, then writing the flow and trigger criteria.
An app built by drawing lanes and boxes first, attaching a screen to each box, naming the role that owns each box, and writing the criterion on each arrow.
A process app started by a criterion on records: each matching row launches its own instance with its own process ID.
A screen that collects answers from a list of people or a level, with a close date, whose answers become rows other apps can read.
The functions and their levels that a collaborative app is built on, with parent and child levels fixed for each level.
A position in a function's hierarchy, such as buyer, category lead or chief procurement officer; each level has a screen and a set of people.
A horizontal band in a process drawing that belongs to one role; the boxes in it are the steps that role performs.
A step in a process drawing, with a screen and the role that performs it; also called a node.
Start, screen, decision, parallel split and join, wait, notification, write-back, sub-process and end.
A node that chooses the next arrow from an expression evaluated when the previous screen completes.
A screen delivered to an outside login (a supplier, carrier, customer or auditor), with the access policy limiting the rows shown.
Where apps are configured: hierarchies and lanes, screens, data handlers, criteria, variables and versions.
A definition proposed by the studio from a description, a rule or a hierarchy; it passes the same validator, preview and gate as a hand-built definition.
The part of the studio that generates screens from data handlers, rules and hierarchies.
What a person sees at a step: a layout of components, for desktop and mobile, attached to a level or a box.
A control on a screen: a field, a dropdown, a grid, a chart, a button, a pop-up, an upload, a scan, a signature.
A part of a component: the label, the value, the help text, the validation message.
The regions a screen is divided into, with a desktop and a mobile arrangement.
The name every component has, unique across all screens of an app, through which any property can be read or set.
A setting of a component, such as value, visible, enabled, required or format, set from a constant, a variable, a data handler, an expression or a function.
The rules a component's value must pass: required, range, pattern, custom expression, each with its message.
To give a component or a variable its value at load or on an event.
A trigger, an execution and an outcome on a component; a component can carry several.
The condition that fires an action: a click, a change, a valid value, a selection, a load, an upload, a clock.
What an action does: set a value, call a data handler, run a function or a script, call a REST endpoint, move the flow.
What changes after an execution: a panel fills, a component enables, a row is written, a notification goes out, a clock starts, the flow moves.
The place where conditions, calculations and actions are written in one formula language and tested against live values as you type.
A condition written in the expression editor that starts a flow (trigger criterion) or moves it (flow criterion).
Running a trigger and an execution against a chosen row in the editor with the outcome shown and every write held.
A named value with a life: screen, app, global or system scope.
Lives while the screen is open: a filter, a draft value.
Lives while the instance runs: a total, a chosen site, the current level; exchanged between nodes.
Defined once for the platform with business meaning for every app: fiscal calendar, plant list, approval bands.
Provided by the platform: today's date, the time, the logged-in user and role, counts.
A named piece of logic, provided by the platform or registered by an application team, called by name from actions.
A named connection from an app to rows in a system: a federated table, a saved query, a pipeline result, an API or file, or a device feed; reads and writes rows.
A handler on a federated table registered in the catalog; the rows stay in the source.
A handler on a saved query with parameters, computed in the sources with pushdown.
A handler on the result of a Backbone or data-science pipeline: prepared, checked, refreshed on a schedule.
The rows stay in the system that owns them; the handler sends the filter and the columns and the system returns the matching rows.
Receiving changed rows from a system as they happen, through the interface the system offers.
A change made by the app in the system of record through that system's released interface, with the acknowledgement stored beside the decision.
An interface the vendor publishes and supports for third parties: BAPIs and IDocs in SAP, REST resources in Oracle Fusion, the Table API in ServiceNow, web-service operations in Workday.
What a system returns after a write: a document number, a resource ID, a status, or an error; stored in the log.
The register of every table, column, view and object the platform can read, shared by the Data Fabric, the Backbone and SmartApps.
One start of a process: its own process ID, workbench, clock and log.
The unique identifier of an instance, present in every log line and notification.
The running instance as its owner sees it: the screens in their current state, the step, the clock and the log so far.
All instances of an app by step, age, owner and value, with the clocks about to run out first.
The time limit on a step; when it runs out, the rule for that step decides: escalate, hand to the alternate, return with a note.
Passing a case to the parent level or a named user when a clock runs out, with the context attached.
A person named in the definition who acts at a level when the primary is absent.
A person named by an approver for a stated period; both names are logged on every step taken under the delegation.
A published state of an app; running instances finish on the version they started on; new starts use the newest.
The approval and checks that move a version from the configuration environment to production; write-back is switched on per object here.
Running an app end to end as a chosen role on live rows with writes held.
The append-only, hash-chained record of every step, value, decision, notification and write-back acknowledgement of every instance, with the app version.
Each log entry carries a hash of the previous one, so any change to an earlier entry is detectable.
A read-only screen where auditors browse instances, decisions and configuration history with the same filters a process owner uses.
The meta data of a collaboration: for each activity, the prior action, the function and level, the next level, the type, the rule, the run-time table, the filter, the screen and the active period.
The traces of each running collaboration instance, referencing the rules that produced them.
The first session builds the first screen on your live rows.
