Clio Operate supports the personalisation of different portals for different personas based on other business rules.
Since there can be many different portal definitions and personas in use across the system, it is important for configurators to understand how Clio Operate resolves the correct portal, particularly where there might be several different inherited portals in the system.
Understanding How Clio Operate Resolves Work Type Portals Across The Hierarchy
The first concept to understand is how Clio Operate traverses the work type hierarchy when multiple portals are defined; consider the following example of the work type hierarchy for Matters.
In the image above, you can see a label “Has Portals” on some of the Matter Types.
When a user requests a particular Matter Portal, Clio Operate then checks if the particular work type, in this case Matter, has a portal definition:
- If yes, this displays to the user.
- If no, it will check back up the “tree” until a portal definition is found.
Therefore, using the hierarchy above as an example:
- If the user is browsing Matter – eDiscovery, then the “eDiscovery” portal displays.
- If the user is browsing Due Diligence – Seller, then the base “Matter” portal displays.
Where a work type doesn’t have a portal, you can see the rules that are applied by clicking on Portal Designer and observing the following widget.
As a general guide, it is best practice to:
- Create generic portals at top levels, such as Matter or Real Estate.
- Only override them where there are considerable changes in child work types.
Understanding How Clio Operate Resolves Work Type Portals For Different Personas
In addition to resolving portal definitions based on work type hierarchies, Clio Operate resolves portals based on the persona (or applied business rule). Let's explore how this works.
Using our Matter hierarchy from above as an example, if no persona rules are defined, all users see the same portal. However, you can restrict the usage of a portal to specific personas.
| Before v7.7, you can configure a portal to only be shown for specific personas. |  |
| From v7.7 onwards, you can configure more advanced business rules. |  |
Browsing my eDiscovery portal as a Legal Project Manager persona, you see the portal that has been defined for that Matter type. For a different person, Clio Operate goes up the work type hierarchy to find a portal they can use. In the example above, the Matter Portal.
It should be noted, however, that when portal matching rules are used rather than simply traversing the work type hierarchy, Clio Operate attempts to find the most “relevant” portal for a given persona. For example, if you define a portal for the B2B persona at the Matter level, this always displays in preference to a “low level” portal with no targeting rules.
This behaviour is designed to make it easier to configure generic persona-driven portals that apply across all of your hierarchy, typically for external users, while allowing you to “specialise” for internal users.
Default System Portals
In addition to configurator-defined portals, your default Clio Operate instance ships with a number of system portals; these are designed as “fallback” for when the system is first created and should be overridden.
If these portals are not overridden by your configuration, then when Clio Operate attempts to resolve the correct portal via its traversing strategy, it will fallback to one of the system portals.
The following system portals are provided
| Context | Overview |
|---|---|
| Work Type |
System portals are provided for the following work types:
|
| Workbench |
The following system workbench portals are provided:
|
The system portals for Matter Dispute, Matter Commercial Contract, and Real Estate will be deprecated in v8.0.
Best Practices In Configuring Portals, Rules And Personas
Using Clio Operate's portal targeting rules can give you great flexibility, but if used incorrectly, it can create unintended consequences. This section outlines some general best practices for configuring portals.
| Best Practice | Overview |
|---|---|
|
Create a small set of business rules for portal display targeting [Applies to version 7.7 and above] |
Since it is often the case that you may extend the number of personas that your system uses over time, rather than creating different “rules” for different personas, consider instead creating a single rule for “Internal” or “external” users and then applying that to your portals. If unsure where a rule is used, press the Usages button on the rule canvas. |
| Create top-level portals as “fallbacks” for each work type and then specialise as required |
While creating a new portal is easy, every portal you create carries a maintenance overhead. As a minimum, you should create:
|
| Consider creating page or widget display rules rather than creating separate portals where possible |
You don’t always have to create a new portal definition for a sub work type. Instead, you can simply change the behaviour slightly by adding display targeting rules to individual pages or widgets. In this way you can keep the total number of portals reduced. Nevertheless, if your portals start to have lots of rules, then it may be easier to break them out into different portals. |
| Consider creating different portals based on your practice group or configuration POD structure. |
Within our solution accelerators, we typically create separate portals for each. For example, we have different portal definitions for real estate than for claimant disputes. This structure is useful for personalising for different user communities and for segregating the changes that different configurators might make or deploy. |