...
| Child pages (Children Display) |
|---|
| Table of Contents |
|---|
In a nutshell, what has changed and what impact does it have for you?
Before, a Settings-ID had a set of email addresses that could equally access this Settings-ID. This meant that everyone involved was an admin and each and every Settings-ID had to be managed separately. With the rollout of role and permission system, two new entities are introduced that affect this status-quo.
What are the new entities?
The first entity is for creating companies; a company will have a name and address. A Settings-ID can be assigned to only one company at a time. Currently, a clustering of companies is not possible.
The second entity is for permissions management; permissions determine what a logged-in user can and cannot do within the admin interface.
What are the various roles introduced under this new permissions entity?
Admin access, read/write access, and read access are introduced under this entity. Permissions can be for a company or just for a Settings-ID. It is important to note that permissions are automatically inherited from the company level to the Settings-ID level unless otherwise overwritten.
A user with admin access to a company can:
edit company details
delete a company
manage company permissions
assign(remove) Settings-IDs to(from) a company
configure all Settings-IDs assigned to a company
A user with read/write access to a company can:
configure all Settings-IDs assigned to a company
A user with read access to a company can:
see all Settings-IDs assigned to a company
A user with admin access to a Settings-ID can:
manage permissions for this Settings-ID
overwrite permissions inherited from the company for a specific user for this Settings-ID
configure this Settings-ID
publish this Settings-ID
download reports for this Settings-ID
A user with read/write access to a Settings-ID can:
configure this Settings-ID
publish this Settings-ID
download reports for this Settings-ID
A user with read access to a Settings-ID can:
see the configuration for this Settings-ID
download reports for this Settings-ID
Which users can create a new company and Settings-ID under this system?
All users will see the option to create new companies. But, no user can create new Settings-IDs; the users are advised to get in touch with their point of contact at Usercentrics (as before) for a new Settings-ID.
Will a user with access to a Settings-ID also have access to the company this Settings-ID is assigned to?
This user does not necessarily have to be a user at the company level.
Can a user with (only) admin access to a Settings-ID see other Settings-IDs assigned to that company?
No, this user can only know the company this Settings-ID is assigned to.
Can a user with admin access to a Settings-ID also be a user with only read access to another Settings-ID that has been assigned to the same company, and at the same time maintain the read/write access to this company?
Yes, only if the admins of this company did manually overwrite the said user’s inherited read/write Settings-ID permissions accordingly.
Can a user with admin access to a company change the status of another user with admin access to a company?
Yes, this is possible only if both the users have admin access to the same company, i.e., one admin’s status can only be changed by another relevant admin (and not by the same admin). The logic is the same for admins at a Settings-ID level as well.
How many admins are possible at the company and Settings-ID level?
There is no limit to the number of admins possible at both levels.
What happens to the direct access status of all users of a single unassigned Settings-ID when one of these users assigns this Settings-ID to a specific company?
Any user of this Settings-ID with admin access to a company can assign this previously unassigned Settings-ID to that company. As the user is an admin of the company, this particular user then also becomes the admin of this newly assigned Settings-ID.
The other users with direct access are processed depending on the following conditions:
The attached setting was not used in the new Permission System before: all other users will have read/write permission on the setting
The attached setting was used in the new Permission System before: all other users keep their current direct permissions on the setting
Who has access to a setting when it is removed from a company?
The company administrator who removes the setting will become the direct administrator of the setting. Other members of the company will not have access to the setting anymore, however, users that might have direct access to the setting can still access it.
How can I revoke access for a user for all settings under a company?
A user that is removed from a company will also be removed from any direct access to a setting. If you want to make sure a user without company access has no direct access anymore, you can also add this user to your company and directly remove the user again.
Can users with limited access to Settings-ID request access for a higher role from within the system for i) that Settings-ID, ii) that company?
This feature is not implemented in the current version.
Can company level admins get an overview of all the relevant Settings-IDs and the corresponding different users?
...