Guidelines for model impacts when removing a user from a workspace

Removing a user from a workspace

There are two different ways to prevent a user from seeing and accessing models:

1. You can set the user's model role to "No Access." This is set on a model-by-model basis and will prevent the user from seeing the model on the Tiles screen, as well as completely preventing the user from accessing the model. You will typically use this option when you still want the user to see some models in the workspace.
2. You can completely remove the user from the workspace. This is done on a workspace-by-workspace basis, and will completely prevent the user from accessing any models in that workspace, as well as preventing access to the workspace entirely.

This post focuses on the second option: what happens to records in the model history when a user is removed from a workspace?

1. Impact on model history

• After the user is removed, the history still retains any records tied to that user's email address (i.e. you will still have a record of what they did in the model).
• For any history records containing changes to the user's selective access, the Target User field in the history reads as <email> (now deleted), similar to how fields read for list items that have been deleted from the model.
  • If the user is later re-added to the model, the (now deleted) no longer appears, and history continues to record normally.

Example

Let's look at an example of the model history when the below steps are taken.

1. A user is added to a model.
2. The user logs in and updates a few cells of data.
3. The model owner updates the user's selective access.
4. The user is deleted from the workspace.
5. The user is added back to the workspace.

History after Step 4

Note that the changes made by the user are still present in the model history, along with their email address (2), and the Target User field for the selective access change has "(now deleted)" appended (3).

History after Step 5

When the user is added back to the same model, note that the "(now deleted)" no longer appears in the model history (5).

2. Impact on model data

When you remove a user from a workspace from the Administration console, you will see a warning message about potential data loss:

This message refers to situations where you have leveraged the Users list in a model. From the linked page, note the bolded text below:

When you (1) assign a user a model role of No Access or (2) remove them from the workspace, the user will be removed from the Users list. If you have any modules in your model that use the Users list as a dimension, then the data associated with that user in those modules will also be deleted.

For clarification, the model history records associated with a user are never deleted. You will continue to have a record of all model and data changes made by that user.

It will be up to you to assess the potential data impacts of removing a user based on your specific model architecture.

Example 1: User preferences (low potential impact)

Two common uses of the Users list as a dimension are building Smart Filters into a model and setting up access drivers for Dynamic Cell Access. The modules used for these will include the Users list as a dimension. However, since the module data associated with the Users is primarily for personal preferences or enhancing the end user experience, it is not typically a problem for it to be deleted.

In this example below, the Users list is used for a read/write access driver. If we remove a user from the model, their read/write configuration will be deleted. However, since they can't access the model anyway, it doesn't have any real impact to lose that data.

Example 2: Data entry (high potential impact)

Sometimes, you may want to enable users to enter data in their own personal version, and then use that version as the foundation for a baseline version that others will plan against. See example below.

In this situation, if you delete the user, then the associated data loss has the potential to impact many downstream calculations.

Conclusion

When you are evaluating the impact of removing a user from a model, remember these points:

• Model history is always retained.
• The potential impact of losing data is based on your specific model architecture and needs to be evaluated on a case-by-case basis.