The brigade system

Have we piqued your appetite yet? Now that you have had the amuse-bouche, it's time for the entree. Let's now look at how to meticulously structure user hierarchies, groups and access levels so every team member can work efficiently and flawlessly within their designated station.

Stations, everybody!

Have you ever had to work in an Xplan site that had no structure and no organisation when it came to segmenting practices and clients amongst advisers? 

Was it a constant strain pulling you away from creating a masterpiece, having to sort out why someone couldn't find a client, why another person was able to see someone else's clients and why your paraplanners were constantly using the wrong entity to model against?

If this sounds familiar, ask yourself: what seemed to be the underlying reason that all of these issues arose? Was it access, capabilities or group memberships? 

Let’s focus on hierarchies and groups. Think about hierarchies as your kitchen stations: you have the executive chef that oversees everything, then you have the sous or station chefs that run each of their own stations. Finally, you have their teams, looking after their individual dishes and orders. 

Similarly, your hierarchy should reflect the running of the business. A typical complex licensee hierarchy may look like this:

There are four layers of hierarchy in the above picture:

1. Top level: licensee
2. Second level: business
3. Third level: state
4. Bottom level: practice

Not all of the businesses use all four, but some do. Advisers and their direct staff would sit in the practice level groups/subgroups. Some administrative staff may belong to multiple practice groups, but not necessarily all of them in their state or their business. 

Having advisers only in their practice groups means that there is no crossover and/or accidental access to clients they shouldn't see.

The state-based level might represent support staff such as client services managers and paraplanners that assist all teams regularly in their state/group, although perhaps not every day.

The business-based or sub-group levels would represent head office staff that may require overview of all practices, such as the compliance team and/or group CEO or manager.

Finally, the licensee level would represent users that require access to all business and groups across the site, such as site administrators or licensee head office staff. These users may not necessarily require access to view clients, but they would require access to the individual groups and users within them to assist with any business related needs.

The easiest way to remember all of this is that if a person is added to the top level, they will see everything below it. If they’re added to the second level they will see everything below that – i.e. third and fourth levels – and so on.

A smaller, less complex business hierarchy may look much more simpler:

Advisers and their staff would be a part of the individual practices that their clients are in and all shared/head office staff would be a part of the business (licensee) group.

Here are some handy hints to remember when working with hierarchies and groups:

• Identify which groups are “parent”/“licensee” groups in the hierarchy and which groups are “practices”/“branch”
  
  
• Keep it simple: we would suggest limiting your hierarchy levels to about three. Even though you can add as many as you want, sometimes less is more.
  
  
• Visualise your hierarchy. Map it out first; it's always easier to see it drawn up.
• Think about adding a Testing group somewhere in the hierarchy so that fake clients aren't mixed up with real clients.
  
  It could be at a site administration level or even at each individual practice level, depending on who you want to access this group.
  
  
• Hierarchies are a good way of applying group specific assumption sets and themes.
  
  There may be a group of practices that all have the same assumptions to be applied; this set can be added at the hierarchy parent level and will automatically be applied to all groups beneath it, making it less of an administrative burden to add it to each individual group.
  
  
• Default settings and a global assumption set are automatically applied to the top hierarchy parent. This ensures that any group beneath that does not have a custom or specific assumption set has the default one applied.
  
  
• Food for thought: be mindful of coding templates that draw group information (such as licensee details) from hierarchy parent groups. If a user is not a member of the hierarchy group, the details will not flow through, so think about using group level fields for this. 

Do you have the right equipment to do your job?

Have you tried to fillet a steak or fish with a whisk? What about de-boning a chicken with a pastry brush? It's an impossible task! You need the right tools to do the job. It’s the same with Xplan: you need the right capabilities that reflect your role.

The best way of doing this is to create access levels that best reflect your business and the staff within.

Here are some handy tips when it comes to access levels:

• Whether your access levels reflect role type or modules/licences, you should start with a matrix to keep track of which capabilities are added to which access level.
  
  This is easy enough to do by exporting your current access levels into a CSV file and using this as your starting point to review them all.
  
  
• Understand the difference between module licences and capabilities. Ensure that you allow users the right capabilities within a module, not just the licence itself.
  
  For example, having “View Portfolio” ticked applies the licence for the portfolio module to the user, but it doesn't automatically add all the related capabilities so that the user can do their job. Further to this, a Paraplanner will need more portfolio capabilities than an administrative assistant.
  
  They will need to model recommendations and apply target sets, whereas the administrative assistant might not.
  
  
• Keep your access levels simple and don’t apply capabilities that are not required for a user to do their job as this would result in more confusion than anything.
  
  
• When updating access levels, remember to push them through to the applicable users to ensure the new capabilities are applied. In line with this, try not to manually add capabilities to individual users, as any updates to access levels being pushed out to them will override manual changes

Moving onto the main course

Have we got your tastebuds tingling now? In our next blog, we will be moving onto the main course where we focus on onboarding, offboarding, and ongoing training of your staff.