Set up Workflows

A Workflow Definition describes a process for one record type or one Board. A revision contains its steps; a running instance keeps the revision with which it started. Start with Using Workflows for the everyday view, or use Workflow configuration automation for HTTP and C# configuration.

Prepare the application

Enable Workflow in module administration and give the configurator Workflow configuration permissions. These permissions allow authoring; they do not grant access to records or permission to answer a process step. The Worker must run for automatic steps, timers and event waits to progress.

For an order-and-assemblies example, first create the Order and Assembly record types. Give Assembly a Reference to Order and Order the inverse collection Assemblies. Give Assembly a State field whose values include ready. Configure the record permissions and Table, Card and Form surfaces needed by the people who will create and change these records.

Put the Assemblies inverse collection on the Order Card so people can see and manage its children from the order. An Object context fact is a process or Board summary; it does not create this related table. If children must also be managed inside an edit form, configure a Form Related table. Add Orders, Assemblies and any relevant Board to the user menu.

Create the Workflow Definition

1. Open Workflow Definitions and create a Workflow. Enter its name, key and optional description and instance-number prefix.
2. In Context, choose the Order Entity Definition. For a Board process, choose the Board instead: that process belongs to its Board items, across target types.
3. Save the Definition. Review its Context before creating a revision: creating the first revision permanently locks Context, even if that draft is deleted.
4. In Outcomes, configure the business results. A new Definition starts with the enabled default Completed. You can edit its key and result type until revision references impose the same restrictions as for other outcomes.
5. To change the default, edit another enabled outcome and select Use as default. There must always be exactly one enabled default. Choose its replacement before disabling or deleting the previous default. Disable an outcome to remove it from new selections; published processes can still finish with their existing outcome.

A draft reference permanently locks an outcome key. A published reference also locks its result type. Name, description and order remain editable. An outcome still referenced by a revision cannot be deleted.

Create and publish the first revision

In Revisions, create a draft. Creation opens the Designer with Start and End. Add nodes from the palette, connect their outputs and configure their properties. Use meaningful step titles; If also shows its condition on the canvas. The Designer supports Start, End, Delay, DevLog, User Input, If and Wait Event.

• Assign each End an enabled outcome.
• For User Input, add named choices, connect each choice and set Who can respond. Responsibility, inherited permissions and a Security DSL rule are separate ways to grant admission. An unconfigured rule grants nobody access.
• For Delay, set a positive duration and connect Continue.
• For If, enter a condition over the process context and connect True and False.
• For Wait Event, add observations as described below and connect Event. Timeout is optional; if you set a duration, also connect Timeout.

Validate shows publication problems or confirms success. An expression’s Validate button checks that expression; it does not validate the entire graph. Save permits an unfinished draft. Publication requires valid settings and references, connected required outputs, every node reachable from Start and a path from every node to an End. See the process document reference for exact rules and YAML examples.

Save, return to the revision and publish it. At most one revision is Active; publishing a new one deprecates the previous Active revision. Published content is immutable. Copy a revision to a new draft for subsequent changes. Running processes keep their original revision.

Configure activation and runtime administration

In Activation, choose Explicit for a manual Start process action, or Implicit for automatic activation. Explicit requires a permission rule and record View; it may also have a business precondition. Implicit has no personal permission rule: without a precondition it reacts to creation; with a precondition it checks creation and update events. Saving activation settings does not scan existing records. Related-record observations belong in Wait Event or Wait Until, not in an assumption that every child change becomes an Order update.

In Security, assign the roles or groups allowed to administer runtime processes. Cancel, Retry, Suspend and Resume require this authority or global runtime administration. It does not grant record View or permission to answer User Input.

Expose the process to users

For an Entity process, open its Entity Definition’s Object context facts and add the Workflow under Workflows. Then add that fact to the relevant Card or Table surface. Configuration uses the process name; a fact on a Card provides status, a process-number link and permitted actions. A Table cell is read-only. Configure both the surfaces and their assignment to the intended users.

For a Board process, affiliation follows the selected Board automatically. Its Workflow configuration section controls order and visibility; Item signals adds the process summary to the Board item’s header. Hidden presentation does not disable the process or change permissions.

Add Workflow Instances to the runtime menu for process browsing, and Workflow Definitions for configurators. Module administration offers these menu entries. Users still need the permissions of each destination.

Enable the Definition’s Collaboration policy if its subsequent process activity should appear on the record or Board item. This does not backfill earlier activity or enable a disabled Collaboration channel.

Wait until all assemblies are ready

Use Start → Wait Until → End, connecting the Satisfied output. Configure its condition with:

COUNT(item.Assemblies) > 0 AND ALL item.Assemblies WHERE (State = 'ready')

The count prevents an empty collection from satisfying the condition. Configure Wait Until with one observation:

• Source: Related records.
• Related path: item.Assemblies.
• Changes: Collection membership changed and Related records changed.
• Continue after: Any observation (OR).
• Leave Timeout empty to wait indefinitely, or set it and connect a separate End with a suitable timeout outcome.

Membership means a record joins, leaves or moves between parents. Related records changed includes changes to reached records and their Board/Workflow facts. This does not emit a synthetic Updated event on the Order. The observation wakes the process; Wait Until reads the current state and leaves through Satisfied only when the condition is true. Observation begins before the first condition check, so a change during the switch to waiting remains available. Initial true completes immediately. False checks consume their event group and keep the same step and deadline.

For a singleton Reference, the choices are Link changed and Related records changed. A path can follow up to five singleton References and end in one collection, such as item.Customer.Assemblies. It cannot continue through a collection into another collection, such as item.Assemblies.Components.

To react to Order edits as well, add a second observation with Process context and Updated, keeping Any observation (OR). Every observation (AND) waits until each observation has received a matching event; it does not mean that every child is ready. Use the Wait Until condition for that state test. Specific Entity records and Board items can also be observed. A group has at most 20 observations; nested groups and fork/join are not supported. Event semantics explain receipts, repeated visits and timeouts.

Verify the configured application

Use the menu and the same surfaces as the intended users:

1. Create an Order, open its Card and confirm the Assemblies table and named process fact are visible. Start the process with an empty collection: it waits.
2. Add two assemblies from the Order. Set only one to ready: the process still waits. Set the second to ready: it completes with the configured outcome.
3. On another order, verify adding, removing and reassigning an assembly while waiting. Verify that a change to an unrelated order’s assembly does not satisfy this process’s condition.
4. Open the process number and inspect its steps and history. Exercise any User Input and timeout branches you configured.
5. Verify with a normal user that record access, response permissions and process administration match the intended roles.

Move cards from a process

Add Move on Board and choose the process context, its typed related record or collection, a Board target Entity, or a fixed card through the picker. Select the Board, destination and optional specified source, then connect both Success and Failure. A Board Item process can move its own card, including an Itself card. Board-target navigation requires an actual matching external Entity type.

The node runs as System User through normal Board permissions. Configure the transition’s System grant or other intended SQL grants; author access alone does not permit execution. Already-at-destination is a successful unchanged result when identity, View and source checks pass.

Collections are fixed when the node starts, with at most 500 source members. Each card commits independently. Connect Failure to a step that lets operators inspect partial results; it does not roll back cards already moved. Use another Move node for a different Board, and an explicit new visit for a new business attempt. Save/reload and publish before starting the process normally.