ACM stands for access control management — the system that governs who can view and edit each module and source in a workspace. The questions below are the ones that come up most often about it.
What happens to the old workspace access types (Private, Open, Limited)?
With the new access-control system (ACM), the old workspace access types (Private, Open, Limited) are removed. They'll no longer be available when creating a new workspace.
All new workspaces are now closed by default — meaning only administrators have access until they grant rights to other users.
When a workspace is created, is it open or closed by default?
With the new ACM system, every workspace is closed by default. This means when a user creates a new workspace:
- Regular users (readers or stewards) have no access to modules or sources.
- Only administrators can view, edit, and manage all of the workspace's modules and sources.
Who is the administrator of a newly created workspace?
The user who creates the workspace automatically becomes its first administrator. They're the only one with access initially. They can then:
- Designate other administrators for the workspace.
- Create rules to grant access to other users.
How do I add other administrators to a workspace?
The first administrator (the workspace's creator) can add other administrators by:
- Going to the Access tab.
- Clicking the Features tab.
- Clicking the pencil icon to edit the administration rule.
- Selecting one or more users from the dropdown.
How do I open a workspace's access to all users?
By default, new workspaces are closed. However, the administrator can, in a few clicks, grant read access to every client-space user, across all modules and sources.
Here's how:
- Click Create an open-access rule.
- Check the pre-filled fields:
- Selector: All users.
- Selector: All modules and sources.
- Access right: Can view.
- Click Create.
Confirming this creates an open-access rule, giving read-only access to every current and future user. This is a dynamic rule that applies automatically to new users with no further action.
How do I grant access to a module or source to users?
Access is granted by creating an access rule.
How do I create a rule?
Click the + button to create a new rule.
What are the elements of a rule?
A rule contains:
- Rule name.
- Description (only visible after creation, in the rule's preview).
- Users and/or teams concerned.
- Access level (e.g. view, edit).
- Modules and/or sources concerned.
What are the new access levels?
The new system has only two access levels:
- Can view: read-only access.
- Can edit: full access, including edit rights.
What happened to the Administrator access level for a module or source?
The Administrator access level for a module or source has been removed and merged into the Edit level.
What changed:
- The Administrator right no longer exists for modules/sources.
- Users who previously had this right now have the Edit right.
- The Edit right now includes import and export permissions.
- For lifecycle (status) management, the Admin role is removed. See the object lifecycle matrix.
- The Edit right, combined with a Steward license, now lets users manage every lifecycle status, including Validated and Deprecated.
What access level is needed to import or export a module or source?
With the new access-management system, the Administrator source/module permission level has been removed and merged into the Edit permission level.
To import and/or export a module or source, the user needs a Steward license, and the workspace administrator must grant them the Edit right on that module/source.
How does the new access system affect lifecycle management?
- The Administrator role no longer exists for status management.
- The Edit right (with a Steward license) lets users manage every status, including Validated and Deprecated. (The Admin role is no longer required for this.)
Can a rule be created for a team?
Yes, a rule can apply to different groups. You can select:
- A single user.
- Several users.
- A team.
- Several teams.
- A combination of users and teams.
The rule applies to every member of the selected teams and/or users.
What happens if a user is included in both a Can view rule and a Can edit rule on the same module or source?
The user inherits the higher access level — in this case, edit rights on the module/source in question.
What happens if a team member has a Reader license, but their team is included in a rule granting edit rights?
Since Reader licenses don't allow edit rights, these users won't be included when the rule is applied.
What happens if we disable a rule?
When a rule is disabled, the access rights it granted are temporarily removed for every user covered by it. You can re-enable the rule at any time to restore those access rights.
After migrating to the new access-management system, will users lose all their access rights?
No, users won't lose their access rights, and the administrator won't need to recreate rules to grant them access.
We ensure a smooth migration to the new access-management system by automatically generating rules that replicate existing access rights. Administrators won't need to manually recreate rules.
Can I apply a rule to all users?
Yes. To apply a rule to all users, enable Apply to all users when creating the rule.
This includes every current user in the client space, as well as any user added in the future.
What does the All users group include?
The All users group is a system team that includes every existing user in the client space, plus any future user added. This means that if you create a rule for all users, any new user added to your space is automatically included, with no manual update needed.
How can all users view the Glossary while a specific team can edit other modules?
You can achieve this by creating two rules:
- First rule: enable Apply to all users, set the permission level to View, and apply it to the Glossary module.
- Second rule: select a specific team, set the permission level to Edit, and apply it to the other modules.