As part of your implementation you will be creating lots of configuration artefacts and potentially managing configuration teams across the business. We find that having a clear naming convention for your configuration items helps make everything clear to all parties involved and help with maintenance of your configuration.
Work Types
| System Name |
The system name is not visible to end users but it should clearly describe where your work type sits in a hierarchy. If you are creating custom work types it should also be prefixed with 'custom-' this will enable you to differentiate between core configuration and your own custom configuration. {custom}-{top level work type}-{next level work type}-{name} For example: custom-matter-dispute-personal-injury |
| Name |
The name is what is visible to end users. It should be prefixed with 'Custom - ' which will enable you to differentiate between core configuration and your own custom configuration. {Custom} - {top level work type} - {next level work type} - {name} For example: Custom - Matter - Dispute - Personal Injury |
Common Configuration Items
| Matching Rules |
System Name {custom}-{context}-{description} e.g custom-matter-jurisdiction-scotland Name Custom - Matter - Jurisdiction is Scotland |
| Allocation Rules |
System Name {custom}-{description} e.g custom-find-matter-owner Name Custom - Find Matter Owner |
| List Views |
System Name {custom}-{context}-{description} e.g custom-workbench-expired-approvals Name Custom - Workbench - Expired Approvals |
| Formbuilder fields |
System Name {meaningful}-{name}-{for}-{context browser} |
| Others | In general it is good practice to prefix any custom configuration items with the pre-fix 'custom'. This allows you to see clearly where you have configured the product and will help you to build your configuration packages. |
Execution Engine Plans
| Plan System Name | It is important to give a naming convention to your plans. This will allow you to find them easily and for other people to understand what has been configured. We recommend {custom}-{worktype}-{path indicator}-{sequence}-{name} Work type gives an indicator of the type of work e.g. matter, instruction, offer. Path - describes where the work type sits in the work type hierarchy Sequence - is the sequence number for this workflow in terms of execution Name - is the individual name for the workflow - for workflows triggered on a phase change this should be the phase name. EXAMPLE custom-matter-dispute-defendant-001-investigation custom-offer-made-calderbank-002-expired |
| Plan Name | As per the system name but with spaces instead of - characters |
Task Action Plan Items - Examples
Presenting a consistent end user experience is important and can help with clarity in your implementation. Although you may wish to adopt your own standards these are the sharedo standards we use for naming action plan checklist items. We find that having a consistent single word indicator used across common types of action plan items is helpful to the end user.
| Editing a work item | Capture: Enter {workitem name} details e.g. Capture: Matter details |
| Creating a document | Document: Prepare {document name} e.g. Document: Prepare hearing report |
| Creating an email | Email: Send {email descriptor) e.g. Email: Send client acknowledgement email |
| Capturing key dates | Capture: Instruction key dates Capture: Incident date |
Execution Engine Step Names
Step names will vary depending on their function but where possible try to provide the most descriptive name possible. We prefix our step names with the a descriptor indicating the primary purpose of the step.
For example
Task: Initial investigation
Change Phase: move matter to Litigation
Key Date: Set discovery due date
Execution Engine Workflow Modeller Variables
As part of building up your execution engine plans you will need to create data storage variables. We advise the following naming conventions for clarity.
| Work Type Identifier | Work type identifiers are used to store the id of a work item you have created or that has triggered the plan. System Name {worktypename}Id e.g. matterId, offerId Name e.g. Matter Id |
| ODS / Participant / Participant Role Entity Id | ODS / Participant / Participant Role entity variables are used to store the id of a team, organisation or person. This could be something that has been looked up using the data composer function or an allocation rule. System Name {rolename}Id e.g. matterOwnerId Name e.g. Matter Owner Id |
| Task Id | You may have multiple tasks in your workflow so you need to story any task id variables in a way that describes the task that is being referred {taskdescripter}Id e.g. hearingReportId Name Task Hearing Report Id |
| Call To Action | Call to action variables are used for storing the information about the buttons that will be placed on checklist items System Name cta{Descriptor} e.g. ctaParticipants Name CTA Participants  |
| Action Plan Items | Prefix action plan item variables (the items in an action plan list) with APIT System Name apit{Descriptor} e.g. apitSendHearingReport Name e.g. APIT Send Hearing Report |
| Other Variable Prefixes | String - STR Date / Time - DT Boolean - BOL Number - NUM |