Using Approval Processes
An approval process defines how records of a related Soln form enter approval, who makes decisions, how conditional branches are evaluated, and which service, message, or callback steps run before the process finishes.
Open Approval Center, then enter Approval Process Management to manage the approval processes of the current space.
Before You Create A Process
- You need a space administrator who can manage approval processes
- The related form must already exist and be enabled; triggers, condition fields, recipients, and the record snapshot all come from it
- Plan the process code and the related form up front: both are fixed after creation
Process List
The list is sorted by last update time and paginated; the default page size is 20, and 10, 20, 50, or 100 rows can be shown per page. Keyword search matches the process name, code, description, related form, and status.
| Item | Description |
|---|---|
| Name | Business-facing approval process name |
| Code | Unique process code in the current space |
| Related form | Soln form whose records trigger and provide data to the process |
| Current version | Active published version, or the latest draft version when no version is published |
| Outdated | A newer draft exists after the currently published version |
| Audit info | Created and updated time and operator |
The list supports creating a process, plus these actions:
| Action | Description |
|---|---|
| Open approval process design canvas | Configures triggers, nodes, and routes |
| Versions | Opens version history and allows a publishable draft or archived version to be viewed or published |
| Execution logs | Opens runtime records for the selected process |
| Disable | Available for published processes: archives the process so it no longer starts new approval instances |
| Enable | Available for archived processes: republishes the last published version so the process starts new instances again |
| Delete | Available for unpublished drafts and archived processes; a published process must be disabled first. Deletion is permanent |
Process Status
| Status | Meaning |
|---|---|
| Draft | The process has not been published, or only has an unpublished configuration; it does not start new approval instances |
| Published | The active version can start approval instances from the configured record triggers |
| Archived | The process is disabled and no longer starts new instances; it can be deleted, enabled again when it has a published version, or have a valid version published again |
Publishing another version makes it the active version, and existing execution records keep their original version and runtime snapshot.
Create A Process
- Open Approval Process Management
- Click New
- Enter the process name
- Select the related form
- Add an optional description
- Click Create
| Field | Required | Description |
|---|---|---|
| Name | Yes | Display name used in the process list and designer |
| Code | Generated | Created from the process name, for example expense_claim_a1b2c3d4e5f6, and cannot be changed afterwards; a name without usable characters falls back to the approval_process prefix |
| Related form | Yes | Supplies trigger events, condition fields, recipient fields, and the business record snapshot; only enabled forms can be selected, and system default forms are excluded unless they are organization profile forms |
| Description | No | Explains the approval purpose or scope |
A new process is created as a draft with an empty design canvas, and the trigger on create and the trigger on every update are enabled by default. Open the design canvas, add a start node, an end node, and the nodes that process the approval, connect a valid route, then save and publish it.
Trigger, node, and route configuration is covered in Approval Process Design Canvas.
Edit The Basic Information
The process name and description can be changed later: in the design canvas, Save and Save & Publish open the Approval Process Basic Information dialog where both fields can be edited before the version is written.
The process code and the related form are fixed after creation.
Version History
Use Versions to inspect every saved version. The list is paginated and shows the version number, status, creation time, and update operator.
View opens the saved version in the design canvas so its nodes, routes, node settings, and trigger can be inspected; the canvas stays editable there, and saving creates a new draft version. Publish makes a draft or archived version active when it passes current validation.
Saving the designer creates a new draft version, and Save & Publish creates and activates a new version in one operation. When a published process has a newer draft, the process list shows Outdated.
Disable, Enable, And Delete
| Action | Precondition | Effect |
|---|---|---|
| Disable | The process is published | Archives the process so new trigger events no longer start it; historical versions and execution logs are not rewritten |
| Enable | The process is archived and has a published version | Republishes the last published version, so the process returns to the published state |
| Delete | The process is archived | Permanently deletes the process; deletion cannot be undone |
An archived process that has never been published cannot be enabled; publish a version from version history or the design canvas first.
Keep a process when its configuration or execution history is still needed for audit or troubleshooting, and delete it only when neither is needed.
Copy A Process
Use Copy in the design canvas header when another approval process is a suitable starting point.
- Open the source process in the design canvas
- Make any required canvas or trigger changes
- Click Copy
- Enter the new process name and optional description
- Confirm the copy
Soln validates the current trigger configuration, nodes, routes, and node settings before copying. The new process receives the current valid canvas, including valid unsaved changes, and keeps the same related form. Its trigger settings, approval rules, conditions, service calls, messages, callback settings, and layout are copied, and a new unique process code is generated automatically.
The result is an independent draft process with its own version and audit information. It does not inherit the source process's published or archived status, active runtime instances, approval tasks, or execution logs, so review and publish it separately.
Verify That A Process Runs
- Open the design canvas, add at least a start node, an end node, and a processing node, then save and publish
- Create or edit a related-form record so that a configured trigger fires
- Open Execution logs for the process: the new instance appears with its status and current node
- Open Approval Records: approvers must see the pending task and be able to decide on it
Execution log fields and the troubleshooting order are in Approval Process Execution Logs.
Troubleshooting
| Symptom | What to check |
|---|---|
| A new record does not start the process | At least one trigger must be enabled; the field-change mode needs at least one selected field; the condition mode needs matching record data; an archived process never starts new instances |
| Saving the canvas fails | Canvas validation failed; the message names the node that needs attention |
| Publishing a version fails | The version must pass current validation; open the design canvas, fix the reported node, and publish again |
| Disable is missing | Only published processes can be disabled |
| Delete is missing | The process must be archived first: disable it, then delete it |
| New instances still appear after disabling | Disabling stops new trigger events only; instances that already started keep running to completion |