Workflow Activities
This chapter details the configuration of the different steps (Activities) available in the designer.
User Task
This is the main activity, representing a human action (Validation, Input, Signature).
Participants (Stakeholders)
Participant management defines who can access the task and with what rights.
There are 3 types of participants:
Task Stakeholders
Role: These are the people who must process the task (validate, input, modify).
Assignment:
- Actors: Calculated dynamically (see section below).
- Roles: All members of a role (e.g., "Managers").
- Services: All members of a service (e.g., "Accounting").
- Users: People named directly (avoid for flexibility).
Behavior:
- Can receive a notification (email/portal).
- The task appears in their "To Process" list.
- Can modify the document according to the rights defined in "Access Control".
- Must validate or make a decision to advance the workflow.
[!NOTE] If multiple stakeholders are assigned, see the "Voting Rules" section to define how the final decision is made.
Additional Readers
Role: People who can view the document at this step without being able to modify or validate it.
Assignment: Same options as stakeholders (Actors, Roles, Services, Users).
Behavior:
- Can receive a notification (optional).
- Can view the document in read-only mode.
- Cannot validate or advance the workflow.
- Useful for keeping people informed (e.g., Management, Quality Service).
Use cases:
- Put the Director in copy of a Manager validation.
- Allow the Quality Service to track requests in progress.
- Inform the requester of progress without giving action rights.
Actor Types (Advanced)
Actors are dynamically calculated participants. Click the Add new actor button to create a custom actor.
You can define an actor based on:
| Type | Description | Example |
|---|---|---|
| Field content | The actor is the person mentioned in a form field. | "Manager" field contains "John Doe" → John Doe is a stakeholder. |
| Role member contained in field | All users having the role whose name is stored in a field. | "Validator_Role" field contains "Managers" → All Managers are stakeholders. |
| Role name | All users having a specific role named directly. | "Directors" role → All Directors are stakeholders. |
| Role member | All users belonging to a role selected from a list. | Selection of "Accountants" role → All Accountants are stakeholders. |
[!TIP] Favor dynamic actors (Field content) for more flexibility. For example, a "Manager" field in the form allows automatic reassignment of the task to the right manager without modifying the workflow.
Advantages of dynamic actors:
- Flexibility: No need to modify the workflow if people change.
- Reusability: The same workflow adapts to different services/teams.
- Hierarchy: Allows automatic following of organizational hierarchy.
Concrete example:
Form: "Leave Request"
Field: "Direct_Manager" (type: Person)
Actor: "Requester's manager" → Content of "Direct_Manager" field
→ Regardless of who makes the request, their direct manager automatically becomes the stakeholder for the "Manager Validation" step.
Validation Rules
Defines the buttons available to the user (e.g., "Validate", "Reject", "Request correction").
Simple Decisions
You can customize button labels.
These buttons are available to the user at the record level:
Voting Rules (N-ary Validation)
If multiple people need to validate the same step, how is the final decision made?
- Wait for all signatures: The step only ends when everyone has responded.
- Routing rules: For example, "Validated unless at least 1 Rejection".
Access Control (Security)
For each task, you define precisely what the user can do on the document.
Fields
You can restrict field visibility or modification.
- All fields modifiable: Ideal for an initial drafting step.
- Only these fields: For a validation step, only leave open "Comment" or "Validation date" fields.
- Mandatory input at this step: You can force field input specifically for this step (different from global form rules).
Attachments
Do you authorize the user to add or delete files?
- Checked: Modification authorized (Add/Delete/Versioning).
- Unchecked: Read-only (Download only).
Detail Tables
Manage line-by-line rights for tables (e.g., Order lines).
- Consultation: View the table.
- Addition: Add a new line.
- Modification: Modify existing cells.
- Deletion: Delete lines.
Advanced Properties of Validation Rules
Validation rules offer advanced parameters for each available action (decision).
Configuration is done via 3 tabs:
"Action" Tab
Role: Defines the decision behavior.
Available parameters:
| Parameter | Description | Usage |
|---|---|---|
| Label | Text displayed on the button in the user interface. | E.g., "Validate input", "Reject request". |
| Name | Internal identifier saved in workflow history. | E.g., "Validate drafting", "Manager rejection". |
| Comment input | Forces/Allows the user to justify their decision. | Options: Mandatory, Optional, Hidden. |
| Client validation control | JavaScript script executed client-side before validation. | Advanced validation (format, calculations). |
Example:
Label: "Approve"
Name: "Director Approval"
Comment: Mandatory
→ User sees an "Approve" button and must enter a justification comment.
[!NOTE] The "Name" appears in document history and serves as a reference for transitions (conditions).
"Mandatory Fields" Tab
Role: Defines which fields must be filled before being able to click on this specific action.
How it works:
- Select the action (decision) from the left list.
- Check the fields that must be filled for this action.
- Independent of mandatory form fields: you can make fields mandatory only for certain decisions.
Usage example:
Workflow: Purchase Request
Actions: "Validate" / "Reject"
Configuration:
- "Validate" action → Mandatory fields: "Approver(s)", "Approval date"
- "Reject" action → Mandatory fields: "Rejection reason"
Result:
- If user clicks "Validate" without filling "Approver(s)" → Blocking error.
- If user clicks "Reject" without filling "Rejection reason" → Blocking error.
[!TIP] Use this feature to guide the user and guarantee data completeness according to the chosen path.
"Visibility" Tab
Role: Restricts display of this action (decision) to certain roles only.
Configuration:
Section 1: Select roles
- Check roles for which this action is visible.
- Default: All roles see all actions.
Section 2: Configure rules (Advanced mode)
- Simple mode: Only checked roles see the action.
- Advanced mode: Add conditions to show/hide the action based on form content.
"Add condition" button: Allows creating rules like:
- "Show 'Validate' only if Amount < €10,000"
- "Show 'Director Approval' only if Requester = Finance Service"
Option: Hide action on Mobile Studio
- If checked, this action does not appear in the mobile application.
- Useful for complex actions requiring a large screen.
Other Advanced Task Properties
Keep Window Open
Option: Available in general task properties.
Behavior:
- Enabled: After validation, the document window remains open.
- Disabled (default): The window closes automatically after validation.
Usage:
- Useful if the same user chains multiple steps (e.g., Drafting → Verification by the same person).
- Practical during testing to immediately visualize the next step.
Task Security Level
Option: Overrides the global workflow security level for this specific task.
Available levels:
- Global: Uses the level defined at workflow level.
- None: No signature required.
- Simple: Password only.
- Double: Login + Password.
Use cases:
- Workflow in "Simple signature" by default.
- "Final approval" step configured in "Double signature" to strengthen security.
[!WARNING] Ensure that the task security level is consistent with regulatory requirements (e.g., qualified electronic signature).
Script Task
Executes C# code server-side. This is a system step, invisible to users. The code library is available in the Action Library section.
Common uses:
- Calculate a complex value.
- Call an external database (ERP, CRM).
- Generate a PDF document.
- Modify folder access rights.
[!WARNING] The script executes with "System" service rights (not those of the connected user).
Sub-Process
Allows calling another workflow from the main workflow.
- Interest: Reuse logical blocks (e.g., "Payment circuit") in different processes.
- Inheritance: You can map fields from parent process to child process.
- Escalation: Allows waiting for all sub-processes to end before continuing the parent.