ODS Connections record the relationships between entities in the Operational Data Store. Connections are dated, so relationship history is preserved rather than overwritten. They also drive real behaviour across Clio Operate, including participant role suggestions, address inheritance, allocation rules, absence delegation and Data Composer.
ODS connections overview
A connection is a relationship between two ODS records. It describes the two parties themselves rather than a case, so it holds true regardless of which matters they appear on.
- Acme Ltd employs Jane Smith.
- Jane Smith is supervised by Mark Jones.
- Mark Jones automatically delegates tasks to Priya Patel while he is absent.
Connections are not limited to people. Any two records of the configured ODS entity types can connect, and teams can take part where the type is configured for them.
- User to user. Supervision, or a client partner relationship. Drives participant suggestions and allocation.
- Organisation to organisation. Parent company to subsidiary, which is useful where a client group spans several legal entities.
- Organisation to person. Employment, which carries a job title and employee code.
A connection type sets which ODS entity types can connect, how the relationship reads from each end, and who can see it. The connection is the actual link between two named entities, created from a type and given dates.
Each end carries its own label, which is what lets one connection read sensibly from both sides. An employment connection displays as Employs Jane Smith on the Acme Ltd record and Employed By Acme Ltd on the Jane Smith record. Users do not choose an end. They pick the label that describes the relationship, and Clio Operate works out the direction.
The ODS Connections aspect
Open a person or organisation record and the Connections aspect displays what that entity connects to. Three groupings display there, and they do not all behave the same way.
Admin > Operational Data Store > People/Organisations > Edit
 |
|
Configure connection types
Before you start
- Decide which relationships the firm needs to record, and how each one reads from both ends.
- Decide whether any type is sensitive enough to restrict to named staff.
- Confirm which ODS entity types belong on each end. Clio Operate enforces this and you cannot change it freely once connections exist against the type.
Create a connection type
Connection types sit alongside role connections, which is why the two are easily confused. See the Key concepts tab for the difference.
Navigate to Modeller > Participant Types > ODS Connections.
The list displays the connection types already defined. Double click or Select Edit Connection from the Actions menu to review it, or the New button to add a new one.
| Setting | Description |
|---|---|
| Name | What the connection type is called. |
| System name | The internal identifier. Used by workflows, reporting and the API. |
| Category | Groups the type for display, for example Organisational Structure or Employment. |
| Left entity type | The ODS entity type that goes on the left end. Employment uses organisation. |
| Right entity type | The ODS entity type that goes on the right end. Employment uses person. Clio Operate enforces both ends, so an employment connection cannot attach to a team. |
| Left label | How the relationship reads from the left entity, for example Employs. |
| Right label | How the relationship reads from the right entity, for example Employed By. |
| Left role name | The internal name for the left end, for example employer. |
| Right role name | The internal name for the right end, for example employee. |
| Read permission | Optional. Controls who can see connections of this type. |
| Edit permission | Optional. Controls who can edit connections of this type and assign them in the front end. |
| Show in summary view | Whether the connection displays on participant cards. Set independently for each direction, so a relationship can display from one end only. |
| System | Marks the type as built in. System types cannot be edited or removed, which protects the behaviour that depends on them. |
Worked example: supervision
This is the built-in Supervision type, and it is the simplest illustration of how a type is put together. Both ends are users, and the two labels describe the same relationship from opposite sides.
| Setting | Value |
|---|---|
| Left entity type | user |
| Left role name | Supervisor |
| Left label | Supervises |
| Right entity type | user |
| Right label | Supervised by |
Once saved, the relationship reads as Supervises from the supervisor's record and Supervised by from the supervised user's record. One user can supervise many people, so a supervisor's record can hold several of these at once.
Worked example: contacts at an organisation
This is the pattern most firms get the most value from, because it feeds the matter experience described on the Connections in Clio Operate tab.
A type such as Works at links an organisation to a person, so a firm can record which individuals work at each of the organisations it deals with. Bob Smith works at AXA Insurance. Several contacts can be recorded against the same organisation.
| Setting | Value |
|---|---|
| Left entity type | organisation |
| Left label | Reads from the organisation, for example Employs |
| Right entity type | person |
| Right label | Reads from the person, for example Works at |
Built-in connection types
| Type | Links | Reads as | Notes |
|---|---|---|---|
| Employment | Organisation to person | Employs / Employed By | Carries a job title and employee code. Can be permission restricted. |
| Supervision | User to user | Supervises / Supervised By | For your own staff. Allocation rules can route work through it. |
| Auto Task Delegation | User to user | [On Absence] Automatically delegate tasks to | Reassigns tasks while the user is marked absent. |
| Proprietor | Title to person | Owned By / Owns | For property and conveyancing. Ships disabled, enable it where needed. |
Firms can add their own connection types alongside these.
Extra fields on a connection type
Some connection types carry additional information about the relationship itself rather than about either entity. Employment is the example. It holds an Employee code and a Job title, because both describe that specific employment and not the person in general.
When a person changes employer they get a new employment connection with its own job title, and the previous connection keeps the job title it had. Attach extra field sets, and the screens that capture them, to any connection type.
Permissions
Four permissions govern connections, split by whose relationships they are.
| Permission | Allows |
|---|---|
| View own network | See the connections on your own record. |
| Manage own network | Create, edit and end the connections on your own record. |
| View other networks | See the connections on other entities' records. |
| Manage other networks | Create, edit and end the connections on other entities' records. |
This split lets staff maintain their own relationships without giving them access to everyone else's. Read and edit permissions on an individual connection type apply on top.
Manage connections
Where connections are added
Connections are added and edited on the Network aspect of an ODS record. There are two routes to it, and they do the same thing.
| Route | Who uses it |
|---|---|
| A user's own profile | A user maintaining their own connections. |
| Admin, on any person or organisation record | An administrator maintaining connections for other people. |
Which route a given user gets is decided by the network permissions. A site can grant users the right to maintain their own connections, grant it to administrators only, or both.
View the connections on a record
User: Profile picture (top right) > My Profile > My Network.
Admin: Admin > Users > Find person/organisation > Click to view profile > My Network.
The connections display, each reading from that record's end of the relationship. This is where the two directions of a single connection type become visible on one record.
Case connections also display against a record, alongside the connections described here. They are created by adding the party as a participant to a work item rather than here.
Add a connection to a record
- Open the record and select Network.
- Select add a new connection type.
- Select the relationship label that describes what you are recording, for example Supervised by.
- Search for the person or organisation at the other end of the relationship.
- Select the result to link it.
- Complete any extra fields the type carries. Employment captures a Job title and an Employee code.
- Select Save.
Users pick the label that describes the relationship rather than choosing a side. Clio Operate works out the direction from the label, so there is no need to know which end is which.
Change or remove a connection
- Open the record and select Network.
- Select edit against the connection.
- Select unlink to remove the connected party.
- To replace it, add a new connection as above and search for the new party.
So changing a supervisor is an unlink followed by a new link, rather than a swap in place.
Validation rules
Three checks apply when a connection is saved.
- The connection type must exist and be enabled. Users can only pick from the types a configurator has set up.
- Both sides must be the correct entity type. Attaching an employment connection to the wrong entity type returns "The Employment connection must be from an organisation".
- Two open-ended connections of the same type cannot exist between the same pair of entities. If an existing connection has no start or end date, complete both dates before adding another. This prevents overlapping and ambiguous history.
End a connection
ODS deactivates rather than deletes. Set an End date on the connection rather than deleting it. The connection remains on the record and in the connection history reporting tables, and ended connections drop off participant cards automatically.
Where someone rejoins a former employer, complete the start and end dates on the original connection first, then add the new one.
How connections are used
Selecting participants on a matter
This is the return on setting connections up. The work is done once on the ODS record, and it pays back every time somebody fills a participant role.
The supervisor is already known
A fee earner opens a new matter and sets themselves as matter owner. When they move to the Matter supervisor role, their supervisor is already offered, because the supervision connection on their ODS record tells Clio Operate who supervises them.
Against Nicola's profile you can see she is supervised by both Ben and Mike.
They display automatically when Nicola is the Matter Owner and you select to add a Matter Supervisor.
Nobody has to remember the reporting line, and nobody has to look it up. Clio Operate knows who supervises whom, so the correct name is suggested at the point the role is filled.
Contacts at an organisation
A firm records which individuals work at each organisation it deals with, using an organisation to person connection.
Then, for example, on any matter, adding AXA Insurance as the solicitor means the contacts who work at AXA can be preloaded when somebody comes to fill the solicitor contact role. Rather than searching the whole store for a name, the fee earner picks from the people already known to work there.
The organisation Bench Law Firm has 3 employees:
They display automatically when that organisation is on a case for example as a buyers' solicitor, when you select to add a solicitor contact
Other places connections are used
Connections are not only a record. Several parts of Clio Operate read them.
| Area | How it uses connections |
|---|---|
| Participant suggestions | When a user picks a participant for a role, Clio Operate suggests the party the existing participants connect to. Described above. |
| Participant cards | Connections flagged for summary view display on the card. A matter owner's card displays who supervises them. Ended connections are filtered out, so cards display current relationships only. |
| Data Composer | Calculated fields and queries can follow a connection from one party to another, instead of treating them as unrelated records. See below. |
| Data tagging | Connections are available to data tagging, using the same relationship. |
| Address inheritance | A person inherits their employer's addresses through the employment connection, so an office address is maintained in one place. |
| Allocation rules | Work routes through a connection, for example to the assignee's supervisor. |
| Absence delegation | The Auto Task Delegation connection reassigns tasks while the user is marked absent. |
| Reporting | Dedicated tables cover both current connections and connection history, so relationships can be reported on over time. |
| SCIM provisioning | Automated user provisioning creates or updates the employment connection wherever it can identify the person's organisation, and writes the incoming job title onto it. |
| Public API | The people API creates the employment connection, repoints it when the person's organisation changes, and saves the job title and employee code against it. |
| Data import | Loads employment connections in bulk. The data is checked for both an organisation and a person before it loads. |
| Employees navigation | An organisation record lists its employees, drawn from employment connections. Configured on the Configure connection types tab. |
Connections in Data Composer
Without a connection, two participants on a matter are two separate records, with nothing to say how they relate. A connection lets a calculated field start at one party and pick up details of the other.
To get a matter owner's supervisor from the work item:
- Select the participant role, for example Matter owner.
- Select the ODS record behind that role. For a user this is a person.
- Select ODS connections.
- Select the connection that records the relationship you need, such as the supervisor.
- Select Resolve to return the connected party, then pick the field you want from it, for example their name.