Implementation Guidance provides practical advice and design recommendations for using Clio Operate features effectively.

These resources outline different implementation approaches, highlight best practices, and explain the advantages and trade-offs of different approaches to help firms make informed design decisions.

Example topics include:

• Managing inbound email
• External conflict checking

Implementation Guidance provides practical advice and recommended approaches for implementing Clio Operate effectively.

Drawing on experience from real-world implementations, this guidance helps organisations understand how best to use platform features, functionality, and configuration approaches to support efficient and scalable solutions.

Rather than starting from scratch or learning through trial and error, teams can leverage proven implementation patterns and practical recommendations to accelerate their implementation journey.

Practical Experience, Applied

Implementation Guidance is developed from hands-on experience across many implementations. It utilises lessons learned, common patterns, and practical design considerations that help organisations make informed decisions when configuring and deploying solutions.

Each piece of guidance focuses on a specific capability or implementation challenge, explaining:

• Different ways the feature or capability can be implemented
• When particular approaches may be most appropriate 
• Advantages and trade-offs of different design choices 
• Practical considerations for implementation and ongoing operation

This enables organisations to select the approach that best aligns with their business processes, technical environment, and operational requirements.

Supporting Faster, Better Implementations

By providing clear guidance on how to use platform capabilities effectively, Implementation Guidance helps organisations:

• Reduce time spent researching or experimenting with configuration approaches
• Avoid common implementation pitfalls
• Apply proven patterns and practices
• Design solutions that are scalable and maintainable

Implementation Guidance complements Accelerators and Workflow Patterns, helping organisations not only implement solutions faster, but also implement them well.

Implementation Guidance may cover a wide range of implementation considerations, such as:

• Approaches for ingesting and managing inbound email
• Implementing external conflict checking processes with external datasets
• Best practices for configuration management and release processes 

Each topic focuses on helping organisations make informed implementation decisions based on practical experience and common industry patterns. Together with Accelerators, Implementation Guidance forms part of the Implementation Acceleration approach, helping organisations implement Clio Operate with greater speed, structure, and confidence.

Accelerators help firms start implementation with proven foundations rather than a blank page.

Built from real-world Clio Operate implementations, Accelerators provide structured starting points for common legal operational scenarios. They include pre-designed configurations, workflows, and supporting guidance that significantly reduce the time required to design and build solutions from scratch.

Accelerators are designed to speed up implementation while maintaining flexibility. They provide the foundational configuration for a subject area, enabling teams to focus their time on tailoring the solution to their specific business needs rather than building core components from the ground up.

Designed as Foundations — Not Plug-and-Play Solutions

Accelerators are not intended to be deployed as plug-and-play solutions.

Instead, they provide the foundational configuration for a particular subject area, which organisations can build upon to deliver their full business solution.

Every firm operates differently, and it is the responsibility of those implementing an Accelerator to ensure the final solution:

• Meets their specific business requirements
• Aligns with internal policies and procedures
• Complies with relevant regulatory and legislative obligations

Accelerators should therefore be treated as structured starting points, not finished implementations.

Accelerator packs fall into two categories: Functional Accelerators and Micro Solutions.

Faster Implementation, Proven Foundations

By providing pre-designed configuration and practical implementation guidance, Accelerators enable organisations to:

• Reduce solution design time
• Start implementation with proven patterns
• Focus effort on tailoring solutions rather than building from scratch
• Deliver value from Clio Operate more quickly

This catalogue brings together everything available to support your Clio Operate implementation.

Accelerator Recipe Cards define how different accelerators and sample configuration can be combined to support specific areas of legal work.

While individual accelerators provide distinct solutions for particular processes or operational capabilities, most legal practice areas require multiple processes working together. Recipe Cards bring these components together to form a collection of accelerators and sample configuration that can form the foundation for implementing a practice area solution.

You can think of Accelerators as the ingredients, and Recipe Cards as the recipe that combines those ingredients into a practical solution.

Example: Personal Injury Recipe Card

A Personal Injury practice area implementation may require a combination of common accelerators, practice-specific accelerators and sample ‘starter’ work types for things like instructions and matters, this is to provide the ability to visualise and demo what an implemented solution could look like.

A Personal Injury Recipe Card might include:

Common accelerators:

• Proceedings
• Offers
• Forms of Authority (FOA) & Record Requests
• Managing Witnesses

Personal Injury specific accelerators:

• Managing CRU
• Personal Injury limitation date calculator

Sample Configuration:

• A sample personal injury instruction work type, including sample participant roles, key dates, portal, etc.
• A sample personal injury matter work type, including sample participant roles, key dates, portal, etc.
• Sample data capture such as injury details
• Sample budgets for capturing claimed amounts/reserves

Together, these components form a foundation for designing and implementing a Personal Injury practice area, which can then be tailored to reflect the firm’s specific processes, policies, and regulatory requirements.

Guidance, Not Prescriptive Solutions

Recipe Cards are intended to provide guidance and inspiration, rather than prescriptive implementation designs.

Different firms structure their processes in different ways, and organisations should review the accelerators listed within a Recipe Card to determine:

• Which accelerators are relevant to their needs
• How those accelerators should be adapted
• What additional configuration may be required

Recipe Cards should therefore be viewed as illustrative combinations of accelerators that help guide implementation planning.

By showing how accelerators can be combined into practical solutions, Recipe Cards help firms:

• Visualise how practice area solutions can be assembled
• Identify relevant accelerators more quickly
• Design practice-specific solutions more efficiently
• Accelerate overall implementation planning

Together with Accelerators, Recipe Cards form part of the Implementation Acceleration approach, helping organisations implement Clio Operate with greater speed, structure, and confidence.

As part of the Clio Operate accelerator strategy we are developing accelerator specific design principles to ensure we have a consistent and scalable design approach.

To ensure accelerator solutions are modular and reusable they should not include elements that we know can vary significantly between clients/environments. For example, accelerator generally will not include:

• Approval rules/processes
• Automated supervision/review processes
• Automated budget/transaction creation
• Automated time recording
• Notifications
• Subject specific template documents/emails
• Integrations to third party systems (we cannot assume all clients will have/use them)

One of the key principles to accelerator design and configuration is to ensure that it is export-able, meaning that it needs to be as self contained as possible. Therefore inherited configuration and reference to other work types should be avoided wherever possible.

Configuration Guidelines

Configuration Approach

• Do not apply/use inherited config unless it’s within the scope of the accelerator content
• Do not use workflow triggers that reference out of scope content, e.g. a work item phase trigger where the work item is not in the scope of the accelerator component
• Only use core allocation rules (see below)
• Use core/standard case team participant roles (see below)
• Use standard ‘more’ menu options (see below)
• Use standard CTA labels icons in UI (see below)
• Only use ‘PS – System Admins’ for create permissions on work types
• Use confirmation messages on workflow menu commands (see below)
• Phase plans must include a ‘System Closed' phase (with no transitions to it)
• The first phase in a phase model should be called “Draft”

Naming Conventions

• Do not use numbering in workflow names; this causes issues in the future when an additional workflow is needed between workflow 1 and workflow 2
• Prefix work type system names with “core” with the exception of key dates which should be prefixed with “kd”
• Prefix form system names, list view system names, business rule system names with “core” 
• Buttons/commands/CTAs to use verb in labels; on a menu the menu title (label) should use a verb to help the user understand the action, e.g. open xxx, create xxx, edit xxx, run xxx

Templates Approach

• Only use top & tail letter and top & email templates in workflows

Configuration Guidance

Standard ‘More’ Menu Options

The ‘more’ menu commands on work item blade ribbons should follow the default settings to provide a consistent and standard approach and naming convention:

• More 
  • Administration 
  • View Audit
  • View Processes 
  • Jump to Phase
  • Work Item Merge
  • Work Item Reparent
  • Data Browser
• Security
  • Security Barriers
  • Why can I see
  • Permissions on this Work Item 

Standard Label & Icons

The use of icons in the UI, such as on task action plan call to actions, menus, etc. should follow a consistent and standard approach:

Unless explicitly required, only the following case team participant roles should be used:

• Matter Assistant (system name: matter-assistant)
• Matter Owner (system name: matter-owner)
• Matter Partner (system name: matter-partner)
• Matter Supervisor (system name: matter-supervisor)
• Contributor (system name: contributor)
• Reader (system name: reader)
• Primary Owner (system name: primary-owner)

Participant Sync Rules

Participant sync rules should not be included in accelerators, any required sync rules should be included as considerations in the implementation notes section of the design document.

It is assumed there will be existing participant sync rules from the parent matter work type to the child task work type for the following participant roles:

• Contributor
• Primary Owner
• Reader

Key Dates

Key date configuration should on a work type should follow the below behaviours:

• Set as date only (unless there’s a specific reason not to)
• Always on form
• No default settings

Standardised Workflow Configuration

Standard Allocation Rules

Unless explicitly required, only the following allocation rules should be used:

• Lookup matter-owner (system name: core-lookup-matter-owner)
• Lookup supervisor (system name: core-lookup-supervisor)

Workflow Triggers

Do not use workflow triggers that reference out of scope content, e.g. a matter phase trigger where the matter work type is not in the scope of the accelerator component. The lucid workflow design should indicate what the expected trigger is and it may need to be added to enable testing, but should not be included in the config export pack.

Task Due Dates

Unless the process requires it, e.g. based on procedural rules, workflow generated tasks should be set to 0 days due date. This is so there is a consistent approach that clients can update as appropriate.

Task Assignment

Unless the process requires it, e.g. based on process needs, workflow generated tasks should be assigned to the primary owner role. This is in case different clients use different case team roles, again this a consistent approach that clients can update as appropriate.

Javascript Blocks

JS workflow blocks should not be included in accelerators unless absolutely necessary. If there is a product/functionality gap it should be raised as an enhancement request on our DevOps product backlog.

Confirmation Messages on Menu Workflow Commands

To improve user’s experience (and avoid them clicking on the menu command repeatedly not realising something has been actioned), completion messages should be used to inform/direct the user to what the workflow action. For example if the workflow will create a task for the user explain this in the completion message.