User Access Management: Part 3 - Practice makes perfect!

This is a detailed walk-through (and a downloadable link to a practice model!) that you can follow to get started on your UAM journey.

High-Level Architecture

annejulie_0-1635877086735.png

How User Information is updated via import

The User import definition in the screenshot to the right shows what can be updated:

The import key is Email Address.

Target Data items are the standard attributes that you can change. Note: If a user already exists, you cannot change First Name and Last Name. You can only change Role and Single Sign-On.

Target Access items are for Selective Access. Note the bulleted items below for Selective Access:

  • Every individual Selective Access item must be on its own row for a given user.
  • The “None” attribute only works with existing Selective Access items (on the user).
  • Numbered List Items must be loaded as #Name (no Code or Name allowed)
  • A Role of No Access will remove all Selective Access assignments
 annejulie_0-1635881583753.png

The UAM model must be able to provide the above information for each planning model as in the example below:

Update User MD PL.png

Common Structures

This article covers two different ways to implement UAM and the common Structures and Lists are covered here: Directory Source, Anaplan User, Models, and Model Roles

 

02 Common Structure.png

Directory Data

The Directory Data can be from the source systems that are valid for your environment.  These can include Directory Systems (e.g. LDAP, Active Directory), Identity Management Systems (e.g. Okta), or Employee Data (e.g. Workday).  What is common between these sources is information about potential Anaplan Users, such as email address, role, and organization, that are useful for correctly assigning a user to a particular model.  In some cases you may source from a ticketing system that sends approved access request information (e.g. ServiceNow).

03 Employee Directory.png

The Starter model will allow you to choose which person to add as an Anaplan User using their email address.  The User L1 column above connects to the Anaplan User list (via FINDITEM) and easily identifies whether someone was already added.

User list - User L1

The key for User L1 is the email address.  The other person-specific information needed when adding a user to a model are first name, last name, and whether to use SSO.  We recommend SSO since it is inherently more secure so you can explicitly set this to always be true.

04 INP User.png

The Starter model does include the ability to replicate the access of an existing Anaplan user. 

Models and Roles - Model L1, Model Role L2

Model L1 contains the list of current Anaplan models that you will be updating from UAM.

Model Role L2 is a child of Model L1 and is a numbered list so you can have duplicate role names across different models. The Role name you enter also acts as the Display Name for the list item.

annejulie_3-1635888452211.png

Model Schema - Option 1 (No Selective Access)

We recommend this option if Selective Access does not have to be maintained in UAM.  In this case, User to Model assignments is defined by a specified role at the desired intersection.

This is easier to implement than Option 2 (which supports Selective Access - covered later in this article).

annejulie_4-1635888559488.png

User to Model mapping

The module INP User Model V1 is dimensioned by User L1 and Model L1.  The critical line item is "Role" and selecting a value here creates the mapping information that will be exported to the planning model.  The SSO flag is also set here, normally always TRUE because it is the more secure option.

Note: the selected Role is a dependent list so you can only choose the roles specific to the model as defined in the Model Role L2 module covered earlier. 

06 Model Role.png

Export User Model Information to Planning Model

Each Model needs to have its own saved view in User Model L2, with the appropriate filtering mechanism as in the screenshot below which shows the view for the P&L model.

07 User Model Export.png

The view is filtered by Status, Role Assigned (not blank), and specific Model as in the screenshot below.

annejulie_8-1635888795069.png

Import User Model information into the Planning Model

The screenshot below shows elements of the saved view mapped to the User information in the Planning model.

annejulie_9-1635888861945.png

Define Selective Access directly in Planning Model

Option 1 does require you to go into the Planning Model and update Selective Access as shown below.

08 Import User Info.png

Model Schema - Option 2, with Selective Access

In order to support Selective Access which is detailed access items per model per user, a hierarchical structure is needed.  In this case: User L1 / User Model L2 / User Model Selective Access L3.

09 Schema Option 2.png

User to Model relationship

User Model L2 is a numbered list and you add models as children of User L1.  The module below (INP User Model V2) contains the properties that define access: selected model (Model L1), Role, SSO, First Name, and Last Name. The exported view looks very much like the V1 module equivalent.

10 User Model V2.png

Defining Selective Access

Selective Access (User Selective Access L3) items are added as children of User Model L2. This is a numbered list, and each row defines one list item that the user has access to. The item name is just a sequential number.

Each specific dimensional element (by row) is defined for selective access Read and/or Write, for that level of the hierarchy. Every list that requires selective access should reflect the latest structure in the planning model. That is why the architecture early in this article shows list data being pulled into UAM.

In the screenshot below you see that you pick the item for selective access and if this is a numbered list item, the "#Name" equivalent is pulled in since that is required for selective access.  This too must come from the planning model.

11 User Selective Access.png

Export Views to update the Planning Model

Similar to Option 1, you need saved views for User to Model assignments and User to Model Selective Access. The examples below show an extra export for setting role to “No Access” which clears all existing Selective Access Items before being re-assigned in a subsequent import action. This is not a recommended approach as it will remove data associated with the user (e.g. user filters).  This is here to reflect the challenge of changing existing Selective Access Items after the initial assignment.  

12 User Model V2 No Access.png

 

13 User Model V2.png

 

Each Selective Access item is a separate row for a given user as shown in the below screenshot and is filtered explicitly for a particular model.  Note the #name value for numbered list items.

14 Selective Access.png

Selective Access Import Definition for planning model

You can see in the screenshot below the user information mapped to selective access fields.

annejulie_17-1635889444749.png

Automating Updates to Planning Model

You can automate the security updates from UAM to planning models by leveraging CloudWorks to periodically update security. CloudWorks uses an internal user ID that can run model to model integrations and this means the UAM administrators do not need any access to the planning model.

You can schedule the security update to run daily or more frequently. Or if you need security to update immediately you can ad hoc run the import in the planning mode.  The person running the process in the planning model must have WSA (full access) rights and have read access to the UAM objects.

CloudWorks Example

  • Step 1: In the planning model, create a process that runs the security import from UAM

annejulie_18-1635889545530.png

  • Step 2: In CloudWorks, create a process to execute the Security update

xx CloudWorks Process-Upd.png

  • Step 3: Schedule your new CloudWorks process

annejulie_20-1635889578122.png

Additional Functionality (not in the Starter Model)

Here are some other considerations you may want to explore:

  • Map Directory Source data to a role or selective access to automate that part of model authorization.
  • Add a History Log of User changes with date-time stamps to simplify security audits.
  • After the actions complete for adding a user to a model with role (and optionally Selective Access), you can flag that user to no longer update to the planning models

There are 2 downloadable models related to this article. 

  • The UAM Starter Model has all the core functionality of User Access Management. 
  • The UAM Starter Planning Sample is the planning model that will be updated with the latest User access information and is also the source for the Selective Access list items that the UAM Starter model uses.

Got feedback on this content? Let us know in the comments below.

The content in this article has not been evaluated for all Anaplan implementations and may not be recommended for your specific situation.
Please consult your internal administrators prior to applying any of the ideas or steps in this article.
Comments

While this is great, I'm curious what the solution is for removing a user completely from the spoke models. You eventually import into the native User Settings as a "No Access" role, but when would you delete the user from the model entirely? Trying to keep the Users Settings tab clean is important for me because we have many security items dimensioned by Users, and inactive Users will expand our model size. 

Version history
Last update:
‎11-11-2021 04:40 PM
Updated by:
About the Author