Author: Lis de Geus is a Certified Master Anaplanner and Customer Success Consultant at Bedford Consulting.
Setting the details of a user’s access is usually a job for the workspace admin: decide their role and selective access to lists members. However, the Users tab is not always the friendliest, especially when thinking about selective access in detailed lists. It’s hard to tell what exactly someone has access to when they have access to multiple members of the same list, but not necessarily a top level. Also, in certain models, it can be quite handy to have the same security settings reflected in a module, where you can refer to for creating more custom DCA controls.
With that in mind, I like to create an admin UX page that can be used for that purpose. You see the list of users with access to the model, you may chose their roles and maintain their selective access in a very visual way. The page then contains an action button which will import all that information into the users list. While the person who runs the action still needs to be a workspace admin, setting up the details and maintaining it is a task that can be shared with other trusted members of the team. As a bonus, we can use the same settings to reference in DCA for certain functionalities.
In this article, I’ll give you a detailed step-by-step on how to set up this functionality. I’ll use an example that you can easily reapply to the realities of your model.
What the solution does
- Lists users with access to the model.
- Allows choosing a role assignment for each user.
- Allows granting/revoking selective access to one or multiple lists.
- Contains a process button so these settings are loaded into the back-end User details.
With this solution in place, we of course recommend that user settings are no longer done straight in the back-end. We’d want any changes to go through the UX, and that way we can make sure that our module information will match the actual selective access and avoid any conflicts. It’s the responsibility of the workspace admins to comply.
Pros and cons
Pros
- A centralized administration UX — user access can viewed from an app without needing to toggle to back-end settings.
- Easy to audit user roles with flexible UX layout.
- Reduced risk of manual mistakes by using standardized saved views and processes.
- Responsibility of reviewing and maintaining detailed selective access can be shared with other key members of the team that may not have WSA rights.
- The information is kept in modules and therefore can be referenced for DCA controls.
- The process works well even if your selective access hierarchies are numbered list, since we use the codes for importing.
Cons and trade-offs
- Development is required if selective access is needed in a new list that is not yet set up through this process.
- WSAs must comply to update all access details via the UX; any changes done directly in the back-end would be overwritten when the process is run again.
- Brand new users do not appear in the UX list until they have an initial role assigned in that model.
Proposed mitigation: Create a model role such as “Default” that doesn’t have access to any specific module, list or action. When a new user is added to the workspace, the Default role must be granted in User settings. That user will then be displayed in the User Access Management UX page without any role selected yet (in the UX module) and the detailed access profile (role and selective access) can be set up via the regular process.
Let’s do it!
Okay, this sounds like a nice idea, but how do we actually make this work?
I’ll share an example with detailed instructions so that you can easily reapply to the requirements of your model.
For this example, let’s assume the following:
- We have three roles available that have previously been set up on the User settings: Full Access, FP&A User and Read-Only.
- The Full Access user should always have access to the full company (selective access) — we’ll add some extra conditions for this, but of course this is optional and you can leave those conditions out if preferred.
- The other two roles require selective access to the Department list. The list is a hierarchy of two levels: D1 Department and D2 Cost Center.
What we need to set up: a module selection of a user’s role; a module for selection of a user’s selective access in D1 Department, then in D2 Cost Center; saved views and corresponding actions to import all three into the User settings page; a UX page that ties it all together.
Object Blueprint: what we will need
Lists
Users (standard list)
- Roles: a technical list of model roles, which should be a mirror of the actual roles existing in User settings – make sure the names match exactly
- C1 Department
- C2 Cost Center
Modules
- SYS01 Role Assignment
- SYS02 C1 Selective Access
- SYS03 C2 Selective Access
Actions
1.1 UAM Import User Roles
1.2 UAM Import Selective Access Total
1.3 UAM Import Selective Access C1
1.4 UAM Import Selective Access C2
Step-by-step
Starting point: you already have a working model with lists C1 and C2, and you have already reviewed role security with the three roles discussed.
Let’s start our build of the User Access Management functionality:
- Create the technical lists for roles, matching the roles you have in the model
- Create module SYS01 Role Assignment
- Create the saved view UAM_Role Assignment
- Create module SYS02 C1 Selective Access
Note: the third user has no option to select read or write, because they are set as Full Access — we’ll automatically grant them access to all departments on the next stage. - Create module SYS03 C2 Selective Access
- Create three saved views from module SYS03, one for each level of the hierarchy of selective access (Total, C1 and C2)
- Create the four necessary import actions into the Users list
- Create a UX page so that this can be maintained through and Administrative app
There you go!
Questions? Leave a comment!
