Overarching Design & Configuration Principles

• Do not use/apply inherited configuration unless it falls within the scope of the accelerator content, i.e. do not reference or trigger work types or configuration outside of the scope of the individual accelerator.
• Do not use workflow triggers that reference out-of-scope content — e.g. a work item phase trigger where that work item is out of scope for the accelerator component.
• Work types should be specific enough that they don't create a need for display rules or complex workflow evaluations downstream.
• Only use core allocation rules (see Standard Allocation Rules in Reference Standards tab).
• Only use core case team participant roles (see Standard Case Team Participants in Reference Standards tab) and the defined case team role permissions.
• Enable role sourcing where required, but leave it un-scoped to avoid referencing any specific work types/roles.
• In workflows, use tasks with action plans in preference to a sequence of multiple individual tasks.
• Only use 'PS – System Admins' for create permissions on work types.
• Do not include tags
• No icons on widgets; icons should only be used on phase plans, menus, and portal page titles.
• Persona filters should not be used.
• The core configuration of standard non-matter work types should never be amended, e.g. Key Dates, Task, Approvals, Prepare Document, etc.
• Descriptions should always be completed, using clear, plain language.
• Phase guards and data quality rules are not included by default and should only be used where explicitly necessary.
• Use separate participant roles for specific organisation types and their contacts, with an ODS connection to enable linking — this supports better data capture for analytics and entity management.
• Participant sync rules should not be included in accelerators; any required sync rules should be captured as considerations in the implementation notes section of the design document.
• It is assumed that participant sync rules already exist from matter work types to (child) task work type for the following roles: Contributor, Primary Owner, Reader.
• Apply 'mandatory' field configuration only where absolutely necessary.

Naming Conventions

• Do not include numbers in workflow names — this causes issues later if an additional workflow needs to be inserted between two existing ones.
• Prefix work type system names with 'acc', except key dates, which are prefixed 'kd-acc'.
• Buttons, commands, and CTAs should use a verb in their label so the action is clear to the user (e.g. Open, Create, Edit, Run, etc.).
• Accelerator export pack naming convention: Accelerator Pack – [Accelerator Name]e.g. Accelerator Pack - Mediation

Matter Work Type Accelerators

Phase plans should start with a 'Matter Setup' phase and end with 'Pre Closure' and 'Closed' phases.

Standard matter work type portals should include the following portal pages:

• Matter Dashboard
• Documents
• Notes & Comments
• Finance
• Participants
• Chronology
• Processes (hidden)
• Audit (hidden)
• Matter Dashboard
• Documents
• Notes & Comments
• Finance
• Participants
• Chronology
• Processes (hidden)
• Audit (hidden)

Dispute matter work type portals should additionally include:

• Litigation & ADR
• Negotiation & Settlement

Standard menu options for matter work types should include:

• Prepare Comms
• Manage Participants
• Progress Milestone
• Create Tasks
• Start Workflow
• Manage Key Dates
• Edit Key Facts
• More (see Standard More Menu Options in Reference Standards tab)

Non-Matter Work Type Accelerators

Phase plans must include a 'System Closed' phase, with no transitions into/out of it.

The first phase in the phase model should be 'Draft'.

Portals are not usually required.

Standard menu options for non-matter work types should include:

• Prepare Comms
• Manage Participants
• Progress Milestone
• More (see Standard More Menu Options in Reference Standards tab)

Key Date Configuration

Configuration of key dates on work types should follow these behaviours:

• Set as date-only display, unless a timestamp is explicitly required.
• Set as ‘always on form’.
• If "allow multiple" is enabled, "description" should also be enabled.
• No validation on key dates.

Forms & Optionsets

• Use the vertical layout, not horizontal layout.
• Apply display order increments by 10.
• On optionset fields "allow no selection" should always be set to true.

Workflow Configuration

• Workflow input parameter IDs should be explicitly named for the context of the work type invoking the workflow; do not use generic names such as SharedoID or WorkTypeID, e.g. on a workflow triggered by a proceedings phase the input parameter would be named ProceedingsID.
• When referencing a parent work item, prefix the name with ‘Parent’ then name the work type it is, e.g. Parent[worktype]ID, following the same pattern, when referencing a parent work item, prefix the name with ‘Grandparent’ then name the work type it is, e.g. Grandparent{worktype]ID, 
  • Working example: a workflow launched by a Hearing being created needs to reference it’s parent proceedings and the proceedings parent matter, the IDs would be: HearingID, ParentProceedingID, GrandparentMatterID
• Use delayed start steps to generate reminder tasks at the required date/time, rather than creating them upfront; this keeps users' task lists minimal, e.g. a hearing reminder is needed 5 working days before the hearing date - the workflow step to create the reminder task should be configured to create 5 days before the hearing date.

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 out of scope for the accelerator component. The design document and workflow design should indicate the expected trigger; this may need to be added to enable testing, but should not be included in the config export pack.

Task Due Dates & Assignment

Unless the process requires otherwise (e.g. procedural rules), workflow-generated tasks should use the 0-day default due date — a consistent baseline that clients can adjust as needed.

Unless the process requires otherwise, workflow-generated tasks should be assigned to the Matter Owner role for matter work type accelerators or the Primary Owner role for non-matter work type accelerators.

JavaScript Blocks

JS workflow blocks should not be included in accelerators unless absolutely necessary. Where a product or functionality gap exists, it should be raised as an enhancement request on the Operate product backlog.

Confirmation Messages on Workflow Menu Commands

When starting a workflow via a menu command, add a completion message to tell users what a workflow action has done — e.g. if it creates a task, state this in the completion message. This avoids users repeatedly clicking a command without realising it has already run. For example:

Standard 'More' Menu Options

The 'More' menu should follow this default structure on both the blade and work item ribbons. Where a work type has a portal, a "View Portal" option should also appear in the blade ribbon.

Administration

• View Audit
• View Processes
• Jump to Phase
• Work Item Merge
• Work Item Reparent
• Data Browser

Security

• Security Barriers
• Why Can I See This?
• Work Item Permissions

Workflow Task Action Plan Command Labels

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

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

The following configurations are generally excluded from accelerator configuration, unless specified in an accelerator design document:

• Approval rules/models
• Automated supervision/review processes
• Automated budget/transaction creation
• Automated time recording/time recording configuration
• Notifications
• Template documents/emails (other than top & tail letter/email)
• Integrations to third-party systems
• Global features 
• Data quality rules
• Phase guards
• Work type change rules