Workflows

A workflow is the reusable definition of what Alentra asks one person to do. A session is one non-repeatable run of one published workflow revision. Create and publish workflows in the Alentra dashboard. Add the primitives you need, drag them into the exact order the user should complete them, configure access and delivery, then publish. API callers pass the resulting workflow_id; they do not send an inline steps[] definition on every request.

​

Drafts, publishing, and evidence

Editing a live workflow changes only its draft. Publishing increments the revision and commits a definition hash. Each new session copies the workflow id, name, revision, definition hash, launch mode, and ordered steps into its immutable session record. Existing sessions and evidence never change when a workflow is edited later.

​

Access modes

Access modes are deliberately exclusive. An API-only workflow cannot also be launched from its public URL, and the API cannot run a one-time dashboard workflow.

​

Metadata and email are different

metadata is caller-owned correlation context, such as an order or case id. It is available to authenticated dashboard members, signed webhooks, and authenticated session reads; it is never shown on the hosted signer page. Anonymous reusable-link launches accept no metadata because there is no authenticated caller to trust. There is no API recipient_email field. For one-time dashboard links, entering an email only delivers the opaque invitation—it does not identify or pre-bind the signer. Separately, the signer may enter a verified email at the end of the session to receive their result. A workflow may also notify a configured business address when a run finishes; that message contains no claims, signatures, documents, or result data.

​

Conditions

Add Conditions after any primitive, including the last one. Choose Continue when or Stop when, then select a result field, a plain-language comparison, and a value from that primitive’s verified result. For multiple conditions, choose All conditions match or Any condition matches. The opposite action is always shown as Otherwise. For example, after Identity, request date of birth and set Continue when Age in whole years is at least 18. After Age verification, set Stop when Age 18+ requirement met is No; otherwise, continue. Age verification never exposes date of birth or exact age to a condition. Continue requests the next primitive, or proceeds to result delivery when there are no more primitives. Stop ends the session while retaining all verified results. Conditions run after successful verification; a declined or invalid proof still uses the session failure flow. They work with every access mode. Text comparisons ignore case and surrounding spaces. Dates use calendar dates; age is calculated at verification in UTC. Missing values do not match ordinary comparisons, including “is not.” A non-matching rule takes the Otherwise path, so Stop when continues when its conditions do not match. Use an explicit availability condition to handle missing identity fields. Up to eight conditions are allowed per decision. Unrequested fields cannot be tested, and changing a proof’s requested fields requires repairing any conditions that use a removed field. The selected action and conditions are part of the published revision and its definition hash. Editing them cannot alter an existing session. The verified result, decision, audit, charge, and webhook are committed together, including a signed terminal marker on Stop. Existing configured conditions without an action keep their original Continue-when behavior.

​

Existing API-controlled gates

Existing API-only workflows may still pause after a non-final step for your backend to inspect step.completed and call continue or stop. A gate without configured conditions retains that behavior. The editor offers Use conditions instead to convert it explicitly; configured decisions do not pause in awaiting_decision.