Published at: 2026-09-17
04-configure-business-process-countersign-nodes.md
Configure a business node that requires multiple users to approve together, so the process enters the next step after all countersigners handle it.
Overview
A countersign node is used when multiple users must jointly confirm the same business matter. Compared with an Approval Node, a countersign node focuses on joint decisions by multiple users. It usually assigns the task to multiple handlers, who approve the same Business Data separately.
After you select a Co-signature node on the process canvas, configure Node Settings on the right, including countersign node name, business description, approval object, countersign content, countersign conditions, handlers, default handler, whether all approvers must approve, button name, and timeout rules.
Core configuration for a countersign node includes:
- Which Business Data to countersign.
- Configure countersign content or editable fields.
- Who countersigns the task, and how to provide a fallback when the handler is empty.
- Whether all approvers must approve before the node ends.
- Which path to enter after agreement or disagreement.
- Whether the handler can edit node content.
- Whether the handler can specify the next-node handler when the node is completed.
Before you begin
- You have created a Business Process and opened the process canvas configuration page.
- You have confirmed the business object that requires joint confirmation in the current node, such as Work Order, Account, Opportunity, Quote, or Related Object.
- You have confirmed countersigner rules, the default handler, and timeout requirements.
- You have confirmed the routing path after agreement and disagreement.
- If countersigners need to edit content, confirm field permissions, required rules, and page display requirements first.
Configure Node Settings
Select the countersign node on the process canvas. Then configure these items on the Node Settings tab on the right.
| Configuration item | Description |
|---|---|
| Node name | The name of the current countersign node on the canvas, in To-Do tasks, and in process records. Use an action-oriented name, such as Work Order countersignature or Quote countersignature |
| Business description | Describes the countersign matter and helps handlers understand the countersign context. The limit is 500 characters |
| Which Business Data to approve | Selects the data countersigned by the current node. Options include current object, related data, and process-related Business Data |
| Configure editable fields | Sets content that countersigners can edit in the node task. Options include no content, custom form, and process layout |
| Configure countersign content | Sets the countersign content to display or fill in, such as object fields, rich text, or collaborative rich text |
| Allow editing of configured node content | Lets countersigners directly edit configured node content during handling |
| Countersign conditions | Configures routing paths after agreement and disagreement. Routing by countersign result is supported |
| Who approves this business task | Sets node countersigners. You can select personnel, roles, or variables, or calculate by APL code or configuration table |
| Default handler when the handler is empty | Specifies a fallback handler when countersigner rules do not match valid users |
| Handler can specify the next-node handler when the node is completed | Allows the current countersigner to specify the next-node handler at completion |
| All approvers must approve | When selected, the node waits until all countersigners complete handling before it ends |
| Set button name | Sets the main button label on the To-Do handling page, such as Approve, Disapprove, or Submit countersignature |
| Task timeout duration | Sets the node handling deadline for reminders or exception handling |

Configure the countersign object
A countersign node must first define which business object the node countersigns and which data record countersigners handle.
- In Node name, enter a countersign name that handlers can understand.
- In Business description, describe the countersign goal.
- In Which Business Data to approve, select the data countersigned by the current node.
The countersign object defines the process context. When countersigners open the To-Do task, the system displays the information that must be handled based on this object.
Configure countersign content
A countersign node can display or collect countersign content. Common Content Type options include:
| Content type | Description |
|---|---|
| No content | The countersign page does not show extra countersign content. Use this when countersigners only need to agree or disagree |
| Custom form | Manually select fields to display and edit in this node. Use this for a small number of key fields |
| Process layout | Uses a process layout to display countersign content. Use this to reuse a unified form layout |
In Configure countersign content, select the content type to display and configure the related fields.
To let countersigners directly modify countersign content, select Allow editing of configured node content. If the countersign content includes key fields, check field permissions and required rules.
Configure handling actions and routing
The core of a countersign node is controlling which path the process enters after agreement or disagreement, and whether the node waits for all countersigners.
- In Countersign conditions, configure routing paths after agreement and disagreement.
- If agreement enters the next step, select the target node or path after agreement.
- If disagreement must return for correction, select the target node or path after disagreement.
- To run different processing for different results, configure post-actions.
- If the business requires all countersigners to approve before the node ends, select All approvers must approve.
Use a countersign node when multiple users must all confirm before the process continues. If only one handler needs to decide approval or rejection, use an Approval Node.
Configure countersigners
The countersign node handler determines who receives the node To-Do task. Countersigner configuration supports these methods:
| Method | Description |
|---|---|
| Select people, roles, or variables | Directly select colleagues, roles, or process variables. Use this for common countersign rules |
| Based on APL code | Dynamically calculate countersigners with code. Use this for advanced organization, region, or business rules |
| Based on configuration table | Match countersigners by configuration table. Use this for product line, area, Account Type, and other rules that operations teams maintain |
Configuration steps:
- In Who approves this business task, select the countersigner configuration method.
- Select or add specific countersign rules, such as the process Initiator’s manager, Account owner, department head, or specified role.
- If countersigners might be empty, add fallback users in Default handler when the handler is empty.
- To let the current countersigner specify the next-node handler, select Handler can specify the next-node handler when the node is completed.
- To change the To-Do page button label, enter a button name in Set button name.
If the process requires fixed-position countersignature, use roles or configuration tables. If it requires dynamic countersigner identification, use variables or APL code.
Configure timeout and reminders
A countersign node can set how long the task stays before timeout. Use this to remind countersigners to handle tasks on time or to trigger exception handling.
- In Task timeout duration, set the node handling deadline.
- To configure timeout reminders or automatic handling, continue in related reminder or Expiration Strategy settings.
- Save the node configuration.
Timeout settings are suitable for Work Order SLA, Account grading countersignature, Quote countersignature, and document completion countersignature. For key countersign nodes, configure reminders and a default handler to prevent stuck processes.
Configure completion conditions
Countersign node completion conditions control whether countersigners can complete the current node. Countersign nodes support field-based and APL-code-based completion conditions.
| Condition type | Description |
|---|---|
| Based on fields | Use for rules such as required fields or status updates |
| Based on APL code | Use for cross-object validation, advanced calculations, or combined rules |
You can configure custom Notice text to help countersigners understand completion conditions.
Configure post-completion actions
After a countersign node is completed, you can configure post-actions to update data or trigger later operations. Common post-actions include field update, SMS notification, Initiate Business Process, Email Notifications, External Notification, Execute APL code, Change Owner, data lock or unlock, create task, create schedule, New Sales Record, Sales Records, change team members, variable assignment, and Conversion Rules.
For more post-action configuration, see Configure post-Business Process actions.
Configuration recommendations
- Use countersign node names that make the result clear, such as Work Order countersignature or Quote countersignature.
- Keep countersign content concise. Show only the information needed for the node decision.
- Configure a default handler for key countersign nodes to prevent empty countersigner rules from blocking the process.
- If countersign results enter different paths, check the agreement and disagreement connectors first.
- If countersigners can edit node content, check field permissions and required rules.
- After you configure completion conditions and post-actions, validate the full path with test data.
Expected result and validation
- Start a test Business Process.
- Use a countersigner account to open the countersign node task.
- Check whether the node name, countersign content, button name, and editable fields match the configuration.
- Test agreement and disagreement paths separately.
- Check whether the node ends based on the All approvers must approve rule.
- Check whether completion conditions restrict node completion as expected.
- Check whether post-actions run.
- If you configure timeout, default handler, or next-node handler assignment, validate each scenario.