[Start Here] User Access Management - Part 1: Get Started

AnaplanOEG
edited December 2022 in Best Practices

A foundational design element of any Anaplan model is User Management. This includes creating the design within the Anaplan model and app, as well as establishing the process for managing and maintaining access once users are active.

The table below contains questions that are typically asked as part of the Foundations phase and when thinking through model design:

Design Questions Management/Maintenance Questions
  • What role(s) are required to streamline & guide the users’ experience?
  • Who should be assigned the User Admin role for each model? 
  • What selective access is necessary to limit users’ data to the minimum required to complete their work?
  • What process will users/admins utilize to add/change/delete users from the model(s)?
  • Is there an external identity management system that will provide the required information to derive users, and/or role/selective access information?
  • How often will requests be processed to add/change/delete users?
 

User Management becomes increasingly complex the more models that are added within a tenant and the more unique users that require access to the models. It is no exaggeration that user management can take up a significant percentage of a User Admin’s time, particularly during busy cycles where Anaplan usage is high. Additionally, our customers must adhere to strict security and audit requirements which are enforced both internally and externally (depending on the industry).

Many of our customers are utilizing a User Access Management (UAM) model to solve the complexity of their growing Anaplan ecosystems as well as meet their security and audit requirements.

A User Access Management Model centralizes the management of model users by including one or more of the following functionalities:

  • Monitor users by model role and access type
  • Add users to one or more models
  • Remove user's access from one or more models 
  • Assign access to other features of the model(s), including roles and selective access
  • Import a file containing user account data
  • Export user information

The above functionality can also be built within each individual model. Why would one choose to build a separate model to manage users? Consider the following situations:

  • A customer has over 20 models with 1000+ unique users; business process owners want to own security instead of IT
    • User management becomes a full-time job during busy cycles, taking away from other key model management activities and causing frustration with end users
    • Business process owners want to manage users through a single centralized interface, not by accessing each model individually
  • Customer is required to pull from its central identity management system and derive all users’ access for its models; additionally, periodic audit reports are required to review all user access since Anaplan models hold sensitive data
    • Creating an integration from each model to the CIM system is inefficient, error-prone, and time-intensive to build & manage on an ongoing basis
    • Pulling individual user reports across all models and then manually consolidating is time-consuming and might not meet audit requirements

In both cases above, the UAM model saves time and provides more insight than a standard per-model approach to user management.

In addition to centralizing the main tasks of user management, additional features can be built to streamline administration and increase efficiency for User Admins:

  • Ability to sort/filter users by name and role
  • Add, edit, or remove access for multiple users at once
  • Copy user access settings from one user to another

Design Considerations

The design and build of a UAM model can vary depending on the level of complexity that is needed. A simple read-only dashboard to view users’ roles across all models can be built out in a matter of hours by an experienced model builder. A comprehensive model to manage all aspects of user access should be broken out into multiple user stories, accurately sized using Planning Poker, and prioritized accordingly within the available Sprint timelines.

A few considerations on UAM model design:

  • The UAM model works in conjunction with Anaplan’s Central Identity Management console; the UAM model does NOT replace CIM
  • If managing Roles and/or Selective Access, any changes to spoke model design regarding these items may require additional build to the UAM model to maintain continuity between dimensions
  • If managing Selective Access for multiple levels of a hierarchy, make sure that you incorporate a process to clear the highest level of the hierarchy before applying changes at lower levels (Anaplan always defaults to the highest level of access) 

Conclusion

The decision to utilize a UAM model must be measured against a customers’ business process, internal/external security requirements, and their current and planned Anaplan model ecosystem.

 

Ready for Part 2? See UAM in action.

 

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

Contributing authors: Paul Rosal, Becca Robertson, and **** Jacoby.