[Part 1] Removing users in bulk: Approaches and challenges
- 1. Which users do you want to remove?
- 2. What do these users currently have access to?
- 3. What level of removal do you need to perform?
- 4. How will you go about removing the users?
- Users tab
- User administration
- SCIM API Script
- Conclusion
- Additional resources
There are several things to consider when removing platform access for multiple users in bulk from your Anaplan environment. There are also a variety of approaches for how to remove those users, each with their own respective tradeoffs. This article will provide you with the information you need in order to take the best approach for your own specific requirements.
1. Which users do you want to remove?
There are several reasons you may need to remove Anaplan platform access for users. Perhaps people have left your company or moved to a different role that no longer requires Anaplan access. Maybe you’ve given access to some users that don’t actually need to use Anaplan. Regardless, the first thing you’ll need to do is determine exactly which users you want to remove.
- First, get a list of your current Anaplan users. You can do this via your HyperCare Reporting Model, or work with your Anaplan Business Partner to get this list, or leverage the SCIM API to generate this list through a script.
- If you are looking to remove users that have left your company or changed roles, work with your IT team to get a list of the current employees in your organization and cross-reference the two lists to determine which users need to be removed from Anaplan.
- You can work with your Anaplan Business Partner to assist in determining which users may no longer need access to Anaplan based on your current usage.
2. What do these users currently have access to?
Before you can make the right decision about how to remove the users, you’ll need to know what exactly they have access to in Anaplan. For the purposes of this exercise, you are ultimately looking for each user’s ID, the workspaces they have access to, and the level of access to each workspace (workspace administrator or regular user). There are several different ways you can get this information.
- Export the Users list from one model in each of your workspaces, and combine them into a single file. This is manageable if you only have a small number of workspaces.
- If you are leveraging a User Access Management model, export a list of all your users from that model.
- Export the list of users from your HyperCare Reporting Model.
- Work with your Anaplan Business partner to get the current list of users across your environment.
3. What level of removal do you need to perform?
When you're looking to remove access for users, consider which of their access levels you need to remove. Instead of removing them fully, you may just need to remove some of their permissions.
- Disable a user: When you disable a user in your tenant, that user can no longer log into Anaplan, either via basic authentication or single sign-on. They will not be able to access any workspaces they have access to or any other tenants. Note that this does not impact the authorization configured for this user at the workspace or model level. While they cannot log into Anaplan, you will still see them listed in your models. If you later enable their account, they will be able to access Anaplan with the same model-specific authorization as if you had never disabled them.
- Remove workspace access: When you remove a user from a workspace, they can no longer see that workspace or access any models in that workspace. If you remove a user from all workspaces, they will not be able to see any workspaces or models in your tenant. Note that the user may be authorized to see other tenants and would still be able to access models in those other tenants. Removing all workspace access without disabling the user does not prevent them from logging into Anaplan, either via basic authentication or single sign-on.
- Remove workspace administrator (WSA) privileges: When you remove a user’s workspace administrator privileges, they will no longer be able to perform administrative or model builder functions in that workspace. However, they will still be able to enter and view data in models in that workspace if they have the right level of authorization. If you remove WSA authorization from all their workspaces, they are no longer considered a model builder in your environment. Note that you can only remove WSA access from the Users tab in a model in that workspace.
- Remove tenant level roles: There are a number of administration roles that apply only at the tenant level. Removing any of these roles does not impact the user's authorization to see or use models or workspaces.
- Full removal: In order to fully remove a user from your environment, it is recommended to disable the user, remove their authorization to all workspaces, and remove all tenant level roles.
4. How will you go about removing the users?
Removing users can be cumbersome, so you’ll want to choose the best method based on your situation.
Considerations:
- What is the volume of users you need to remove?
- How many different workspaces do these users have access to?
- Do you have the Tenant Administrator or User Administrator role?
- Do you have access to someone with programming or scripting experience (e.g. Python, Java, shell scripting, etc.)?
The chart below will be helpful for determining your best option for removing users.
Users tab
This option involves removing users directly from the Users tab in the model settings. This approach is best for situations where most of the users that you need to remove exist in a only few workspaces.
Prerequisites:
- Must be Workspace Admin (in all relevant workspaces)
Steps:
- For each workspace that the user has access to:
- Go to a model in that workspace
- Navigate to the Users tab in the model settings
- Delete the desired users from the workspace
Advantages:
- Can remove multiple users from a workspace at the same time
- Can remove only workspace administrator privileges (without deleting the user)
Disadvantages:
- Need to repeat for each workspace the users belong to
- Cannot disable user accounts
- Manual effort
User administration
This option involves removing users via the Anaplan Administration console. This approach is best for situations where you have a small number of users to remove, but you need to remove each of them from a large number of workspaces. Additionally, you can disable user accounts with this approach. Note that the steps are slightly different depending on whether the user you are removing is an internal user or a visiting user.
Prerequisites:
- Must have either the Tenant Administrator or User Administrator role assigned
Steps:
- Navigate to the Anaplan Administration console
- For each user you want to remove:
- Internal users:
- Remove the user from all workspaces by unchecking all boxes
- Disable the user
- Visiting users:
- Internal users:
Advantages:
- Can remove a user from multiple workspaces at the same time
- Can disable user accounts
- Does not require workspace administrator access to all relevant workspaces
Disadvantages:
- Need to repeat steps for each user you need to remove
- Cannot remove only workspace administrator privileges. You must do this through the Users tab.
- Manual effort
SCIM API Script
This option involves leveraging the Anaplan SCIM API to build an automatable script that removes users from Anaplan.
Note: The SCIM API is designed to be used to interface with your identity management system. While it is possible to use SCIM API methods outside this interface, it is not the standard use of the Anaplan SCIM API and may not necessarily be supported in the future.
Prerequisites:
- An understanding of the Anaplan SCIM API
- Access to someone with programming or scripting experience (e.g. Python, Java, shells scripts, etc.)
- Permission from your internal security team to deploy code or run scripts in your environment, or access to a server where you have permission to run such scripts
- The user account running the script must have the User Administrator role assigned
Steps:
- Ultimately, the structure and approach for the script will be up to you. However, there is a walkthrough of a sample script in Part 2: Leveraging the SCIM API to bulk remove users.
Advantages:
- Automated
- Efficient
- Can be used to both disable user accounts as well as remove their workspace access
Disadvantages:
- Requires technical knowledge and time to configure the script
- Only works to remove internal users. You will need to use one of the other methods to remove visiting users.
- Cannot remove only workspace administrator privileges. You must do this through the Users tab.
Conclusion
If you have any questions or additional suggestions, please share them in the comments below. If you’re interested in learning more about this topic, you can check out the additional resources below.
This article continues with Part 2: Script Example: Leveraging the SCIM API to bulk remove users.
Additional resources
Comments
-
Thanks @ryan_kohn ! Very well written!
0