Summary
ShareDo 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 ShareDo resolves the correct portal, particularly where there might be several different inherited portals in the system.
Understanding How ShareDo Resolves Work Type Portals Across The Hierarchy
The first concept to understand is how ShareDo 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 how ShareDo indicates the presence of a portal by the label “Has Portals.”
When a user requests a particular Matter Portal, ShareDo will then:
- See if the particular work type, in this case, Matter, has a portal definition. If so, this will be displayed to the user.
- If not, ShareDo will traverse 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 will be shown.
- If the user is browsing Due Diligence – Seller, then the base “Matter” portal will be shown.
Where a work type doesn’t have a portal, you can see the rules that will be applied by clicking on Portal Designer and observing the following widget.
As a general guide, it is typically best practice to:
- Create generic portals at top levels, such as Matter or Real Estate.
- And then override them where there are considerable changes in child work types.
Understanding How ShareDo Resolves Work Type Portals For Different Personas
In addition to resolving portal definitions based on work type hierarchies, ShareDo will also resolve 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 will see the same portal. However, I 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 are now able to configure more advanced business rules. |  |
Browsing my eDiscovery portal as a Legal Project Manager persona, I will see the portal that has been defined for that Matter type. If I am using a different person, ShareDo will again “traverse” the work type hierarchy to find a portal that I can use. In the example above, it will show the Matter Portal.
It should be noted, however, that when portal matching rules are used rather than simply traversing the work type hierarchy, ShareDo will attempt to find the most “relevant” portal for a given persona. For example, if I define a portal for the B2B persona at the Matter level, then this will always be displayed in preference to a “low level” portal with no targeting rules.
This behaviour is designed to make it easier for you 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 ShareDo instance will also ship 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 ShareDo 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 ShareDo’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. |
