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.