Skip to main content
Version: Next

Workflow Verification

Introduction​

The Verify workflow function is an automated analysis tool that examines the consistency and validity of your process before publication. It detects configuration errors, missing references, and inconsistencies that could prevent proper workflow operation.

This verification is accessible via the Verify workflow button in the "Edition" ribbon of the designer.

Consistency Report

The verification report is organized by element categories and uses a three-level severity system:

  • 🔴 Error: Blocks proper workflow operation (must be fixed).
  • ⚠️ Warning: Potential risk of malfunction (recommended to fix).
  • ℹ️ Information: Improvement suggestion (optional).

Verifications by Category​

1. Transitions (TR)​

Transition verifications ensure that the workflow flow is properly configured.

TR0001 - Element loops​

Severity: ⚠️ Warning
Description: Detects transitions that form a loop by returning to the same element without an alternative exit.

Problem: A transition that loops indefinitely on a step can create an infinite cycle.

Error example:
"Transitions should avoid looping on an element"

Solution: Verify that all steps have an exit to the next part of the process and that no infinite loops exist.

TR0002 - Notification configuration​

Severity: ⚠️ Warning
Description: Verifies that emails configured on transitions are properly set up.

Problem: A poorly configured notification (empty recipient, missing subject, empty body) will prevent email sending.

Error example:
"Transition notifications must be properly configured"

Solution: Open the transition properties (right-click → Notification) and complete all required fields (Recipient, Subject, Content).

TR0003 - Transition conditions​

Severity: ⚠️ Warning (inferred from context)
Description: Verifies that conditions defined on transitions exiting a gateway are valid.

Problem: A poorly formed condition or one referencing a non-existent field will cause a runtime error.

Solution: Verify that fields referenced in conditions exist in the form and that the syntax is correct.

TR0004 - Transition actions​

Severity: ⚠️ Warning (inferred from context)
Description: Verifies that automatic actions configured on transitions are valid.

Problem: An action that attempts to modify a non-existent field will fail silently.

Solution: Verify that all target fields of actions exist in the form.

2. User Tasks (UT)​

User task verifications ensure that manual steps are properly configured.

UT0001 - Non-editable required fields​

Severity: ⚠️ Warning
Description: Detects fields marked as required in a validation rule but that are not editable at this step.

Problem: The user will not be able to validate the step because they cannot fill a required read-only field.

Error example:
"Fields must be editable when they are required"

Solution: In the "Access Control" → "Fields" tab of the task, add the required field to the list of editable fields.

UT0002 - Unrecognized participants​

Severity: 🔴 Error
Description: Verifies that all participants (actors, roles, users) assigned to the task exist in the directory.

Problem: If a referenced participant doesn't exist, the task cannot be assigned and the workflow will remain blocked.

Error example:
"Participants must be recognized in the directory"

Solution: Verify that all referenced roles, actors, and users exist in the "Organization" module.

UT0003 - Participants neither actors nor services​

Severity: ℹ️ Information
Description: Reports participants that are neither actors nor services (e.g.: direct users).

Problem: Using direct users makes the workflow less flexible (if the user leaves the company, the workflow must be modified).

Error example:
"Participants should be actors or services"

Solution: Favor Actors (dynamically calculated) or Services rather than direct Users.

UT0004 - Inconsistent security level​

Severity: ⚠️ Warning
Description: Detects a validation rule configured with a security level lower than the task's global level.

Problem: If the task requires "Double signature" but a decision is configured as "Single signature", this creates an inconsistency.

Error example:
"The security level of a user task must be lower than that of its validation rules"

Solution: Harmonize security levels between the task and its validation rules.

UT0005 - Reminder configuration​

Severity: ⚠️ Warning
Description: Verifies that reminder rules (timers) configured on the task are properly set up.

Problem: A poorly configured reminder (empty email, invalid delay) will not work.

Error example:
"Reminder management for a user task must be properly configured"

Solution: Check the reminder configuration (right-click on the clock icon → "Reminder management").

3. Script Tasks (ST)​

Script task verifications ensure that automatic actions are valid.

ST0001 - Missing referenced actions​

Severity: 🔴 Error
Description: Detects references to library actions that no longer exist.

Problem: If an action has been deleted from the library but is still referenced in a script task, the workflow will fail.

Error example:
"Referenced actions must belong to the action library"

Solution: Open the script task and replace the missing action with an existing action, or recreate the action in the library.

ST0002 - Compilation errors​

Severity: 🔴 Error
Description: Verifies that the C# code of actions compiles correctly.

Problem: A syntax error or reference to a non-existent field will prevent task execution.

Error example:
"Code must not contain compilation errors"

Solution: Fix the C# code in the action editor. Check syntax and references to form fields.

4. Sub-processes (SP)​

Sub-process verifications ensure that calls to other workflows are valid.

SP0001 - Empty form reference​

Severity: 🔴 Error
Description: Detects sub-processes without an associated form.

Problem: A sub-process must create a document. Without a form, it's impossible to generate a sub-document.

Error example:
"Form reference must not be empty"

Solution: Open sub-process properties and select a form from the dropdown list.

SP0002 - Invalid form reference​

Severity: 🔴 Error
Description: The referenced form doesn't exist or has been deleted.

Problem: The system will not be able to create the sub-document.

Error example:
"Form reference must be valid"

Solution: Select an existing form in the sub-process properties.

SP0003 - Empty workflow reference​

Severity: 🔴 Error
Description: The sub-process doesn't reference any workflow.

Problem: The created sub-document will not start any process.

Error example:
"Workflow reference must not be empty"

Solution: Select the workflow to start in the sub-process properties.

SP0004 - Invalid workflow reference​

Severity: 🔴 Error
Description: The referenced workflow doesn't exist, is disabled, or has been deleted.

Problem: The system will not be able to start the sub-process.

Error example:
"Workflow reference must be valid"

Solution: Verify that the target workflow exists and is active. Update the reference if necessary.

SP0005 - Inheritance compilation errors​

Severity: 🔴 Error
Description: The C# code configured in field inheritance (parent → child mapping) contains errors.

Problem: Data will not be transmitted correctly from the parent document to the child document.

Error example:
"Code must not contain compilation errors"

Solution: Fix the code in the "Field Inheritance" tab of the sub-process.

5. Events (EV)​

EV0001 - Event notification configuration​

Severity: ⚠️ Warning
Description: Verifies that emails configured on timer events are properly set up.

Problem: A poorly configured automatic reminder will not be sent.

Solution: Check notification configuration in timer event properties.

6. Calls (CA)​

Note: This category appears in the report but has no active rules in the current source code. It is probably reserved for future verifications related to external service calls.

7. Miscellaneous (MC)​

MC0001 - Miscellaneous errors​

Severity: 🔴 Error
Description: Catch-all category for errors that don't fit in any other category.

Problem: XML serialization errors, corrupted properties, etc.

Example: Malformed XML property in an element.

Solution: Read the error message carefully. This may be data corruption requiring element recreation.

Best Practices​

  1. Check regularly: Run verification after each significant workflow modification.

  2. Fix errors first: Errors (🔴) block execution. Warnings (⚠️) may cause malfunctions.

  3. Test after fixing: After fixing errors, re-run verification to confirm the problem is resolved.

  4. Keep the report: Export or capture the report before modifying the workflow, this will facilitate debugging.

  5. Understand messages: Each message indicates the element concerned and the nature of the problem. Read them carefully.

Frequently Asked Questions​

Q: Can I publish a workflow with warnings?
A: Yes, but it's not recommended. Warnings signal potential risks that can cause production malfunctions.

Q: How long does verification take?
A: Generally a few seconds, even for complex workflows (20-30 steps).

Q: Does verification automatically fix errors?
A: No, it only detects them. You must fix them manually.

Q: What to do if I don't understand an error message?
A: Note the error code (e.g.: UT0002) and consult the corresponding section above for a detailed explanation.

See also: