Process Properties

Process Properties manage various settings for a process, encompassing both basic and advanced attributes.

Figure 3.7–19 Process Properties Configuration Page

3.7.5.1 Basic

3.7.5.1.1 Default Settings

• Notifications: Notification settings control who receives alerts at different stages of the process.

  • Notification After Process End: Supports notifying the initiator and/or all approvers. "Notify All Approvers" includes everyone who generated and handled a To-Do task, such as those involved in approvals, rejections, add-signs, add-sign returns, supplemental approvals, and communication replies. By default, only "Notify Initiator" is selected.
  • Process Anomaly Notification: Supports notifying privileged users and/or the initiator. By default, neither option is selected.
  • Initiator withdrawal notification: Supports notifying the current handler of the node.

• Process Handling: These settings govern how the process behaves during its flow, particularly concerning handler assignments and process circulation.

  • When Two Nodes Have Duplicate Identity: Supports two options: "Skip Subsequent Nodes" or "Skip Preceding Nodes." "Skip Subsequent Nodes" is selected by default. This is primarily used when "Skip if adjacent handler identity duplicates" or "Skip if handler identity duplicates" is configured in Node Properties – When Duplicate Identity, causing the system to skip the downstream or upstream nodes of the configured node.
  • Handler Exclusion Settings: Personnel selected here will be automatically filtered out when an approver performs operations like delegation, communication, pre-approval, post-approval, or distribution during the process flow.
  • Handler Scope Settings: For free-flow processes, handlers can only be selected from this defined scope.
  • Role-to-User Mapping: A feature that automatically resolves departmental roles (positions) into specific users when a process node is assigned to a role rather than an individual. Used at the template level to control whether node handlers with position configurations are resolved to individuals.
    • When a process node is configured to be handled by a departmental role (e.g., "Department Manager" or "Finance Approver"), the system will automatically expand that role into the actual users who hold that role at runtime.
    • If multiple roles are assigned to the same node, the system will resolve all relevant users across those roles.
    • The system uses the global "Role-to-User Mapping" settings by default, ensuring consistency across workflows unless overridden at the process level.
  • Allow Circulation After Process End: This switch controls whether relevant personnel can circulate the process after process ends. It's enabled by default.
    • Circulation Settings: "Initiator" is selected by default. You can also select "Participants" (includes all relevant personnel in the process) to allow them to initiate circulation after the process ends.
  • Circulatable Organization Settings: Used at the template level to control the organizational scope for circulation recipients.
    • Options: "System Default" (follows circulation mechanism configuration), "Full Organizational Structure," "Own Organization," "Own Department," "Custom." "System Default" is selected by default.
  • No Withdrawal After Rejection: Disabled by default. When enabled, withdrawal is not allowed after rejection.
  • Number of transfers: Limits the number of transfers during the process. For example, if A transfers to B and B transfers to C, it counts as 2 transfers. The transfer option will be grayed out when the limit is reached.

• Group Chat

  • Disabled by default.
  • If the system is integrated with DingTalk, enabling this allows selection of a pre-configured scenario group template from the DingTalk integration backend. This template is used for sending interactive cards via group bots when creating DingTalk groups.If the system is integrated with Feishu, simply enable it.

  Tips: If the DingTalk integration switch is turned off in Basic Settings - Default Settings, the group chat configuration in Process Properties will also be hidden.

• Approval Comment: "Highlight Display" allows selected approvers' comments to be displayed in a specific color during process approval.

• Process Privileged User: Process Privileged Users can intervene in the process flow through high-privilege operations such as tracking the process, modifying handlers, or handling exceptions. Process Privileged Users can be selected from the organizational structure or acquisition via the formula editor.

  • Batch Update Historical Process Instances: Allows batch updating historical process instances generated from this template. This enables the new privileged users to intervene in the flow of historical process instances.
  • Form Permission: Supports "View (All)," "View (Masked)," "Edit," and "Delete." "View (All)" is selected by default.

3.7.5.1.2 Timeout Settings

Timeout policies are used are used to monitor scenarios requiring specific approval times for nodes and processes. Timeout policies are divided into node timeout policies and process timeout policies.

• Add Timeout Policy:
  • Policy Name: Name the timeout Policy for easy identification during Process Node usage.
  • Conditions: Options include approval node, approval task, and unfinished subprocess.
    • Approval Node: Triggers the timeout policy and executes configured actions if the current process has not ended and the handler at the current node remains unhandled after a specified duration (days, hours, minutes).
    • Approval Task: Triggers the timeout policy and executes configured actions if the current approval task remains unhandled after a specified duration.
    • Unfinished subprocess: Triggers the timeout policy and executes configured actions if a sub-process initiated by the current process has not ended after a specified duration.
  • Execute Action
    • Notification Actions: Notify Initiator, Notify Privileged User, Urge Handler.
    • Operation Actions: Auto Skip, Auto Transfer, Rollback to Previous Node, Rollback to Drafting Node.
  • Tips:
    • If the timeout condition type is "Approval Task," the "Operation Actions" will include "Rollback to Previous Task."
    • If the timeout condition type is " Unfinished Subprocess," the "Operation Actions" will lack "Rollback to Previous Node" and "Rollback to Previous Task."

Figure 3.7-20 Timeout Policy Configuration

• Execute Action
  • Urge Handler: If the handler at a node has not completed the task within the specified deadline after the node starts, the system automatically sends a notification urging the handler to process it promptly.
  • Notify Initiator: If the handler at a node has not completed the task within the specified deadline after the node starts, the system automatically sends a notification to the initiator.
  • Notify Privileged User: If the handler at a node has not completed the task within the specified deadline after the node starts, the system automatically sends a notification to the privileged user.
  • Auto Skip: If the handler at a node has not completed the task within the specified deadline after the node starts, the process automatically skips this node and proceeds to the next. Different timing schemes have different skip rules:
    • Node Start: If the handler at the current node does not process within the deadline after the process flows to this node, the process automatically skips this node and flows to the next. (Tip: If the node flow is sequential, and two approvers A and B are set, B's expiration deadline includes A's processing time, i.e., B's processing deadline = node processing deadline - A's processing time).
    • Task Start: If the handler at the current node does not process within the deadline after the process flows to this node, the process automatically skips this handler and flows to the next handler or next node. (Tip: If the flow is sequential, and two approvers A and B are set, B's expiration deadline does not include A's processing time, i.e., B's processing deadline = node processing deadline).
  • Auto Transfer: If the handler at the current node does not process within the deadline after the process flows to this node, the process automatically transfers to the configured handler.
  • Rollback to Previous Node / Rollback to Drafting Node: If the handler at the current node does not process within the deadline after the process flows to this node, the process rolls back to the previous node or the draft node, according to the execution action. The next node of a starting branch cannot execute a rollback to the previous node, or it will not execute a rollback if skipped due to identity duplication or an empty handler.
  • Rollback to Previous Task: If the process flows to the current node with multiple handlers processing sequentially, and a handler does not process within the deadline, the process rolls back to the previous task according to the execution action.

3.7.5.2 Advanced

3.7.5.2.1 Listener

Listeners are primarily used to monitor changes in process instance events (e.g., process start event, process end event), process node events (e.g., node entry event, node exit event), and process task events (e.g., initiator submission/abandonment/urging events). When a corresponding change occurs, the system executes specified operations.

For detailed listener operations, refer to section 3.7.2.1.3 Listener Configuration (Note: This refers to an external section not provided in the current document).

3.7.5.2.2 Process Validator

Process Validators are primarily used to ensure that certain conditions are met before allowing corresponding operations during the process flow. If conditions are not met, the operation is blocked.

• Validator Name: Name the validator for easy identification during process usage.
• Process Operation: Currently supported operations include: Submit (for initiator), Approve, Reject, Withdraw, Transfer, Communicate, Cancel Communication, Pre-approval, Cancel Pre-approval, Return Pre-approval, Post-approval, Node Pause, Node Wake-up, Collaborate, Cancel Collaboration, Reply Collaboration, Abandon.
• Node Scope: Can be set to "All Nodes" or "Manual Nodes."
  • "All Nodes" means all nodes in the process flow must satisfy the validation conditions to allow the corresponding operation.
  • "Manual Nodes" means specific manual nodes in the process flow must satisfy the validation conditions.
• Selection Type: Supports selecting "Call Integration Method."
• Select Integration Method: Supports selecting interfaces from the integration platform.
• Integration Method Settings: Configure the mapping relationship for the interface's input parameters, as well as the validator's result and prompt message.

3.7.5.2.3 Template Properties

Template Properties are fundamental attributes of the process template. Settings here do not follow the version and take effect immediately upon saving. All versions of the template share these properties.

• Notification: Used to set Message Notification for the template.
  • Notification Method: Sets the message notification method for notifying approvers during process flow. If the node has configured a Notification Method, the Node's Settings take precedence.
  • Allows customization of notification methods, supporting To-Do, Email, DingTalk Work Notification, and SMS.
• Message Category Code: Used to assign a corresponding message category to the process template.
• Tag: Used to label and identify the corresponding template.
• Scheduled Process Initiation: The scheduled process initiation feature is only enabled when the switch is turned on in Settings.
  • Timer Settings: Settings
    • Initiation Time: The scheduled time for the process to be initiated.
    • Repeat Cycle: Sets the repetition period for process initiation (Non-repeating, Daily, Weekly, Monthly, Annually).
    • End Repetition: After reaching the End Repetition time, the process will no longer automatically initiate.
  • Settings
    • Form Initial Value: Settings the initial values for form fields when the process is scheduled to initiate.
    • Message Notification Method: After the process is scheduled to initiate, the Initiator and corresponding Handler will be notified based on the configured Notification Method.
    • Skip Drafting Node: By default, this is turned off, and the process automatically initiates a draft. When enabled, the process initiation will skip the Drafting Node.
    • Initiator: Configuration the Initiator for Scheduled Process Initiation (supports multiple selections).

Figure 3.7–21 Scheduled Process Initiation Settings

• Summary Approval: Disabled by default. If enabled, key fields will be displayed in the Approval Center's To-Do list and summary approval lists, allowing handlers to quickly view critical process information. This setting does not follow the process version and takes effect immediately upon saving.

Figure3.7 –22 Approval Center List Displaying Key Fields

• Approval Mode Settings: You can configure the approval interface by choosing one of two main options:
  • System Default: Select this radio button to use the standard approval layout.
  • Customize: Select this radio button to choose a specific layout for the approval interface. When Customize is selected, you can choose one of the following five display modes:
    • Right-side approval card mode: Displays the approval options in a card on the right side of the screen.
    • Right approval button mode: Places the approval buttons on the right side.
    • Top Approval Bar Mode: Shows a bar with approval options at the top of the screen.
    • Bottom Approval Bar Mode: Shows a bar with approval options at the bottom of the screen.
    • Bottom Approval Card Embedding Mode: Embeds an approval card at the bottom of the interface.

Figure3.7 –23 Approval Mode Settings

• Other:
  • Process Owner: Used for template/approval efficiency statistics, not for process approval. Single-person selection, saved in real-time.
  • Primary Responsible Department: Used for template/approval efficiency statistics, not for process approval. Single-department selection, saved in real-time.
  • Process Help: Used to display process help information during runtime. Disabled by default.

3.7.5.2.4 Smart Approval

Intelligent Approval allows setting approval rules that enable the process to execute automatically based on these rules. When conditions are met or not met, the system can perform automatic actions (e.g., Approve, Transfer, Rollback to Previous Node, Rollback to Drafting Node) and automatically fill in approval comments.

• Smart Approval rules are divided into Template Rules and User Rules. Template maintainers can centrally manage the template rules for a given template. In addition to simple rule configuration, they can use the formula editor and script writing functions to set complex rules, which follow the process version. Furthermore, template maintainers can view, disable, and enable all user-configured personal approval rules under that template.
• User rules take precedence over administrator-configured template rules. If a matching rule execution fails, it will be handled manually. If the last rule executed is configured to "Execute Subsequent Rules," it will also be handled manually.
• Configurations
  • Rule Name: Name the approval rule.
  • Process Template: The process template to which the approval rule belongs. Defaults to the current process template and cannot be modified.
  • Process Node: The process node(s) to which the approval rule applies. If empty, it applies to the entire process.
  • Approver Scope: Limits the scope of approvers to whom the approval rule applies. If empty, there are no personnel restrictions.
  • Rule: Click to display the conditional branch formula editor and configure the approval rules.
  • Rule Matched: Set the processing method if conditions met. If the approval rule execution result returns true, this method is executed. Supports operations such as Auto Approval, Auto Transfer, Rollback to Previous Node, Rollback to Drafting Node, Manual Handling, Execute Subsequent Rules.
  • Rule Mismatched: Set the processing method if conditions not met. If the approval rule execution result returns false, this method is executed. Supports operations such as Auto Approval, Auto Transfer, Rollback to Previous Node, Rollback to Draft Node, Manual Handling, Execute Subsequent Rules.
• Example Scenario: Taking a budget approval process as an example. If the estimated expense is less than 50,000, the result is "met," and the approval is automatically passed. If the estimated expense is greater than or equal to 50,000, the result is "not met," and it is automatically transferred to the department's superior leader.

3.7.5.2.5 Smart Check

The Smart Check helps users perform business logic judgments during form filling and process approval. By pre-setting alert rules during process design, the system provides check results as a basis for handlers' decisions during runtime and can affect page submission.

• Configurations

  1. New Template: Enter a template name to create a new check template, then proceed to the check component configuration page.
  2. Edit Template: Enter the edit check template details page.
  3. Apply Node: Set the node(s) where the check template will take effect. Options: "Unspecified " or "Specified Nodes." If a node is configured with both "Unspecified" and "Specified Nodes" check templates, only the "Specified Nodes" template will take effect. A single node cannot be configured with multiple check templates simultaneously.
  4. Delete Template: Click to delete the corresponding check template.

• Check Component Configuration

  1. Click "New" or "Edit" to enter the check component configuration page.
  2. Select "Business Components - Process Platform - Smart Check" and drag it to the canvas area.
  3. Select the component on the canvas to configure its basic information.

• Check Item Configuration

  1. In the "Check Component Basic Information - Content - Data" section, click "New" to enter the check item configuration page.
  2. Check Item Name: Set the check item name (visible at runtime on the frontend).
  3. Check Content: Set the details of the check item (not visible at runtime on the frontend).
  4. Reference Third-Party System Interface: Disabled by default. If enabled, you can select an interface from the integration platform.
  5. Condition Settings: Click to display the conditional branch formula editor and configure the check conditions.
  6. Condition mismatch: If the condition setting returns false, the content specified for "not met" will be executed.
  • Only Remind: Displays an alert at runtime. The instance can still be submitted after secondary confirmation.
  • Cannot Submit: Displays a non-compliant message at runtime and prevents instance submission.
  7. Prompt Message: Displays this message at runtime if conditions are not met.
  8. Associated Document: Supports adding local documents, displayed at runtime if conditions are not met.
  9. Associated Link: Manually enter a link; clicking it at runtime will redirect. Displayed at runtime if conditions are not met.

• Scenario Example: Checking employee's reimbursement amounts. Configuration steps are as following:

  1. Configure the check template, check item, and applied node.
  2. Publish the process template.
  3. On the frontend, select the process template, create a new instance, and enter a total amount greater than 1500. The check validation will fail, and instance submission will be disallowed.
  4. Modify the amount. If the total amount is less than or equal to 1500, the check validation will pass, and the instance can be submitted normally.

3.7.5.2.6 Signal Capture

Process-level signal event rule settings. During process runtime, when a signal event occurs, it will trigger the configured method or action.

• Signal Capture Name: Used to name the Signal Capture.
• Select Signal: Drop down to select a process signal (Template Center - Process Signals).
• Signal Source: Can be set to Current Process, Parent Process, or Sub Process.
• Node Scope: Settings can be applied to All Nodes or Nodes within the current template Process Diagram.
• Matching Rules: Used to match the corresponding process signals. The Signal Capture will only execute when the conditions are met.
• Execute Action: Can be set to Flow Downstream, Business Methods, Jump Forward/Backward, End Current Process, or Abandon Current Process. When the corresponding process signal is matched, the specified action will be executed.

3.7.5.2.7 Email Approval Template

Displays email approval templates already created within the process template. Currently, this feature only applies to systems integrated with Exchange mailboxes.

• New Email Template: Click the "New" button to enter the email template body configuration page. Data items already added in the form design are automatically included by default. Simple adjustments can be made to the display/hide status and layout of these data items within the email.
• Node Reference Email Approval Template: Approval nodes can enable email approval in "Node Properties - Advanced" and bind the corresponding approval template. Email approval cannot be enabled if the node's data permissions require mandatory fields, mandatory modification by handlers, or if the next node is a manually selected node.