Setting up a process to remove inactive users
Author: Kay Kuang is a Certified Master Anaplanner and Principal Data and Insights Architect at Anaplan.
Actively managing the users list to keep the list small and to keep only users who need access to the model will make the model go a long way. The users list can have a big impact on the model's performance — especially if a model has a lot of users. Setting users who no longer need access to No Access can decrease the model size and make the model run more efficiently. (Caveat: removing a user from the users tab will remove this user from all the models in the same workspace. You want to be very careful to do that.) Besides, if inactive users or other users who no longer need access to the model remain the model, it can compromise the data security in the model. This can be a big issue if the model houses highly confidential data.
However, manually checking inactive users and setting end users to No Access can be tedious especially if there are a lot of user changes regularly. In this post, I want to share the practice of using import action/process to manage users in the model. In this way, you can set up formulas to change people’s access, which provides a lot of flexibility. Then you can set up the process in a recurring schedule to update the users list so that you don’t have to manually do the work.
Steps to take
- Think about how you plan to decide if a user doesn’t need access to the model.
You can choose to manually flag users, or you can pull data from somewhere else to support the decision. Depending on the business needs, it could be the termination date (e.g. if you want to remove a user if that user terminated for over 30 days), or cost center (e.g. only users in a certain cost center should have access to), or anything other data that you want to look at to make a decision. - Create a data module and prepare the user data set.
This step is not necessary if you plan to manually flag the users who don’t need access anymore. The employee data set must have accurate employee emails, which will be used to map employees to the users list. You can pull the data from Workday or other systems that house the data that you plan to use. One necessary step is to map the data set’s dimension to the user list. That’s why it's critical to have employee emails included in the data set.
- Create a module dimensioned by users, which will be the output of list of users to set to No Access.
If you plan to manually flag users, then you can do it in this module. This module can be published to a dashboard and people can come in to tag and mark those who no longer need access to the model. If you decide to use data to drive the process, then this module will be the place you set calculations to check if a user still needs access to the model.
You can use FISTNONBLANK or LASTNONBLANK to connect the user data set to this calculation module (see calculation snapshot 1). A caveat is the calculation could be inaccurate if there are multiple records with the same email address. You can set up a validation calculation to check if anything should be watched out for (see calculation snapshot 2).
Another necessary line item is the “No Access” line item. This will be the data that goes into the role field in the users tab. It should be formatted as a text field. It should be the last step to combine all the data logic you want to look at to exclude a user and then populate “No Access” in this field (see calculation snapshot 3).
Calculation snapshot 1:Calculation snapshot 2:
Calculation snapshot 3:
- Create saved view.
With all the calculations set up... Now you just need to set up a saved view with only users marked as “No Access.” - Create the action and process.
After the saved view is set up, then you can go to the users tab. Click “import” then find the saved view you just created. You can follow the mapping below to set up the import action. After you have the action set up, you can bring this action to a scheduled process to let this process run on a recurring basis.
Questions? Leave a comment!
Comments
-
But as of now, we do not have any api or way of adding or deleting user completely from all models or from whole workspace? UAM models are available but the problem is if we have lots of model, creating actions and making it no access will be time consuming.
I was answering someone in the community who has similar issues and they have 300 models in their workspace.
Let me know if any-one has an alternative approach to delete from all models in a different way using api or something ?
0
