Personas and Permissions

Was this article helpful?

Personas 

A persona in Clio Operate is a named classification assigned to a user. It determines how that user experiences the platform, what they see when they log in, which menus appear, and how work items are presented. Think of a persona as a lens: everyone logs in to the same system at the same URL, but what they see depends entirely on the persona they've been assigned.

Personas have a defined theme which controls the look and feel of the platform, and which can be used to ‘white label’ for external users. Portals (both the workbench/global portal and work type portals) are often designed to be persona specific, e.g. an external client persona uses a defined client portal or a manager persona uses a defined manager portal that shows them additional management tools and views.

In practice, different personas are assigned to different groups of users within a law firm. For example, a fee earner might see their matters, tasks, and time recording tools. A manager could see team availability and approval workflows. Compliance officers might access risk registers and audit tools, while clients are presented with a simplified summary of their work. Each persona delivers a unique experience, even though all users access the same Clio Operate system.

Personas are a UX tool, not a security tool. They control what a user sees, not what they can access or do.

Personas are a UX tool, not a security tool. They control what a user sees, not what they can access or do.

 

Global Permissions

Global permissions define the actions a user can perform anywhere in the platform. A global permission is a system control that defines WHAT a user is able to do in the application. For example, a user who has the Admin Access permission has access to the administration area in the platform. 

Permissions are granted to users through permission sets, which are assigned to users via ACL (Access Control List) teams. A permission set is a group of global permissions created for users with common permission requirements. For example, you are a system administrator, a system administrators permission set is created and assigned to a system administrators ACL team, and as a member of that team, you would gain those permissions.

A user inherits the combined permissions of every ACL team (permission set) they belong to — if they are a member of multiple teams, their effective permissions are the sum of all of them.

Global permissions define what a user is capable of doing across the entire platform, regardless of which portal or persona they have been assigned. They work alongside persona configuration and participant role permissions to form the complete access model.

  • Global permissions are accessed via Admin > Security > Permissions
  • Permission sets are accessed via Admin > Security > Global Permissions Granted > Permission Sets (button top right of page)
 

(Work Type) Role Permissions

Participant role permissions control which work items a user can see and work on — and what they can do once they are there. These permissions are limited to four categories: Read, Update, View Participants, and Assign Participants. They are only granted when a user is added as a participant on a specific item.

This layer ensures that even if a user can navigate to a work item in the UI, they still need the correct role to interact with it. Participant role permissions are the mechanism that controls data access — not personas, and not global permissions.

Role permissions are configured via Modeller > open the work type > Participant Roles

See Role Permissions on Work Types for Configuration guidance.

 

(Work Type) Create Permissions

Create permissions refer to the specific permissions that allow users or teams to create new work type items, such as the ability to create a matter type or task. These permissions are essential for enabling users to perform creation tasks, such as creating key dates or other work types. 

To manage create permissions effectively, it is advisable to use permission sets. This allows for easier management and assignment of permissions to users or teams. When creating a new key date, for example, you would need to grant create permissions to the relevant Permission Set (PS) to enable them to perform this action.

Missing create permissions are often the reason why users can’t ‘see’ the option to create something like a key date or a task type.

 

When importing config packs into an environment, create permissions are not persisted from the source environment to the target environment - after importing any new work types you will need to either manually add the relevant create permissions or use the ‘copy from parent’ button to inherit the role and create permissions from the parent work type.

 

Create permissions are configured via Modeller > open the work type > Participant Roles > Grant Create (button on the top right menu)

 

Was this article helpful?

Related Articles

Related articles in the knowledge base