Approval Process Design Canvas

The approval process design canvas defines how an approval starts and flows: record triggers, approval rules, data changes, human tasks, conditional routing, service calls, notifications, external callbacks, and completion paths.

Open Approval Process Management, then choose Open approval process design canvas on a process.

The canvas has four parts:

Part	Location	Responsibility
Top actions	Canvas top bar	Back, trigger method, copy, save, publish, save and publish, and the current version
Node library	Left	Adds approval, data processing, human processing, condition, message, service call, and wait callback nodes
Canvas	Center	Arranges nodes and connects processing routes
Configuration panel	Right	Edits the selected node, connection, or trigger settings

1. Top Actions

Action	Description
Back	Returns to approval process management; unsaved changes require confirmation first
Current version	Shows the version currently loaded in the designer
Trigger method	Opens the process trigger settings without selecting a node
Copy	Validates the current canvas and creates a separate draft process from it
Save	Creates a new draft version from the current canvas
Save & publish	Creates and immediately publishes a new version
Publish	Publishes the selected saved draft or archived version when there are no unsaved changes

2. Trigger Method

At least one trigger must be enabled before the process can be saved.

Trigger	Behavior
Trigger on create	Starts the process when a record is created in the related form
Trigger on update	Starts the process when a related-form record is edited
Trigger on delete	Starts the process when a related-form record is deleted
Trigger from form button	Starts the process when the configured custom button is selected for a related-form record

Update triggers support three modes:

Mode	Behavior
Every update	Every edit can start the process
Only when selected fields change	Starts only when at least one configured field changes; at least one field must be selected
Only when condition matches	Starts only when the configured related-form condition evaluates as matched

Trigger From A Form Button

Use a button trigger when approval must be an explicit business action, such as “Submit contract”, “Request review”, or “Apply for release”.

1. Open Button Design for the process's related form, then create and enable a custom button.
2. Select View Page - Header, List Page - Row Action, List Page - Batch Action, View Page List - Row Action, or View Page List - Batch Action. The placement determines the applicable page: view-page placements use View Page, and list-page placements use List Page.
3. Return to the approval design canvas and open Trigger method.
4. Enable Trigger from form button, select the custom button, then save and publish the approval process.
5. Select the button at its configured location. For a batch action, select the records first.

The button location determines which records enter approval:

Button location	Approval target
View Page - Header	The current record on the view page
View Page List - Row Action	The record in that view-page list row
View Page List - Batch Action	Only the records selected in that view-page list
List Page - Row Action	The record in that list-page row
List Page - Batch Action	Only the records selected on the list page

A View Page List can be a child-form list or a related-form list. Its button belongs to the form represented by that list, so it starts the approval process published for that form. The approval target is the row record or selected list records—not the main record displayed on the view page. Each selected record creates its own approval submission and instance when the trigger conditions match.

The button selector only lists enabled custom buttons whose placement and applicable page are valid. If the selected button is deleted, disabled, or moved to an incompatible placement or applicable page, the process cannot be saved or published until a valid button is selected.

Reopening the trigger settings reuses the loaded custom button list for the same related form.

A button trigger records the member who clicked it. Later nodes can use Variable → Button clicker while the button trigger is enabled. Disabling it clears existing Button clicker selections on the canvas and keeps other people and field settings.

Button-triggered approval is submitted on the server. When the same click also matches button-triggered automation, approval submissions, automation executions, and their background-work commands are committed together. If any selected record fails submission validation, none of those workflow submissions are committed. After a successful submission, background workers continue running them even if the page is closed. Automation starts independently and does not wait for the approval result.

3. Node Library

Node	Purpose
Start	Entry point; the canvas keeps exactly one start node
Approval	Creates approval tasks for one or more approvers
Data Processing	Creates a record, or updates the current record and its related data
Human Processing	Lets the configured handlers complete a form data task
Branch	Routes data to matched and unmatched paths
Service Call	Runs a Studio script or a published service-call OpenLink integration flow
Message	Sends a configured Approval Center message
Wait Callback	Pauses the process until an external callback is correlated to the instance
End	Marks a normal completion point; the canvas keeps exactly one end node

The canvas keeps one start node and one end node, and a message node can act as a notification terminal without an outgoing connection.

4. Node Configuration

Approval Node

Approval nodes configure task assignment and decision behavior.

Setting	Description
Approvers	Select members or other available principals from the approval directory; at least one approver is required
Approver availability	Either block when approvers cannot be resolved, or route to configured fallback approvers
Fallback approvers	Required when fallback routing is selected
Approval mode	Parallel creates the approval tasks together; serial processes approvers in order
Serial approval order	Serial approval only; drag approvers to set the order, and approvers resolved from form fields run after the fixed members
Decision policy	Parallel approval supports any one, everyone, or at least N approvals; serial approval requires everyone in sequence
Allow approve	Allows approvers to approve the instance
Allow reject	Allows approvers to reject the instance
Allow return	Allows approvers to return the instance
Allow withdraw	Allows the initiator to withdraw while the process is pending at this approval step
Required comments	Controls whether approve, reject, or return actions require a comment
Due in	Sets a task deadline in minutes, hours, or days; it takes effect with an enabled policy in Approval Center > Timeout Policies

An approval node has exactly one continuing route, and it must be the approved route. Rejected and returned decisions finish the instance with that outcome.

For button triggers, the Configure people dialog for primary and fallback approvers offers Button clicker under Variable. It hides Data field when no member fields are available.

Data Processing Node

Data processing nodes write form data while the process runs.

Setting	Description
Operation	Create data creates a record; Update data updates the current related-form record and its related data
Target form	Required for Create data; only enabled forms can be selected, and the assignment list follows the selected form
Submit approval after create	Starts the form approval of the new record after it is created
Field assignments	Fields written by the node; each assignment selects a field and one value source: a fixed value, an empty value, a field of the triggering record, or the output of an upstream node. Required fields are added automatically and cannot be removed

Creating data requires the Created By system field, and updating data requires Updated By; the created-by field cannot be assigned when updating.

For button triggers, Button clicker is available as a trigger source for field assignments. It writes the clicking member's ID.

Human Processing Node

Human processing nodes create a form data task for the configured handlers before the process continues.

Setting	Description
Handlers	Required; fixed members, related-form fields that resolve to the handlers, or the button clicker for button triggers
Target	What the handlers work on: edit the current data, create new data, edit related form data, or select existing data and link it
Target form	Required when creating data, editing related form data, or linking existing data
Required when creating	Marks the data created by the node as required
Related field	Required when editing related form data or linking existing data; it links the current record with the target form
Fields to process	Fields the handlers fill in; required when editing the current data or editing related form data
Default values	Values applied when the handler creates data
Trigger form approval after submit	Available when the node creates data or edits related form data

For button triggers, the Configure people dialog lists Button clicker under Variable. It hides Data field when no member fields are available.

Branch Node

Branch nodes read fields from the related form and route the process through two required outputs: Matched (Y) and Unmatched (N).

Conditions support nested AND/OR groups and operators such as equals, not equals, contains, comparison, in, empty, and not empty. Available value editors depend on the selected field type.

A branch node must contain at least one valid condition and exactly one connection for each matched and unmatched output. When the upstream path has already passed through a wait callback node, a later branch can also evaluate the callback outcome.

Service Call Node

Service call nodes run an internal capability or call an external system while the approval runs. Pick the mode by what the target is:

Mode	Requirements
Studio Script	Call tenant capabilities such as context.form.* and context.http.*; the script must exist in the current space and be published before it can be selected
Integration Flow	Select a published service-call inbound or outbound OpenLink flow whose local form matches the approval process related form

Set Up A Studio Script Call

1. In Soln Studio, create the script and publish it; the approval node can only select published assets
2. Add a Service Call node on the canvas and set the mode to Studio Script
3. Select the script asset and its entry file
4. Read the payload preview in the configuration panel and check that every field API name the script reads exists in record.data
5. Connect one incoming route and one outgoing route, then save and publish the process

Set Up An Integration Flow Call

1. In OpenLink, create an inbound or outbound flow, set its trigger to Service Call, and bind the same local form as the approval process
2. Save, publish, and enable the flow
3. On the canvas, add a Service Call node and set the mode to Integration Flow
4. Select the published flow; the picker only lists flows that are published, use the service-call trigger, and match the related form
5. Connect one incoming route and one outgoing route, then save and publish the process

What The Target Receives

The node sends the same soln.runtime-context/v1 context to a script and to an OpenLink flow. The configuration panel shows a copyable preview for the current process.

Field	Purpose
record.id	Record attached to this approval
record.data	Related-form values at the moment the node runs, keyed by field API name
form.apiName	API name of the related form
source.instanceId, source.nodeKey	Current approval instance and node
source.trigger	Record action and changed fields that started the approval
source.callback	Latest callback result when an upstream wait callback has completed
runtime.traceId	Stable trace ID of this node execution; use it as the idempotency key of an external request

Runtime Behavior

Result	Effect
The script or flow finishes successfully	The node completes and the process continues along its outgoing route
The script returns a failure (ok: false, success: false, or a status of failed, failure, error, or rejected), throws, or its published entry file is unavailable	The node blocks and the instance waits at this node
The flow execution fails	The node blocks in the same way; fix the cause and retry, and the retry re-runs the same instance and node

Service call nodes require one incoming connection and exactly one outgoing connection. A missing script or integration flow prevents saving and publishing.

Troubleshooting

Symptom	What to check
The script or flow is not in the picker	The asset must be published, the flow must use the service-call trigger, and its local form must equal the related form of the process
The node is blocked after publishing	Read the execution logs: a script error, a failure return value, or a flow execution error all block the node
The script cannot read a field	Field API names must match the preview; record.data is a snapshot taken when the node runs
The external call runs twice	Use runtime.traceId as the idempotency key of the external request

Message Node

Message nodes use the Approval Center message channel and an active inbox-capable message template. The delivery type is fixed to Inbox message and the channel is fixed to the Approval Center, so the node always sends into the Approval Center inbox.

Recipient sources include:

• Process context: initiator, submitter, or current approval assignees
• Fixed members
• A compatible recipient field from the related form
• Variable → Button clicker for button triggers

A message node requires a template and a complete recipient configuration. It can continue to another node or act as a notification terminal without an outgoing connection.

The recipient Configure people dialog hides Data field when no member fields are available. Message template input mappings can also read source.trigger.buttonClickerId.

Wait Callback Node

Use a wait callback when an external system accepts a job first and returns the result later: the process starts the external work, waits, and resumes when the callback arrives.

Service Call → Wait Callback → next node

Do not place a condition, message, or approval node between the service call and the wait callback.

Prepare The Callback Flow

1. In OpenLink, create an inbound flow and set its trigger to Webhook
2. Bind the same local form as the approval process
3. Set the target action to Complete Workflow Callback
4. Save, publish, and enable the flow
5. Copy the Webhook URL that the flow exposes; the wait callback node shows the same address

A service-call flow cannot be used as the callback endpoint.

Configure The Node

1. Connect Wait Callback directly after the service call node that starts the external work
2. Select the published inbound Webhook flow
3. Configure the correlation key template; the default value is {{data.record.id}}
4. Pass the rendered key to the external system and require it to return the same value
5. Connect exactly one outgoing route, then save and publish the process

The key must identify exactly one pending wait inside the same tenant and callback flow. When one record can have several waiting approvals at the same time, build the key from the approval instance or the external task identity instead of the record alone.

What The External System Sends

The external system posts the callback to the Webhook URL shown in the panel:

{
  "callbackId": "review-result-8f1d31",
  "correlationKey": "record-7c831b",
  "status": "succeeded",
  "result": { "decision": "approved", "comment": "Risk review passed" },
  "error": null,
  "completedAt": "2026-09-10T08:30:00.000Z"
}

Field	Required	Description
callbackId	Yes	Unique identifier of this callback from the external system
correlationKey	Yes	Must exactly match the rendered correlation key
status	Yes	Must be succeeded; approval callbacks do not accept failed or canceled
result	Yes	Callback result object
result.decision	No	approved, rejected, or returned; it decides how the process continues
error	Yes	Must be null on success
completedAt	No	ISO date-time or null

A matching callback completes the wait node and resumes the approval instance. When the external job fails, keep it retryable or return a successful callback that carries a routable business outcome in result.

Route On The Callback Result

Place a branch node after the wait callback and select the Callback Result field to branch on approved, rejected, or returned. The field is available only when the branch upstream path has passed through a wait callback node; later service-call and message nodes can also read the last result from source.callback.

Troubleshooting

Symptom	What to check
The instance stays at the wait node	The external system must post to the Webhook URL with the exact correlationKey; the callback flow must be published and enabled
WORKFLOW_CALLBACK_WAIT_NOT_FOUND	The correlation key does not match a pending wait in this tenant and flow, or the key template renders a different value than the one sent out
WORKFLOW_CALLBACK_WAIT_NOT_UNIQUE	Several waits share the same key; include the approval instance or external task identity in the key
The callback is rejected	status must be succeeded, error must be null, and the callback must belong to an approval wait
The branch node has no callback result field	The branch is not downstream of a wait callback node

The full payload, callback contract, and script examples are documented in Workflow Integration.

5. Validation, Saving, And Publishing

Canvas Validation

Copying, saving, or publishing requires a valid canvas. Key checks include:

• Exactly one start node and one end node
• At least one create, update, delete, or form-button trigger is enabled
• An enabled form-button trigger selects an enabled custom button with a placement and applicable page supported by the related form
• The start node has no incoming connection and exactly one outgoing connection
• Every non-start node is reachable from the start node
• Every node except the start node has exactly one incoming connection
• Approval, data processing, human processing, condition, service call, and wait callback nodes have exactly one outgoing connection, connected from another side of the node
• Approval nodes have exactly one outgoing connection and it carries the approved result
• Every condition has at least one rule and complete matched and unmatched routes
• Data processing nodes have an operation, a target form when creating data, at least one field assignment, and the required created-by or updated-by field
• Human processing nodes have handlers, a target, the target form and related field required by that target, and the fields to process when they edit data
• A wait callback is directly preceded by a service call
• Message templates, recipients, scripts, integration flows, and correlation keys are complete
• Every route can reach the end node or a terminal message node

Save And Publish

Action	Description
Save	Creates a new draft version from the current canvas
Save & publish	Creates and immediately publishes a new version
Publish	Publishes the selected saved draft or archived version when there are no unsaved changes

A process has a runnable version only after publishing, and its status is managed in Approval Process Management.

Copy The Current Process

Click Copy to create a new approval process from the current valid graph and trigger configuration. The copy dialog asks only for a new name and an optional description; Soln generates the new code and keeps the source related form.

Valid unsaved changes on the screen are included. The new process is an independent draft and does not copy publication state, approval instances, tasks, or execution logs.

6. Recommended Design Sequence

1. Configure create, update, delete, or form-button triggers
2. Add approval nodes and set approvers, availability policy, decision policy, allowed actions, and deadline
3. Add data processing nodes to create or update form data
4. Add human processing nodes when a handler must complete a form data task
5. Add conditions for data-based branching
6. Add service calls for scripts or integration flows
7. Add a wait callback only when an external asynchronous result is required
8. Add message nodes for process notifications
9. Connect every required route and review the configuration panel warnings
10. Save a draft version, or save and publish when ready
11. Test with a related-form record or the configured form button, then review the execution logs