An instruction is the work item that captures a piece of work before your firm is engaged. Once it is ready to proceed, it spawns a matter, which becomes the active case. The instruction and the matter are separate work items: spawning creates the matter and links the two, it does not convert the instruction in place.
This article explains what data moves from the instruction to the matter when this happens, and what does not. Some of it carries over on every spawn. The rest depends on how your Clio Operate environment has been set up, so it varies between firms and sometimes between work types on the same firm.
If you need to set up spawning itself, see Phase Features for the Transition Instruction to Matter on Phase and Spawn a new matter from the sharedo settings.
Two kinds of carry-over
There are two distinct groups of behaviour, and telling them apart matters if you need to say whether something will carry over for a specific client or matter type:
- Always on. This group runs on every spawn, regardless of how the environment is set up. It is described in What always carries over below.
- Depends on configuration. This group only runs if it is part of that work type's spawn setup. It varies by firm and by work type, and is described in What depends on configuration below.
Key dates sit across both groups. Two specific dates always carry over as part of the core spawn action; every other key date depends on configuration. See the notes in each section.
What always carries over
| Field | What happens | Notes |
|---|---|---|
| External reference | Always carries over. | No configuration involved. |
| Reference | Carries over by default. | Can be switched off as part of the spawn setup. If a matter's own reference clearly does not match the instruction's, this is most likely why. |
| Title | Does not carry over by default. | Off by default because the matter's title is normally generated automatically once the matter exists. Can be switched on as part of the spawn setup if the instruction's title should be kept instead. |
| Description | Carries over into the new matter's instruction detail. | |
| Case type and work type | The instruction determines what kind of matter is created. | |
| Jurisdiction | Carries over only if it is an allowed option for the matter's case type. | If it is not an allowed option, the jurisdiction field is left blank on the matter, with no warning shown. If a jurisdiction seems to be missing, check the allowed options for that case type before treating it as a fault. |
| Statement of work | The instruction's preferred statement of work becomes the matter's statement of work. | Spawning fails outright if the instruction has no matching or preferred statement of work. |
| Instruction date and incident date | These are the only two key dates that carry over as part of the core spawn action. | Every other key date depends on configuration, see What depends on configuration below. |
| Linked case relationship | The instruction and matter are linked, with the instruction shown as a child of the matter. | Where this displays depends on how your portal is set up, for example in a Case Explorer widget. Your administrator can lock this link so it cannot be removed, in the Matter Spawning global feature. |
| The instruction and everything below it | The whole instruction, including any child work items, moves under the matter. | Because of this, chronology entries, tasks and other child items linked to the instruction display on the matter without being copied. See If something looks like it should have carried over but has not. |
| Matter spawned event | Spawning triggers a matter spawned event. | Any automation or workflow configured to respond to this event runs as part of the spawn. |
What does not carry over
- Electronic signature. A new signature record is created for the matter at the point of spawning. It is not the instruction's signature copied across.
- Client organisation. The matter's client organisation field is set to your firm's default organisation, not the instruction's client. The client as a participant is a separate thing and carries over only if participant copying is configured, see below. Do not assume the two are linked: a matter can show the correct client participant while the client organisation field still shows the default.
What happens to the instruction itself
Carry-over is about the new matter, but closing the source instruction happens alongside it, covered in What depends on configuration below under "Closing the instruction."
Whether the instruction closes at all depends on how your environment is set up. If it stays open after spawning, this is why. Which phase it moves to, if it does close, is controlled by the Move instruction to this phase on matter spawn phase feature, which you can set in Modeller on whichever phase you want the instruction to land on. If no phase has this feature enabled, the instruction moves to a default closed phase instead.
Either way, moving the instruction to that phase is what applies the closure. There is no separate step that closes the instruction without also moving its phase.
What depends on configuration
Beyond the core spawn action, further data can carry over depending on how spawning was set up for your firm. This can vary between work types, so do not assume a specific item will or will not carry over without checking. Contact Clio Operate support to confirm what applies to a specific work type.
| Area | What it carries | Things to check |
|---|---|---|
| Key dates | All key dates from the instruction, created as new entries on the matter. | The instruction's key dates can also be configured to close automatically once copied. |
| Participants | Specific participant roles from the instruction to the matter. | Runs immediately, rather than waiting for the standard participant synchronisation. Commonly used to get the client participant onto the matter straight away. If the configured role does not exist on the instruction, nothing carries over for that role and no error is shown. |
| Participant role connections | Relationships between participants. | |
| Participant synchronisation | Rechecks and reapplies the standard rules that automatically add participants. | Ensures these rules finish running before anyone opens the new matter. |
| Documents | Related documents, into a target folder or repository. | Can include documents from child work items, depending on configuration. |
| Custom attributes | Attribute values stored against the instruction. | |
| Form builder data | Data captured through custom forms on the instruction. | |
| Scorecards | Metric scores. | Only carries over where the scorecard applies to both the instruction and the matter's work type. |
| Commercial model | Estimates, delivery cost structures and budgets. | Each part of this has its own switch, so some elements may carry over while others do not. |
| Related links | Other work items linked to the instruction. | Can be limited to specific link types. |
| Work type change and clean-up | Changes the matter to a different work type if configured, and removes participant roles, connections or scorecard metrics that no longer apply. | |
| Incident details | Details of an incident recorded on the instruction. | |
| Properties | Property records associated with the instruction, such as title number, tenure, location, construction and size. | Relevant to conveyancing and other property-related work types. |
| Litigated flag | Whether the matter is already recorded as litigated. | Only carries over if the instruction was itself recorded as litigated. |
| Closing the instruction | Moves the source instruction to a closed phase once the matter is created, using a closure reason from your Lead Closure Reasons option set. | See What happens to the instruction itself for how the target phase is chosen. |
This list covers the steps included with Clio Operate. Some firms have extra steps added for a specific practice area, so you may see behaviour on your environment that is not listed here. If in doubt, contact Clio Operate support rather than assuming this list is exhaustive.
If something looks like it should have carried over but has not
- Confirm the setting applies first. The most common cause is that the relevant item in What depends on configuration is not part of that work type's setup. This is a configuration choice, not a fault.
- Jurisdiction is blank. Check the allowed jurisdiction options for the target case type. If the instruction's jurisdiction is not one of them, it is dropped silently.
- Client participant is missing. Check three things in order: whether participant copying applies to that work type, whether the configured role exists on the instruction, and whether the standard rules for adding participants automatically apply to that role. Remember that the client organisation field is separate from the client participant, see What does not carry over.
- Matter title looks different from the instruction's. This is expected. Title copying is off by default, see What always carries over.
- Something that appeared on the matter has disappeared. If it appeared because the instruction was moved under the matter rather than genuinely copied, unlinking or deleting the instruction removes it from the matter too. Genuine copies, such as documents or key dates copied under configuration, are not affected.