3.7.2-process-node

3.7.2 Process Node

Node types include: Approval Nodes, CC Nodes, Signature Nodes, Voting Nodes, Robot Nodes, Subprocess Nodes, Embedded Subprocess Nodes, Flexible Subprocess Nodes, Auto-authority Subprocess Nodes, Conditional Branches, Manual Branches, Parallel Branches, Rule Block Subprocess Nodes, Signal Waiting Nodes, Dummy End Nodes.
These node types are designed to cover virtually all standard business use cases.

3.7.2.1 Common Node Properties

While each node has unique properties, they also share common settings.

3.7.2.1.1 Node Name

The Node Name is required. When a node is added to the canvas, it has a default name that can be modified for business needs.

3.7.2.1.1 Node Help

Node Help is an optional field used to provide notes about the current node.

3.7.2.1.2 Data Permission

Data Permission sets the usage permissions of a node’s form fields.
Click Data Permission → Open Data Permission to configure detailed read/edit/required settings for each field.

For example: If the “Manager Approval” node is given Editable permission, managers can update fields like purchase amount and budget during approval.

3.7.2.1.3 Listener Configuration

Listeners monitor events at the process, node, and task levels (e.g., Process Start, Node Entry, Task Submission). They trigger actions such as Business Methods, Context Variable Assignment, Process Task Expansion, and Broadcast Process Signal.

Use Cases:

• Project management: Automatically generate a project record after approval.
• License management: Update license status upon approval.
• Task management: Update task status after confirmation.

Configuration Steps:

1. Go to the Listener Config tab and click Add Listener.
2. Name the listener.
3. Select the event type (e.g., Handler Approval Event).
4. Choose Business Methods as the Execute Action.
5. Select the corresponding Business Method.

Figure 3.7–8 Listener Configuration Steps

3.7.2.2 Approval Node

The Approval Node is the most frequently used node type, mainly for setting approvers.
Approvers can be selected from the organizational structure or defined via the formula editor.

Supports:

• Sequential approval
• Joint review (all must approve)
• Single approval (any approver can approve)
• Skipping duplicate identities

Adding Approval Nodes: Click on a node in the left panel or drag it onto the canvas.

3.7.2.2.1 Node Properties

Basic Info

a) Default Handler
Ways to assign node handlers:

• Directory Picker: Select personnel, positions, or groups from organizational structures.
• Formula Editor: Dynamically determine approvers via simple mode, expressions, scripts, or advanced mode.

Figure 3.7–9 Assign Default Handler

Additional options:

• Recalculate the handler when the process flows again: Dynamically updates handlers when organizational changes occur.
• Only allow adding new ones when modifying: Restricts modifications to adding new handlers only.

b) When No Handler
If no handler is found, options include: Auto Skip, Anomaly Report, or Designated Handler.

c) When Multiple Handlers

• Sequential Processing: Approvers act in the specified order.
• Processed by One of Them: Approved once all designated approvers review.
• Processed by All: Approved as soon as one approver reviews.

d) When Duplicate Identity

• Skip only when adjacent handlers are duplicates (default).
• Skip if the handler already approved earlier.
• Do not skip duplicates (flows normally).

Form Selection
Nodes can be configured to display specific forms, either system-designed or third-party integrated forms.

• Scene Associated with the Form: Default is auto-match; manual selection possible.

Figure 3.7–10 Form Selection Settings

e) Approval Comment Form
Allows configuration of special forms for approval comments.

Types:

• System Default: Single free-text field
• Reference Other Templates: From Process Platform → Basic Settings → Approval Comment Form
• Customize: From Low-code Platform → Form Mgt → Approval Comment Form

Additional features:

• Default Value: Pre-fill fields
• Data Sync & Aggregation: Sync approval form data with context variables
• Approval History Display: Control visibility of fields
• Process Configuration: Define operations triggered by comment form fields
• Approval Comment Display: Choose always visible or only after node ends

id: 3.7.2.2-approval-node-details title: Approval Node Configuration

Approval Comment Form Configuration

Approval Comment Forms allow detailed configuration for capturing structured comments during approval.

Figure 3.7–11 Approval Comment Form Configuration

Timeout Settings

You can create a new timeout policy or select one from the dropdown menu, sourced from:
Process Design → Process Properties → Timeout Settings

Example: If a manager does not approve a request within 24 hours, the process escalates to an alternate approver.

Time Limit Settings

When configured, handlers can view the remaining processing time on the approval page.
If the time limit is exceeded, the page is marked as timeout.

Timeout statistics are available at:
Process Platform → Process Analytics → Process Reports

Figure 3.7–13 Time Limit Settings

3.7.2.2.2 Operation Config

Operation templates define the naming of operation buttons for process nodes.

• Sourced from: Process Platform → Basic Settings → Operation Config → Approval tab
• Users may also click Edit Operation Settings to customize operations.

Figure 3.7–15 Operation Config in the Process Platform module

Operations Available for Initiator

• Withdraw: Return the process to the previous step.
• Abandon: Terminate the process. Approved nodes get a notification.
• Urge: Remind the next handler via a to-do notification.
• Circulate: Share the process with relevant personnel for review.
• Collaboration: Request assistance at the drafting stage; collaborators edit and submit.

Figure 3.7–16 Operations Available for Initiator During Process Runtime

Actions Available for Current Handler

• Approve: Pass to the next node.
• Transfer: Assign approval to another user.
• Communicate: Start discussions with organizational users.
• Abandon: Terminate the process.
• Reject: Return to a previous node.
• Pre-Approval: Add an approver before current handler.
• Post-Approval: Add approvers after current handler.
• Distribution: Share with others without altering flow.
• Node Pause / Reactivate: Temporarily halt/resume approval.
• Circulate: Share process for review.

Operations Available for Past Handler

• Withdraw: Allowed for Approve and Transfer before next handler acts.
• Urge: Notify current handler.
• Circulate: Share process for review.

3.7.2.2.3 Advanced

Figure 3.7–17 Advanced Settings

a) Extended Operations

• Modify handlers of downstream nodes.
• Options:
  • Nodes Can be Modified
  • Nodes Must be Modified

b) Modify Process Diagram

• Disabled by default.
• Allows adding new nodes during runtime (affects only current instance).

c) Permission to View Comment

• Disabled by default.
• Handlers can set comment viewing permissions.

d) Upload Comment Attachment

• Enabled by default.

e) Mobile Approval

• Enabled by default. Mobile-friendly approval.

f) Quick Approval

• Disabled by default. Allows batch approval from To-do list.
• Restrictions apply if required fields or review points exist.

g) Scheduled Approval

• Disabled by default. Groups tasks into scheduled batches.

h) DING Notification

• Enabled by default. Requires DingTalk integration.

i) Review Points Settings

• Add required review checks; prevents submission if unchecked.

j) Handwritten Signature Required

• Mobile-only. Disabled by default.

k) Urgency Level

• Disabled by default. Controls priority in handlers’ to-do list.
• Options:
  • Only Active for Next Task
  • Decided by the Initiator

Figure 3.7–18 Process Level Options for Process Initiator

l) Allow Additional Reminders

• Disabled by default.

Approval Settings

• Permission to View Approval Comment
  • Options: All Visible (default) or Partially Visible
• Recommended Handler
  • Options include Institution, Current Department, Org Structure, Formula Editor.

Push Notification

Figure 3.7–19 Push Content Settings Window

• Push Method: Default = system notification.
  • Customizable to include email, SMS, etc.
• Push Content: Configurable titles and messages.
  • Form Data and Process Data may be inserted.

3.7.2.3 CC Node

3.7.2.3.1 Application Scenario Overview

Use Cases:

• Notify payroll specialist after leave approval (record-keeping).
• Notify administrative staff after seal approval (archiving).

Recipients configured via Org Structure or Formula Editor.

3.7.2.3.2 Node Property Description

• Name: Display name of the CC Node
• No.: Unique ID (e.g., N6)
• Default CC Recipient: From Org Structure or Formula Editor
• Allow Comment Input: If enabled, CC handler can comment
• System Message Type: Options = To-Read (default) or To-Do
• Extended Operations – Process Circulation: If enabled, CC recipients can circulate
• When Handler Is Empty: Options = Auto Skip, Report Anomaly, or Designated Handler
• Select Form: Choose form linked to the node
• Form Application Scenario: Automatic or manual selection

Figure 3.7–61 CC Node Settings

id: 3.7.2.4-signature-voting-robot-branches title: Signature, Voting, Robot, and Branch Nodes

3.7.2.4 Signature Node

Purpose: Allows the handler to perform a Signature confirmation and add Approval Comments.

3.7.2.4.1 Application Scenario Overview

Use Cases

• Leader's signature required for new company establishment applications.
• Business owner's signature for development project requirement confirmations.

Scenario Example
In a new company establishment application, a leader's handwritten signature (mobile-only) is required for confirmation.

Operation Steps

1. Add a Signature Node and set the Handler.
2. Open Advanced Properties in Node Properties.
3. Enable Handwritten Signature Required.

3.7.2.5 Voting Node

Purpose: Allows handlers to Vote (Approve, Reject, Abstain).
The process moves to the next node when the vote count meets configured Voting Rules.

3.7.2.5.1 Application Scenario Overview

Use Cases

• Executives voting on a company policy.
• Experts voting on project initiation approval.

Scenario Example
In a project initiation process, the project is approved if ≥ 2/3 of experts vote in favor.

Voting Rules

• Conditions:
  • Reach Pass Rate (%)
  • Reach Pass Count
  • Reach Veto Rate (%)
  • Reach Veto Count
  • One-vote Veto
• Execute Action:
  • Flow Downstream
  • Jump Forward/Backward
  • Stay at Current Node
  • End Process
• Multiple Rules can be configured in order.
• If none match, configure a fallback Execute Action.
• Voting End Time:
  • Terminate Immediately on Condition Match
  • Terminate After All Votes

Tip: Pass/Veto rates must be between 0–100; counts must be integers.

Node Property Descriptions

• Basic Info: Node Name, No., Default Voters
• Voting Rules: Configurable as above
• When Handler Is Empty: Define fallback behavior

3.7.2.6 Robot Node

Purpose: Executes automated system tasks such as:

• Reading/writing form data
• Saving data to database tables
• Modifying document fields using Formula Editor
• Initiating subprocesses
• Calling RPA (Robotic Process Automation) tasks

Application Scenarios

• Project tracking: Auto-assign tasks on specific dates.
• Contract approval: Auto-fill supplier data from database.
• RPA integration: Robot performs tasks before process continues.

Scenario Example
A project tracking process flows to a responsible person on September 14th for updating phase content.

Implementation Effect
Add a Robot Node named “Pause and Wait for 14 Days to Wake Up”, causing an automated pause.

Operation Steps

1. Add a Robot Node and set its name.
2. Select Robot Type:
   • Execute Business Method (requires pre-configured methods)
   • Node Control
   • RPA Integration
3. Set Wake-up Time: Specific, Relative, or Custom via Formula Editor.
4. If RPA Integration:
   • Select Task
   • Configure Value Transfer (data mapping)
   • Choose Flow Method:
     • Pause and Wait (with return values)
     • Continue Flow (without waiting)

Node Property Descriptions

• Basic Info: Node Name, No.
• Robot Type: Business Method, Node Control, RPA Integration
• Node Anomaly Skip: Option to skip on anomaly
• Robot Settings:
  • Wake-up Time
  • Select Task (for RPA)
  • Flow Method
  • Return Value Settings (for Pause and Wait)

3.7.2.7 Conditional Branch

Purpose: Directs process flow based on pre-set branching conditions.

Application Scenarios

• Leave > 3 days → Supervisor + Department Head Approval
• Office supplies > 10 units → Department Manager Approval

Scenario Example
Leave request:

• ≤3 days → C.C. to Lily

• 3 days → Departmental Head Approval

Implementation Effect
Branch flows according to formula conditions in the Formula Editor.

Operation Steps

1. Add a Conditional Branch (e.g., Leave Days Judgment).
2. Add corresponding branch nodes.
3. Select Formula Editor for Startup Method.
4. Define conditions & name flow connections.

Example Conditions

• ≤3 days → Total (Days) ≤ 3

• 3 days → Total (Days) > 3

Node Property Descriptions

• Startup Method: Formula Editor or Matching Rules
• Flow when Conditions Do Not Match:
  • Default Direction
  • Otherwise process pauses

3.7.2.8 Manual Branch

Purpose: Allows manual decision of next process flow.

Application Scenarios

• Complex procurement project initiation
• Complex construction payment applications

Scenario Example
A procurement project requires manual intervention to decide the next step.

Implementation Effect
In Process Approval → Next Step, the user selects among manual branch options.

Operation Steps

1. Add a Manual Branch node.
2. Select the node deciding the flow.
3. Add subsequent approval nodes.

Node Property Descriptions

• Manual Branch Startup Method:
  • Decided by Previous Manual Node
  • Decided by Start Node
• Select Default Direction: Optional auto-selection; otherwise, handler chooses manually.

3.7.2.9 Parallel Branch

Purpose: Initiates multiple parallel flows requiring concurrent approvals.

Application Scenarios

• Employee exit handover requiring Dept, Admin, HR, IT, Finance approval
• Content publishing requiring multi-departmental approval

Scenario Example
Exit handover process splits into parallel flows: Department Work, Admin, HR, IT, and Finance.

Implementation Effect
Parallel approvals merge into a single node (e.g., Employee Signature).

Operation Steps

1. Add a Parallel Branch node.
2. Add Approval Nodes for each parallel path.
3. Select Startup Method:
   • All Start: All parallel branches run
   • Manual Decision: Previous Manual Node selects
   • Condition Match: Formula Editor or Matching Rules
4. Select End Method:
   • All End: Wait for all
   • Any End: Continue after first completion
   • Conditional End: Continue when condition met

Node Property Descriptions

• Basic Info: Node Name, No.
• Startup Method: All Start, Manual Decision, Condition Match
• End Method: All End, Any End, Conditional End

id: 3.7.2.10-advanced-nodes title: Advanced Process Nodes

3.7.2.10 Subprocess Node

Purpose: Automatically initiates one or more new process instances when the main process flows through it.
The main process may continue independently or wait for the sub-process status.

Application Scenarios

• HR Management: Contract renewal triggers multiple sub-processes for different employees.
• Procurement: Initiate sub-processes for each product in procurement details.
• Travel Expenses: Approved travel application triggers reimbursement process with auto-filled data.

Configuration Steps

1. Design Forms and Processes for main and sub-processes.
2. Add Sub-Process Node and name it (e.g., Initiate Reimbursement Approval).
3. Select Sub-Process Template from Process Management or other modules.
4. Sub-Process Initiation Settings:
   • Initiator: Select from directory picker or Formula Editor.
   • Skip Draft Node: Optionally bypass drafting.
   • Start Method:
     • Each Initiator Starts One Sub-Process
     • Only Start One Sub-Process
     • Start by Detail Table Row
5. Parent-to-Child Value Transfer: Map parent form fields to sub-process fields.
6. Child-to-Parent Value Transfer:
   • Update: Match and update rows.
   • Overwrite: Replace parent detail table rows.
7. Parent Process Flow Method:
   • Continue Flow
   • Flow After All Sub-Processes Complete
   • Flow After Single Sub-Process Completes
   • Continue Flow After Condition Met
8. Abandonment & Anomaly Notifications: Notify privileged user/initiator if abandoned or errored.
9. Child Process View Permissions: Option to allow child process initiator to view parent.

3.7.2.11 Embedded Sub-Process

Purpose: Allows embedding of multiple sub-process templates within a node.
Each embedded sub-process can have its own administrator and start rules.

Application Scenarios

• Project Personnel Requests: Centralized + subsidiary control.
• Policy Formulation: Sequential review across Admin, HR, Finance, Legal, then Senior Management.

Configuration Steps

1. Add Embedded Sub-Process Node.
2. Set Embedded Type:
   • Generic Fragment Set:
     • Select pre-configured fragment from Template Center.
     • Configure Data Mapping.
   • Non-Generic Fragment Set:
     • Add Sub-Process Templates with rules.
     • Set Template Name, Administrator, Start Rules via Formula Editor.

3.7.2.12 Free Sub-Process

Purpose: Provides semi-flexible templates where approvers can insert additional approval nodes.

Application Scenarios

• Official Document Processing: Secretary decides which leaders approve.

Configuration Steps

1. Add Free Sub-Process Node.
2. Set Node Name and Initial Handler.

Tip: Each node can only determine the handler of the next node. If not set, the flow continues to the next node after the Free Sub-Process.

3.7.2.13 Dummy End Node

Purpose: Provides flexibility by allowing independent branch termination without affecting the main process.

Application Scenarios

• Parallel Approvals: Branches may end independently while the main process continues.

Effect:
When the main branch ends, unapproved tasks in independent branches are reclaimed.

3.7.2.14 Signal Waiting Node

Purpose: Enables cross-process communication and conditional triggers.

Application Scenarios

• Cross-Process Collaboration:
  • Procurement triggered by insufficient parts in delivery.
  • Deposit action required on fund shortage.
  • Resignation triggers updates in other subsystems.

Configuration Steps

1. Design Process Diagram.
2. Configure Process Signals in Template Center.
3. Add Signal Waiting Node:
   • Signal Capture Name
   • Select Signal
   • Signal Source (This Process, Parent, Child)
   • Matching Rules
   • Execution Action (e.g., Continue Flow)
4. Configure Node Listener to release signals.

3.7.2.15 Auto-Authority Process

Purpose: References auto-authority templates to dynamically generate nodes at runtime.

Application Scenarios

• Leave Applications: Approvals determined via auto-authority template.
• Department Manager Notifications: Managers edit forms and send messages.

Configuration Steps

1. Add Auto-Authority Sub-Process Node and select template/version.
2. Configure Mapping between template and auto-authority.
3. Publish template.
4. Initiator selects template when starting process.

Node Property Descriptions

• Select Auto-Authority Template.
• No Matching Result → anomaly report or skip.
• Value Transfer Settings via Formula Editor.
• Strategy Matching: Supports data permissions & listener strategies.

3.7.2.16 Rule Block Sub-Process

Purpose: Generates process fragments dynamically based on specified rules (parallel, sequential, nested).

Configuration Steps

1. Add Rule Block Node to canvas.
2. Configure Parameter Settings:
   • Value Setting → Object Assignment
   • Reference a variable (e.g., DesignedForm.Multi-lineText)
3. Create New Instance: Enter JSON data → process fragments auto-generated.

3.7.2.17 Smart Review Node

Purpose: Configures inspection rules to detect non-compliant content and enforce actions.

Application Scenarios

• Cost Management: Reject budget > 100,000 back to Drafting.

Configuration Steps

1. Add Smart Review Node.
2. Configure Review Rules:
   • Formula Editor Rules
   • Smart Approval Assistant
   • Edit Inspection Items (Name, Content, Conditions, Warning/Block).
3. Configure Actions on Review Blockage:
   • Continue Flow
   • Manual Intervention
   • Forward/Backward Jump
   • Abandon Process
4. Create new instance and test.
5. View Smart Review Report in approval record.

3.7.2.18 Dynamic Sub-Process

Note: Requires enabling Advanced Process Node in Process Platform → Basic Settings.

Purpose: Dynamically generates sub-process fragments during runtime based on selected organizational scope.

Application Scenarios

• Joint Departmental Reviews: Upper-level designates departments → each runs its own approval.

Features

• Binds to dynamic generic fragments.
• Pre-sets organizational scope.
• Handler of preceding manual node selects send objects.
• Generates multiple independent sub-process fragments dynamically.

id: 3.7-dynamic-subprocess-and-free-jump title: Dynamic Sub-Process, Free Jump Node, Process Data, and Business Methods

Figure 3.7–20 Dynamic Sup-process

Application Scenarios:

• Departmental Joint Review: In a departmental joint review scenario, each department conducts independent approvals, and their internal approval progress may vary. Users can drill down into the process diagram to view detailed flow information for each department.

Prerequisites:

• A dynamic generic fragment must be configured and activated in "Process Platform - Process Fragments."
  • Within this fragment, the "Leader Approval" node needs to obtain the department leader of the joint review department.
  • The handler scope for this node is configured using the formula editor to retrieve the department leader of the dynamic organization.
  • The "Dynamic Organization" variable represents the specific department corresponding to the send object selected by the handler.

Configuration Steps:

1. Add Dynamic Sub-Process Node:
   Enter the process design interface, add a "Dynamic Sub-Process Node" to the canvas area, and configure its node properties.
   • Organization Source: Choose between "Previous Manual Node Designation" or "Default Organization."
   • Organization Scope:
     • Use Formula Editor: Define the organizational scope using the formula editor.
     • View Data Settings: Review the data settings for the scope.
   • Default Organization:
     • Use Formula Editor: Define the default organization using the formula editor.
     • View Data Settings: Review the data settings for the default organization.
2. Initiate New Instance (Frontend):
   The initiator creates a new process instance, fills in the "Joint Review Department" field on the form, and submits the instance.
3. Select Send Objects:
   At the "Document Processing" node, the next step is to select the "Department Joint Review" node and choose the send objects (e.g., specific departments).
4. View Instance Process Diagram:
   After submission, view the instance process diagram. Based on the N selected send objects, N independent process fragments will be dynamically generated.

Benefits:

This functionality is highly applicable to approval scenarios in government and enterprise sectors, such as official document issuance and reception. When a single matter requires collaborative approval from multiple departments, each department processes internally and provides a final opinion. By integrating with the form's "Approval" control, opinion lists can be summarized and presented on the form according to custom layouts and data filtering requirements, aiding subsequent approvers in their decision-making.

---

3.7.2.19 Free Jump Node

The Free Jump Node allows for flexible transitions between nodes, making it suitable for scenarios where process flow requires manual decision-making, and approval steps are uncertain or involve multiple revisions.

Example: A company document might be received by a secretary, then signed by a leader, and then confirmed by the secretary again.

This node supports multiple incoming and outgoing connections without restrictions. During approval, the node handler can specify which single outgoing connection to follow and who will approve the next step. The selectable personnel/organizational scope can be restricted during the design phase.

Node Property Description:

• Default Handler: When a non-free jump node flows into this node, the default handler is automatically identified.
• Handler Scope: When another free jump node flows into this node, one person from the jump scope's personnel set will be selected as the handler. Handlers can be chosen from the organizational structure, formula editor, or leader's secretary. For leader's secretary, specific groups can be configured; if no group is selected, all leader's secretaries will be set as the handler scope.
• Next Step: Configure the next selectable node(s) when flowing out of this node. It supports conditional matching for selectable nodes. If no condition is configured, the flow is visible by default. If a condition is configured, the flow can only be selected when the condition is met.

Application Scenarios:

• Company Document Flow: A company document might be received by a secretary, then signed by a leader, and then confirmed by the secretary again, involving back-and-forth approvals.

Configuration Steps:

1. Add Free Jump Node:
   Enter the process design interface, add a "Free Jump Node" to the canvas area, and configure its node properties.
2. Initiate New Instance (Frontend):
   The initiator creates a new process instance and selects the send object(s), then submits the instance.
3. View Instance:
   View the instance. The user will have the option to choose the next step for the process.