Operational Data Store (ODS): Everything you need to know

November 10th, 2026

Was this article helpful?

The Operational Data Store, usually shortened to ODS, is the single store of every party Clio Operate knows about. Every person, organisation, user, team, property title and vehicle lives there, whether they belong to your firm or not.

ODS answers one question: who and what exists. It does not record who is involved in a particular matter. That is the job of participants.

Overview

Your own staff and your external contacts share the same store. Your fee earners and your firm's own organisation record sit alongside clients, opposing parties, expert witnesses, insurers, courts and suppliers. What separates them is how they are classified and how they are used, not where they are stored.

Whenever you add a person, organisation, team or user to the system, these are stored in the operational data store (ODS). Think of the ODS as being a huge list containing all of the different parties that are or were involved in your cases.

ODS and participants are two layers of the same thing, and the vocabulary overlaps can cause confusion. ODS stores the record. Participants describe how that record is involved in a piece of work.

One record, used everywhere

This is the point of the store. Adding a party to a work item does not copy it. The work item holds a participant record that points back at the ODS record, so the party keeps one identity everywhere it appears.

Correcting a client's address once corrects it on every matter that client appears on. Recording a company number once makes it available to every piece of work involving that company. Without the shared store, the same organisation would exist as a separate copy on every matter, and each copy would drift.

ODS is matter-independent

An ODS record and its relationships describe the party itself, not any piece of work. They persist whether or not the party is involved in any live work, and they do not change because something happened on a matter.

That is why a client stays in the store after their matter closes, and why a relationship such as "Acme Ltd employs Jane Smith" holds true regardless of which matters either of them appears on.

What the ODS record holds

An ODS record holds little in its own right.

Attaches to the record	What it holds
Contact details and contact preferences	How a party can be reached, and how they have said they want to be contacted.
Locations	Addresses held against a location type. A person can inherit their employer's addresses rather than repeating them.
Bank Details	Account information held against the record and reused by finance processes.
Connections	Dated relationships between two ODS records. See the Connections tab.
Employment details	The job title and employee code for a specific employment connection.
Competencies and ratings	Skills and specialisms, used when matching work to people.

User data is not covered here. Job roles, team membership, time targets, authority limits and email signatures attach to user records rather than to the store, so they sit with user management. See User Management and Job Roles.

Where ODS data comes from

ODS records are created and updated through several routes, and all of them write to the same store.

Route	What it does
Manual entry	Through the People and Organisations screens, or through Manage Participants on a work item. Both reach the same record.
External lookup	Create from.. on a new person or organisation panel, using any lookup providers your firm has configured.
The public ODS API	Used for integrations. 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 records in bulk. Employment data is checked for both an organisation and a person before it loads.
Automated user provisioning over SCIM	Creates and updates users, resolves the employing organisation, and writes the incoming job title onto the employment connection.

Manage ODS records

ODS records are managed in Admin > Operational Data Store >

People - Every individual the system holds, internal and external. Your own staff appear alongside clients, opposing parties and expert witnesses, because ODS treats them all as people.
Organisations - Every body corporate, including your own firm.
Locations - Every address held against a person or an organisation.

People

Lists every individual the system holds, internal and external. Your own staff appear alongside clients, opposing parties and expert witnesses, because ODS treats them all as people.

Organisations

This follows the same idea as people, with Name and Company Number in place of the name fields. It sorts by Name by default.

Locations

Actions on a an ODS record

The actions menu at the end of each row offers more than Edit.

Action	What it does
New	Add a new record.
Deactivate and Activate	Switches a record in or out of use. The menu displays whichever one applies.
Audit	Displays the change history for that record.
Convert to User	Gives a person the ability to sign in. Appears only when the person is not already a user and you hold the permission to convert.
Merge	Combines duplicate records into one. See Merge ODS records.

There is no delete action. ODS records are deactivated rather than removed, so history and any matter that referenced them stay intact.

Open and edit a record

Select a row, or select Edit from the actions menu at the end of it.

People - Personal Details

Organisation Details

People and Organisations also have Locations to add addresses and Connections to show/manage connections to other ODS record and cases.

Avoiding duplicates

The value of the store depends on there being one record per party. Search before creating, because a duplicate splits a party's history across two records and neither one is complete.

Where duplicates exist, use Merge from the actions menu. See Merge ODS records. Merge is not available on Locations.

ODS and participants

How ODS relates to participants

ODS and participants are two halves of the same idea, and the boundary between them is worth stating plainly.

	ODS	Participants
Answers	Who and what exists?	Who is involved in this work item, and as what?
Scope	The party itself, independent of any work	The party on one work item
Holds	The stored record, its addresses, contact details and relationships	A pointer to the record, plus the role and anything specific to this involvement
Lasts	As long as the party is on the system	As long as the party is on that work item

What a participant record adds

A participant record does not duplicate the party. It points at the ODS record and adds the things that are true only for this piece of work.

The role the party plays here, such as Claimant or Court.
Which address applies to this work item, chosen from the locations on the record.
Role specific detail, such as witness statement detail, captured against this involvement rather than against the party.
A reference for the party on this work item, where one applies.

So a client's home address lives in ODS, and the decision to correspond with them at their work address on one particular matter lives on the participant record.

Where the participants side is documented

Everything about classifying parties and using them on work items sits with the participants articles. That includes participant types, party types, participant roles, role restrictions, and how a party is added to a matter.

Article	Covers
Configuring Participants	The configuration side. Participant types, party types, roles and role restrictions.
Case Participants	The working side. Adding, editing, reassigning and removing participants on a case.
Understanding Participant Types	Participant types and party types in detail, including the Edit Party Type settings.
Participant Terminology	The definitions, in one place.

Two points of overlap worth knowing

Party types are set on the ODS record but configured with participants. The party type field sits on the person and organisation blades, so a configurator uses it whilst maintaining a record. What each party type does, and how it is defined, see Understanding Participant Types.

The person and organisation blades open from both sides. A user editing a participant on a matter is editing the stored record. Case Participants documents that route, and this article documents the record itself. They are the same blade.

ODS Connections

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.

Merge ODS Records

Merge ODS records

Overview

ODS Merge consolidates two duplicate records in the Operational Data Store into a single master record. Configurators run the merge from the Admin portal, and the change flows through to active matters. The subordinate record stays in the system, set to inactive, so historical references remain intact.

The feature applies to both People and Organisations in the ODS.

When to merge

Merge two records when they represent the same person or organisation but were created separately. Common causes include:

A participant added during matter onboarding without checking the existing ODS first.
An organisation imported from a data load that already exists in the system.
Variations in name, address, or company number captured as separate records.

Merging brings active assignments together into a single record, reduces duplicate contact details, and prevents new participants from referencing the wrong copy.

Before you start

You need various ODS create/edit permissions. The merge action is not available to users without these.
Identify the two records you want to merge. The current product supports two records per merge. If three or more duplicates exist, merge them in sequence.
Decide which record acts as the master. The master keeps its system identifier and remains active. The other record (the subordinate) is set to inactive after the merge.
The subordinate record is not deleted. Historical references to it are preserved.

Merge two ODS records

These steps cover the core flow. The exact dialogue layout and field labels may vary by tenant. Verify field labels against your environment before publishing.

Sign in to the Admin portal.
In the side navigation, select Operational Data Store, then select People or Organisations depending on the record type you want to merge.
In the list, select the checkbox next to the two records you want to merge.
The bulk action menu displays at the top of the list. Select Merge. The bulk action menu is hidden and appears only after two records are selected.
The merge view opens. Choose which record acts as the master.
For each attribute group, select the value to keep on the merged record. Attribute groups include key details, correspondence address, contact details, locations, teams, and matter assignments.
Step through the merge view and confirm the change to start the merge.

The merge processes in the background. Once complete:

The master record carries the selected attributes, contact details, locations, teams, and active matter assignments.
The subordinate record is set to inactive. It no longer appears in participant search results when adding new participants.
Active matter references are updated to the master. Closed matter references remain pointing to whichever record held them at the time of closure.

What end-users see after a merge

End-users do not have the ODS Administration permission and cannot run a merge. The effect of a merge still flows through to day-to-day work.

After an administrator merges two ODS records you previously worked with:

The merged participant on your matter now references the master record. Address, contact, and assignment details follow the choices the administrator made during the merge.
The subordinate record no longer appears when you add a new participant by ODS search.
Closed matter references are not changed.

If a participant's information looks wrong after a merge, contact your administrator to review the merged data.

Known limitations

Merge processes two records at a time. Sequence multiple merges where three or more duplicates exist.

Bank details

Bank Details: Everything you need to know

Bank Details in Clio Operate lets you store and manage bank account information securely against ODS entities, that is, people and organisations. Each entity can hold multiple bank accounts, which are stored centrally and available to reference across all cases.

Overview

Bank Details operates at two levels in Clio Operate:

ODS bank details — bank accounts stored against a person or organisation record in the ODS. These form the master list of accounts for that entity.
Participant bank details — when a participant is linked to a case, their bank accounts from the ODS record can be viewed and selected within the case context.

When a participant is added to a case (for example, a lender or chargee), users can select from the bank accounts already held against that participant's ODS record, avoiding the need to re-enter details. Bank account numbers and sort codes are encrypted in the database. Access is controlled through dedicated Finance permissions, and accounts can be validated against a configurable external provider such as Loqate.

Bank details are not displayed on ODS records or participant roles by default. Both must be enabled through aspect configuration before the feature is visible to users.

Bank account numbers and sort codes are encrypted in the database using the same method as user passwords. Masking of sort codes and account numbers for users without the Read permission is applied server side, meaning the unmasked values are never sent to the client.

Configure Bank Details

Permissions

Permissions control access to bank details. All sit under the Finance category in global permissions. These permissions are available in core but are not assigned to any default permission set out of the box.

Permission	Description
Finance – Bank Details – Create	Can create new bank account details
Finance – Bank Details – Update	Can update existing bank account details
Finance – Bank Details – Read (pre7.12)	Can see bank account details. Users without this permission see partial details only - a masked sort code and only the last four digits of the account number. Masking is applied server side.
Finance - Bank Details - readFull (from 7.12)	Can see all banking details.
Finance - Bank Details - readPartial (from 7.12)	Banking details with sensitive fields are masked: sort code account number BIC/SWIFT
No Permission (from 7.12)	A user with no banking detail permission does not see the banking details button or navigation bar. The section is hidden entirely, regardless of whether the banking details navigation has been enabled in Aspects.

Assign these permissions based on the access levels appropriate for your implementation.

From 7.12 consider the following when deciding which permission to assign:

Users	Suggested permissions
Finance administrators or roles that need to process or verify banking details in full.	Create, Update, readFull
Roles that need to confirm a user has banking details on record, without needing to see the full account information.	Create, readPartial
If a user should not have any access to banking details, do not assign either permission. The banking details section will not be visible to them.	None

The following assignments are recommended as a starting point pre 7.12:

Permission set	Suggested permissions
Case Administrators, Fee Earners, System Administrators, Team Leaders	Create, Update, Read
Support Staff	Create, Read
Client Case Handlers	None

Bank Account Lookup

Bank Details Lookup

This feature enables the validation of bank account details entered. Where an account is entered correctly, it will retrieve additional details, such as the bank's address. Enabling this feature will allow users to use a bank lookup service.

Feature Configuration

We currently support Loqate (postcode anywhere) for this functionality. Access this global feature at Launchpad > Modeller > Global Features. Search for lookup.

Feature Element	Description
Provider	Allows you to select the provide that is being used for the service
Search URL	The search URL that will be used for accessing searches
API Key	Your own unique API key for the service
Sort Code Mask	The mask that will be applied to validate sort codes in the application to maintain security
Account Number Mask	The mask that will be applied to account numbers to maintain security
IBAN mas	The mask that will be applied in the UI to iban numbers to maintain security
Mask Character	The character that will be used to mask the characters specified above.

ODS Bank Details Aspect

Add the ODS Bank Details aspect to ODS entity types to enable bank details to be created against them.

Modeller > Participant Types
Edit the ODS entity type you want to configure, for example User, People or Organisations.
Select ODS Aspects nav bar.
In the Footer click +
Search for bank
Tick Bank Details Nav
Select the Tick to Save.
Save
Confirm

Once configured, a Bank Details navigation item is available on the ODS entity record.

Participant Role Bank Details Aspect

Add the Participant Bank Details aspect to Participant Roles to enable bank details to be created against them.

Modeller > Participant Roles
Edit the Participant Role you want to configure.
Select ODS Aspects nav bar.
In the Footer click +
Search for bank
Tick Bank Details Nav
Select the Tick to Save.
Save
Confirm

Once enabled, the bank details section is available on the participant with that role within the work type.

Working with Bank Details

This section describes how bank details work for end users once aspects are configured.

Bank Details on an ODS record

Users with the Create permission can add bank accounts directly on the ODS entity record.

Modeller > Operational Data Store > Select the ODS entity type.
Edit the ODS record.
Select Bank Details from the navigation bar.
Select Add New.
If you have Bank Details Lookup configured and enabled, the screen visually indicates what has and has not been validated based on the provider in use.

Different providers offer different levels of validation. For example:
Enter the account details. The account holder name defaults to the name of the ODS entity.
If validation is in place, select the Validate button.

If valid, the bank name, branch and address populate automatically and a green tick displays.
If invalid and the user has the Update permission, they can enter the details manually.

Select Save and Close.

Edit

Fields are editable only if the user has the Update permission. If changes are made to an existing account, the Validate button is shown again and re-validation is required.

Loqate validates the sort code and account number, and populates bank details, but does not validate the account holder name.
Other providers may validate the account holder name but not the account details.

Bank Details on a Participant

When a participant is added to a work type with a participant role that has the Bank Details aspect, the system check whether the ODS entity for that participant has any bank details and display a message stating how many bank details they have.
Click Select, where you can either click + to select the bank details. If the user has create or update permission they can Create New or Edit existing bank details.
When you view a participant's details, depending on permissions the user can see the bank details and has options to unlink or edit.

Example screens for different permissions (from 7.12)

Click each permission to view the example

readPartial only

Shows sensitive information masked. All fields are greyed out as the user doesn't have Update permission.

readFull only

Initial view shows sensitive information masked. Click the padlock to view full details. All fields are greyed out as the user doesn't have Update permission.

readPartial and Create/Update

Shows sensitive information masked. Non sensitive information can be updated.

readFull and Create/Update

Initial view shows sensitive information masked, but non sensitive information can be updated. Click the padlock to view and update full details.

ODS entity picker

ODS Entity Picker Aspect

The ODS Entity Picker aspect can be added to a blade on a work type and is used to add/show specific participant roles.

Configure an ODS picker to pick up items from a parent work item

I want to use an ODS picker on my work type and have it pick up the participants that are on the parent work item. How can I do this?

Step 1 - Participant Role

The participant role you are setting must have the ability to search from parent items turned on in Role Sourcing for that work type.

Modeller > Work Types > Edit work type > Participant Roles > Click the row or the arrow at the end of the row or Actions > Configure

In Role Sourcing set Show related participants on parent sharedos to Yes.

Step 2 - ODS Entity Picker

On the work item, in the ODS Entity Picker Aspect against that role, Can search Related participants must be switched on.

Modeller > Work Type > Edit > Aspects button > ODS Entity Aspect settings button.
In Roles, select the role. In the Can Search section, set Related participants (if role sourcing allows) On.

ODS search

ODS Search

Refining the ODS Search feature improves search result relevance and accuracy by managing the weightings on fields and exact matches.

See the article Understanding Search Scopes for information on using the ODS search in an advanced search scope.

Access this feature at Launchpad > Modeller > Global Features or from the Modeller and search for ODS Search.

Weightings and Actions

Use the Weighting slider to indicate how relevant the results that match on that field are.

Use the Actions menu to enable/disable searching on that field and to indicate whether or not to boose exact matches on that field.

Was this article helpful?

Give feedback about this article

Display
Widget Title	The name of this aspect on your blade. Switch Show On to display on the blade. You can use the next two fields to set when you want it to show on the blade. You can have either or both set to On.
Show before sharedo has been saved	You would likely set this to On if you want the user to be able to add participants when creating the work type.
Show after sharedo has been saved	If you have before set to on, you would want this set to On as well. And if you didn't have before set On, so participants are created through the participants blade, then you may want this displayed once the work type is saved.
Show participant blade on add	When this is on, the participants blade shows immediately on adding an ODS entity (as long as the work type is saved). This allows the user to add/edit further details to the participant.
Roles Add one or many card or list views to the aspect. Use the + to add roles. You can change the order of the roles by clicking and dragging the title bar.
Role	Select the participant role to be added on this aspect. The roles available to select are those available on this work type.
Override label	Enter a label for the role, or leave empty to use the name of the role.
View mode	Select which view mode to use. Either Card or List. The Card takes up more space, but has additional features, such as the ability to search directly from the field and can display a reference. With the List mode, the user has to open another blade. If you allow multiple participants with this role, then a list view may be a better option to save space on the blade. Below the Buyer is a List, the Buyer's Solicitor is a Card: You can search directly on the Buyer's Solicitor field (if Inline Search is switched on against Can Search (see below): For the Buyer, you have to click + and open another Blade.
Vertical Layout	This option is only available for List view mode. It places the label above the picker:
Read only:	You would use this if you just wanted to display existing participants with this role, rather than allow a user to add it from here.
Requirement Level	Select whether this role is mandatory, recommended or optional on this aspect. This overrides the role configuration for this work type. Or you can leave it to use what is already configured.
Support multiple	Switched On only works if the role is configured to allow multiple
Add to current work item	Select whether this ODS entity should only be added as a participant to the current work item. This prevents any 'Add to ancestor' options displaying. For example, you attach a Task to the Matter (as a child). The Task is custom and is designed to capture specific data and some Participants too. Lets say some Medical Expert instruction details plus a Medical Expert Participant. Use the ODS Entity Picker on the Task to find and assign an Expert to the Task. If this option is enabled, the Participant goes directly onto the current work item (the Task) - b it wont go onto the Parent matter too - just the child Task. If the option is disabled, then the user is given the option to add the Participant to current work item (the Task) or the Parent (the Matter)
Allow adding a new ODS entity	If the ODS entity isn't found when the user searches, allow them to create a new ODS entity or not.
Can Search	Set whether the user can search for existing entities, or just add new. If Can Search is set to On, the options here depend on which View mode you have set. Inline Search: For Card view only you can set whether the user can search directly in the field. Related participants: Clio Operate automatically searches for related participants. If role sourcing is allowed on this role for this work type.
Show reference	Only available for Card view and if Show participant blade on add is switched off. Select whether their reference shows. If switched On you can change the label name. You can also set whether it is editable from here and if so whether it is mandatory.