Published at: 2025-10-30
Configure Approval Flow Nodes
1. Approval Node Configuration
1.1 Approval Types
| Type | Description |
|---|---|
| Standard Approval | In standard approval nodes, approvers can be selected from colleagues, departments, department heads, user groups, roles, process variables, data variables, or personnel object variables. |
| Countersigned Approval | Countersigned approval requires unanimous approval to pass; a single rejection results in overall rejection. |
| Tiered Approval (Designated Level) | Follows company hierarchy levels. When the initiator’s department level matches or exceeds the selected tier, options include process exception, designated approver, or automatic approval. |
| Step Approval (Fixed Level) | Requires approval up to a fixed hierarchy level. Multiple consecutive levels can be assigned to the same approver for single approval. When submitter level equals/exceeds the fixed level, options include approval by superior department head, process exception, designated approver, or automatic approval. |
| Step Approval (Fixed Steps) | Specifies the number of hierarchical levels requiring approval (must determine approval flow type before implementation). |
1.2 Approval Types
1.2.1 Standard Approval
Single-approver scenarios: Used when an operation requires one person’s approval before proceeding.
1.2.2 Countersigned Approval
Critical decision scenarios: Ensures all relevant stakeholders approve important decisions.
- When selecting “Countersigned Approval,” configure passing strategies: Unanimous, Approval Ratio, or APL Code.
Countersign Strategies
- Unanimous: Node passes only when all approvers agree; one rejection fails the node.
- Approval Ratio: Node passes when the ratio of approvals (approvals/total approvers) meets/exceeds the set threshold.
- APL Code:
- Customize approval logic via functions.
- Supports strategies like:
- Pass when all approvers agree
- Pass when any approver agrees
- Complete when any approver rejects
- Custom handling for mixed approvals/rejections
- Example function:
groovy
/*
* Customize approval logic using approval opinions
* Return true for passed countersign
* Return false for failed countersign
* Return null for node exception
*/
log.info(opinions)
log.info(taskId)
log.info(name)
return true;
1.2.3 Tiered Approval (Designated Level)
Sales Order approval: For key accounts or high-value orders, designate specific approvers (e.g., Sales Director) to ensure accuracy and compliance.
1.2.4 Step Approval (Fixed Level)
Fund approval: For large expenditures/investments, multi-level approvals ensure compliance.
1.2.5 Step Approval (Fixed Steps)
Purchase requisitions: Requires approvals from fixed levels (e.g., department head → procurement → finance) to validate requests.
picture coming soon:
picture coming soon:
1.3 Node Assignees
1.3.1 Select Personnel, Roles, or Variables
- Assignees can be individuals, roles, approval roles (configured in business roles), user groups, process variables, data variables, or grouped by conditions.
- Data variables support trigger object fields and lookup-associated object fields.
1.3.2 APL Code-Based
- Use APL functions for complex assignee logic.
1.3.3 Configuration Table-Based
- Select Configuration Table Object: Enable “Based on Configuration Table,” then add and select objects.
- Set Matching Conditions:
- Left field: Configuration table fields (determines right-field options).
- Right field: Trigger/associated object fields, including:
- Personnel: Recent, colleagues, related fields (single/multi-select).
- Departments: Recent, departments, related departments (single/multi-select).
- External personnel/departments: Interconnection users/departments (feature-controlled).
- Combine multiple conditions with AND/OR logic.
- Sorting Rules: Default: Created time (descending). Supports 3 custom sort fields (ascending/descending).
- Specify Assignee Field: Select a personnel field from the configuration table (single/multi-select, external allowed).
1.3.4 Default Assignee
- Specify fallback assignees when node resolution fails (supports personnel, roles, user groups, variables).
1.3.5 Other Settings
| Name | Action |
|---|---|
| Auto-approve if current approver = initiator | Skips approval when identical. |
| Return to current node after rejection | Re-submissions bypass prior approvals. |
| Allow current approver to edit locked data | Overrides data locks for approvers. |
| Auto-approve historical nodes with same assignee | Excludes previously processed nodes. |
picture coming soon:
1.4 Approval Content Configuration
Options: No content, custom forms, process layouts.
1.4.1 No Content
Approvers directly approve without viewing/editing content.
1.4.2 Custom Forms
- Configure trigger object fields (sub-object fields excluded).
- Set field requirements (required/read-only).
- Must enable “Allow editing configured content” to display fields during approval.
1.4.3 Process Layouts
- Select/create one layout per node.
- Supports primary/sub-object fields for simultaneous editing.
- Layout rules apply during approval.
- Requires “Allow editing configured content” to display.
1.4.4 Other Notes
- Field requirements inherit from object settings but can be overridden per node.
- Date range fields only configurable via process layouts.
picture coming soon:
picture coming soon:
1.5 Rejection Content Configuration
Options: No content, custom forms, process layouts.
1.5.1 No Content
Reject with comments only.
1.5.2 Custom Forms
Mandatory fields for rejection (cannot disable “Allow editing configured content”).
1.5.3 Process Layouts
For complex rejections involving primary/sub-object fields.
1.6 Mandatory Approval Comments
Configure whether comments are required for approval/rejection. Node settings override global defaults.
1.7 Button Settings
- Show/hide and reorder buttons (first 3 visible; others under “More”).
- Customize button labels.
picture coming soon:
1.8 Node Timeout
Set duration (minutes/hours/days) before triggering CRM reminders.
1.9 Timeout Policies
Custom actions via functions after timeout.
1.10 Additional Reminders
Configure CRM/email alerts (pre/post timeout), to-do lists, and CC recipients.
1.11 Post-Approval/Rejection Actions
Field updates, CRM/email/SMS/external notifications, APL code execution, variable assignment, team changes.
1.12 Preconditions
Set conditions for approval using object fields, lookup fields, department heads, personnel attributes.
picture coming soon:
2. Multi-Branch Node Configuration
2.1 Description
Requires ≥2 nodes; branches execute when conditions are met.
picture coming soon:
2.2 Condition Naming
Customize branch names.
2.3 Condition Details
Set object fields as entry criteria.
picture coming soon:
picture coming soon:
3. Task Collaboration Node
3.1 Description
Assign collaborators who must complete tasks before proceeding.
picture coming soon:
3.2 Assignees
Same options as approval nodes (personnel, roles, variables, APL, configuration tables). Supports fallback assignees.
3.3 Content Configuration
3.3.1 Approval Content
Configure object fields (required/read-only).
3.3.2 Process Layouts
Copy existing or create new layouts (based on object detail pages).
3.3.3 Editable Content
Toggle to allow approvers to edit configured content.
3.4 Button Settings
Reorder buttons (first 3 visible; others under “More”). Custom labels supported.
3.5 Node Timeout
Maximum duration per node.
3.6 Timeout Policies
Define actions when timeout occurs.
3.7 Additional Reminders
To-do lists and CRM alerts.
3.8 Post-Completion Actions
Field updates, notifications, code execution, etc.
picture coming soon:
picture coming soon:
4. Parallel Gateway Node
4.1 Description
Simultaneously routes tasks to multiple parallel nodes/approvers. Branches operate independently.
4.2 Other Settings
Refer to: Task Collaboration Node.
5. Wait Node
5.1 Delayed Wait
Pauses and resumes workflows at scheduled times.
5.2 Conditional Wait
Delays execution until conditions are met.
picture coming soon: