Overview
This document establishes the mandatory best practice standards and configuration protocols to be applied to all workflows within the Clio Operate solution.
General Configuration & Naming
Consistency starts at the structural level. Always align with the broader system naming conventions to ensure clarity within the workflow modeller.
Workflow Name & System Name
Adhere to the defined configuration best practice for Names & System Names.
Step & Action Naming
Step Naming
All workflow steps must adhere to a standardised naming taxonomy to ensure logical transparency and system-wide consistency. Each step should be prefixed with its primary functional action, followed by a concise descriptor of its specific objective (e.g., 'Task: Onboarding Checklist'). Please note that the 'Main entry point' and 'Plan complete' steps are exempt from this nomenclature and must retain their original system titles. Refer to the mapping below for all other approved functional prefixes.
| Step Primary Action | Step Name Prefix | Example |
|---|---|---|
| Progress milestone | Change Phase | Change Phase: Litigation |
| JavaScript | {Primary Action} | Participant: Remove Matter Owner |
| Create notification | Notification | Notification: Case Assigned |
| Create outbound email | Email: Welcome Email | |
| Create outgoing SMS | SMS | SMS: Reminder |
| Create telephone call | Phone | Phone: Chaser |
| Prepare a document | Prep Doc | Prep Doc: Contract |
| Action plan choice branch | Evaluate | Evaluate: Next Steps Choice |
| Each | Each | Each: Contributor |
| Evaluate business rule | Evaluate | Evaluate: Matter Type is Dispute |
| Existing instance branch | Evaluate | Existing instance branch |
| If | Evaluate | Evaluate: Proceedings Raise or Respond |
| Is null or empty | Evaluate | Is null: Parent Matter ID |
| Start script plan | Plan | Plan: Onboarding Process |
| Start step | Start | Start step |
| Start workflow | Workflow | Workflow: Onboarding Process |
| When | When | When: All Tasks Created |
| Add comment | Comment | Comment: Case Assigned |
| Add participant | Participant | Participant: Add Case Handler |
| Add/Update Person | Person | Person: Add Other Party |
| Add/Update address | Location | Location: Add Correspondence Address |
| Add/Update organisation | Org | Org: Add Other Side |
| Create a work item | Work Item | Work Item: Proceedings |
| Date calculations | Date Calculation | Date Calculation: Estimated Exchange Date |
| Find workflow instances | Find Workflow | Find Workflow: Onboarding Process |
| Load ods data | Load | Load: ODS ID |
| Load participant data | Load | Load: Participant ID |
| Load work item data | Load | Load: Parent Matter ID |
| Run allocation rule | Allocation | Allocation: Lookup matter-owner |
| Update due date | Update Date | Update Date: Completion Date |
| Update work item attribute | Update Attribute | Update Attribute: Form Field 1 |
| Log Variables | Log | Log: Subtype ID |
| Create key date | Create Date | Create Date: Exchange Date |
| Find work item | Find Work Item | Find Work Item: Open Tasks |
| Create reminder | Reminder | Reminder: 2 Day Reminder |
| Create task | Task | Task: Onboarding Checklist |
Action Naming
Workflow actions must be labelled contextually to ensure granular transparency. For instance, a 'Load work item data' action specifically retrieving a 'Parent Matter ID' should be titled 'Load: Parent Matter ID' to clearly define its functional output within the process map. Refer to the mapping below for all other approved functional prefixes.
| Action | Action Name Prefix | Example |
|---|---|---|
| Progress milestone | Change Phase | Change Phase: Litigation |
| JavaScript | {Primary Action} | Participant: Remove Matter Owner |
| Create notification | Notification | Notification: Case Assigned |
| Create outbound email | Email: Welcome Email | |
| Create outgoing SMS | SMS | SMS: Reminder |
| Create telephone call | Phone | Phone: Chaser |
| Prepare a document | Prep Doc | Prep Doc: Contract |
| Action plan choice branch | Evaluate | Evaluate: Next Steps Choice |
| Each | Each | Each: Contributor |
| Evaluate business rule | Evaluate | Evaluate: Matter Type is Dispute |
| Existing instance branch | Default | Existing instance branch |
| If | Evaluate | Evaluate: Proceedings Raise or Respond |
| Is null or empty | Evaluate | Is null: Parent Matter ID |
| Start script plan | Plan | Plan: Onboarding Process |
| Start step | Default | Start step |
| Start workflow | Workflow | Workflow: Onboarding Process |
| When | When | When: All Tasks Created |
| Add comment | Comment | Comment: Case Assigned |
| Add participant | Participant | Participant: Add Case Handler |
| Add/Update Person | Person | Person: Add Other Party |
| Add/Update address | Location | Location: Add Correspondence Address |
| Add/Update organisation | Org | Org: Add Other Side |
| Create a work item | Work Item | Work Item: Proceedings |
| Date calculations | Date Calculation | Date Calculation: Estimated Exchange Date |
| Find workflow instances | Find Workflow | Find Workflow: Onboarding Process |
| Load ods data | Load | Load: ODS ID |
| Load participant data | Load | Load: Participant ID |
| Load work item data | Load | Load: Parent Matter ID |
| Run allocation rule | Allocation | Allocation: Lookup matter-owner |
| Update due date | Update Date | Update Date: Completion Date |
| Update work item attribute | Update Attribute | Update Attribute: Form Field 1 |
| Log Variables | Log | Log: Subtype ID |
| Create key date | Create Date | Create Date: Exchange Date |
| Find work item | Find Work Item | Find Work Item: Open Tasks |
| Create reminder | Reminder | Reminder: 2 Day Reminder |
| Create task | Task | Task: Onboarding Checklist |
Variable Naming Conventions
Standardising variables allows any consultant to step into a workflow and understand the data flow immediately.
Workflows designed for multi-context application must adhere to universal naming conventions. Conversely, where a workflow is purpose-built for a unique scenario, context-specific naming should be employed to maximise functional clarity.
Input Parameters
Input parameters should be assigned either universal or context-specific variables to maintain consistency across all solutions.
| Event Data | Variable Name | Data Type |
|---|---|---|
| sharedoId |
If universal: Work Item ID Or use a suitable context-specific name e.g. Matter ID |
Work Item Identifier |
| userId | User ID | ODS Entity Identifier |
Workflow Variables
To maximise architectural efficiency, reusable workflow variables must adhere to a standardised naming convention. This approach eliminates redundancy and prevents the unnecessary proliferation of duplicate variables.
| Use Case | Variable Name | Data Type |
|---|---|---|
| Parent work item ID |
If universal: Parent Work Item ID Or use a suitable context-specific name e.g. Parent Matter ID |
Work Item Identifier |
| Date calculation outputs | Calculated Date | Date Time |
| Allocation rule outputs | Calculated ODS ID | ODS Entity Identifier |
Workflow Logic & Evaluations
Main Entry Point Step
To optimise performance, limit the actions at the start of the workflow. This step should only be used for:
- Load Work Item Data: Fetching optimal path data (e.g., Parent Work Item ID) required later.
- JavaScript: Specifically for Event Data mapping.
- Evaluation: Using If, Business Rule, or Existing Instance Branch actions.
Plan Complete Step
The 'Plan complete' step must remain devoid of actions to ensure a clean and predictable process termination. This step functions exclusively as a logical conclusion point and should not facilitate any functional execution.
If & Business Rule Actions
If Actions & Business Rules
- Exit Conditions: Every If action must contain an exit condition (true) with appropriate handling.
- Reusability: If the logic could be useful elsewhere in other configuration, use a Business Rule instead of a hard-coded If action where possible.
Is Null or Empty Checks
Always validate data before usage to prevent workflow errors.
- Example: If using a Key Date to set a task due date, check if the date is null first.
- Handling: If data is missing, route the workflow to a task for a user to complete the data, then loop back to re-verify.
Actions & Outlets
Outlet Management
- Cleanup: Disable all unused outlets (e.g., if an "Overdue" outlet on a Create Task action isn't needed, turn it off).
- Process Efficiency: Use a Start Step action instead of an outlet if the workflow should not wait.
Example: If a workflow ends with a task, don't use the "Task Completed" outlet; use a "Start Step" to finish the workflow immediately so the process doesn't hang open.
Icons (Call-to-Actions)
Icon choices and labels must be uniform across the entire solution to ensure a predictable UI for the end user.
| Command | Label | Icon |
|---|---|---|
| Open a portal page | {Portal page name} | {Portal page icon} |
| Create a work item of a specified type | {Work type name} | fa-plus-circle |
| Add a participant role to the work item | {Participant role name} | fa-user-plus |
| Manage participants | Manage Participants | fa-users |
| Change phase | Change Phase | fa-fast-forward |
| Edit key dates | Key Dates | fa-calendar |
| Edit work item | {Work type name} | {Work type icon} |
| Open work item | {Work type name} | {Work type icon} |
| Open or create a child task | {Work type name} | {Work type icon} |
Triggers
When using common triggers (such as a Key Date used across multiple work types), include an Evaluation Action at the start. This confirms the workflow was fired for the correct work type before proceeding with the logic.
Visual Documentation Standards
Workflow maps must maintain a linear, left-to-right progression to ensure logical readability. Connector lines should be routed cleanly to avoid overlapping steps or intersecting with other process paths.
Example:
Optimal Path Configuration
The 'Optimal Path' setting on workflow steps must be applied selectively to maintain a clear and intuitive process interface. This configuration should be enabled exclusively for milestone steps that are guaranteed to be executed during the workflow lifecycle.
For optional or conditional branches, the setting must be disabled to prevent UI congestion and ensure the workflow instance process log reflects the definitive project trajectory.
Quality Assurance & AI-Driven Validation
Leverage AI-driven code analysis to audit workflow logic prior to deployment. This ensures adherence to established naming conventions, identifies redundant variables, and optimises script execution for superior system performance.