Security Transfer is a T6 feature that allows you to copy permissions, groups, roles, features, and parameters from one user to one or more users quickly and efficiently. This feature provides two options: add the source user's permissions to the destination users' existing permissions, or fully replace the destination users' permissions with the source user's permissions.
The transfer includes all security objects:
For dynamic roles, you can update the data tables (Data Tables) that configure those roles, allowing you, for example, to transfer the entities for which a user has planning permission.
To access and use the Security Transfer feature, the user must have the Manage User Copy Security feature enabled in the Global Group.
Only users with this feature properly configured will be able to see and use the Security Transfer button in the interface.
Accessing the Security Transfer feature without selecting a user:
When you open the Security Transfer panel, you will find the following elements:
Field where you select the user whose permissions will be copied. If you selected a user in Explorer before opening the screen, this field will be automatically filled with that selected user.
Multi-select field where you choose one or more users who will receive the permissions. This field will not show the user selected in the "Source User" field to avoid conflicts.
It is important to note that users selected in one field will not be available for selection in the other field, ensuring operation integrity.
The system provides two transfer options:
Add to Recipient: The source user's permissions will be added to the destination users' existing permissions. Destination users will keep their original permissions and receive the source user's new permissions.
Replace in Recipient: Destination users' permissions will be completely replaced by the source user's permissions. All destination users' security items will be removed and replaced by the source user's items.
By default, the Add to Recipient option is selected when opening the panel.
The security items tree displays all security objects assigned to the selected source user. The structure is organized as follows:
All (root item)
You can select and deselect items individually in the tree to control which permissions will be transferred. The "All" item lets you select or deselect all items at once.
After selecting a source user, the security items tree will be automatically populated. To configure which items will be transferred:
At least one security item must be selected for the transfer to be performed.
When you change the user selected in the "Source User" field:
Before performing the transfer, the system carries out the following validations:
If any of these fields is empty when clicking "Save", the system will display a message informing that the field must have a value, and the operation will be aborted.
At least one security item must be selected in the tree. If no item is selected, the system will display a validation message asking you to select at least one item.
The system checks whether destination users have planning and/or consolidation profiles compatible with the source user.
Profile Rule: Destination users must have profiles equal to or less restrictive than the source user.
Profile Hierarchy (from least to most restrictive):
Validation example:
If any destination user does not meet this requirement, the system will display the following error message:
"The following users must have the same planning and/or consolidation profile as the source user or a less restrictive profile."
The message will be displayed above the Save button, and the operation will be aborted until incompatible users are removed from the selection.
Profile validation is automatically removed when you change the selection in the "Destination User" field.
This validation is applied only when the Replace in Recipient option is selected.
If an application object is not selected in the security tree and one or more destination users are editing that application's cube (for example, editing a dimension), the cube will be locked and the operation cannot proceed.
In this case, the system will display an error message for each user who has the cube locked:
"It is not possible to remove application "xxx" from user "xxx", because the Cube is locked by the user"
The operation will be aborted until the cubes are unlocked or the users are removed from the selection.
When the Add to Recipient option is selected:
The system will perform the following actions:
When the Replace in Recipient option is selected:
The system will perform the following actions:
Warning: The replacement option completely removes existing permissions from destination users. Make sure this is really the intended operation before confirming.
To cancel the security transfer:
Dynamic roles are roles configured through Data Tables that determine, for example, which entities a user is allowed to plan for.
During security transfer, when dynamic roles are selected:
Dynamic role transfer ensures that not only roles are copied, but also the specific settings that determine users' access scope.
Scenario: A new analyst joins the company and should have the same permissions as an existing analyst.
Solution:
Scenario: A user changes department and needs to have exactly the same permissions as that department's manager.
Solution:
This operation will remove all old permissions from the user and replace them with new ones.
Scenario: An entire team needs to receive additional permissions to access a new system module.
Solution:
Scenario: Several analysts have inconsistent permissions and need to be standardized.
Solution:
The Add to Recipient option keeps all existing permissions of destination users and adds the new permissions from the source user. The Replace in Recipient option completely removes all current permissions of destination users and replaces them with the selected permissions from the source user.
Yes, the "Destination User" field allows multi-selection, enabling you to transfer permissions from one source user to multiple destination users simultaneously.
Yes, you can use the security items tree to individually select which groups, applications, roles, features, permissions, and parameters you want to transfer. You don't need to select all available items.
The system will prevent the operation and display an error message. Profile validation requires destination users to have profiles equal to or less restrictive than the source user. In this case, you would need to remove the Planner from the selection or change their profile.
Check if:
Dynamic roles are roles configured through Data Tables that determine the user's access scope (for example, which entities can be planned). During transfer, the system updates these data tables, copying not only the role itself but also the settings that define the permission scope.
There is no native undo feature. Therefore, it is recommended to document users' current permissions before performing a replacement transfer, especially when applying to multiple users.
This is a security measure to avoid conflicts. A user cannot be simultaneously source and destination of the same transfer, ensuring operation integrity.
This option is ideal for role changes, permission standardization between users, or when you need to ensure a user has exactly the same permissions as another, without keeping any old permissions.
This message appears when you try to remove an application (using "Replace in Recipient") from a user who is currently editing that application's cube. The operation cannot proceed until the user finishes editing or is removed from the destination selection.