ACM : Access control management
User access rights management based on access control attributes has not yet been deployed to all clients. If this feature is not yet be visible within your environment, please contact your Account Manager to schedule its activation or to obtain information regarding its deployment date for your environment .
When well designed, ACM rules provide precise access control without adding complexity to the workspace. When poorly designed (too numerous, too granular, not properly cleaned up), they create recurring problems : duplicate rules that overlap for no reason, performance slowdowns caused by too many active rules, and a loss of efficiency for administrators who no longer know which rule does what.
This guide brings together the best practices to follow before, during, and after creating an ACM rule.
You may also refer to the following articles related to access rights management:
Manage user access rights based on access control attributes
Before Creating a Rule
- Define the exact scope: which users or teams, what permission level (View or Edit), which modules/sources, and precisely which subset of objects.
- Check what already exists: check the Access screen to see whether a similar rule already covers this need, in whole or in part.
- Configure access control attributes in advance: they must be selected from the Access screen before the rule is created, otherwise they won't appear in the creation modal.
- Confirm the actual need with the team concerned: a rule that is too broad or too restrictive leads to repeated correction requests.
Avoiding Duplicate Rules
- Before creating a new rule, check whether an existing rule already covers the same module/source: it's often better to enhance it (add a user, a team, an attribute) rather than create a new one.
- Keep in mind that the Edit rule always takes precedence over the View rule: there's no need to multiply rules to "secure" a case that's already covered by this priority.
- Two rules with the same permission level and a fully overlapping scope add nothing beyond a single, well-configured rule ,they only make things harder to read and debug, with no functional benefit.
- A clear naming convention helps quickly spot redundant rules during a review.
Optimizing Performance
The number and complexity of active rules directly impact access computation time at each login. A few principles to follow:
- Favor a few broad rules over many individual ones: one rule per team with attribute filters is more efficient than ten individual rules per user.
- Group users into teams before creating the rule, rather than adding users one by one: this also makes onboarding and offboarding easier, since it's enough to add or remove a user from the team for them to automatically inherit (or lose) the associated rights, without having to reconfigure their access individually.
- Regularly clean up outdated rules (users who have left, closed projects) rather than letting them pile up.
Lesson learned: for a client who made heavy use of ACM on their instance, the accumulation of many active rules caused noticeable platform slowdowns. This case is a concrete illustration of why keeping the number of rules under control matters just as much as their functional relevance.
Choosing your access control attributes wisely
Each workspace is limited to 3 attributes (tag, multi-value list, or hierarchy), in addition to status. Since this selection is shared by all administrators of the workspace, it deserves to be thought through collectively:
- Choose attributes that are truly discriminating for current and future access needs, rather than attributes picked "by default."
- Favor an attribute created under "Common" in the Client Space administration if it needs to be used across several modules; reserve module-specific attributes for needs that are specific to a single module.
- Always check that an attribute applied to a rule is properly linked to the module targeted by that rule: otherwise, the system displays a warning and the attribute won't appear in the object creation modal, which can block your editors.
- Keep in mind that these 3 attributes will also appear (and be mandatory) in the object creation modal: choose them with the everyday experience of the users creating objects in mind, not just the logic of the rules.
- Make sure objects are properly tagged and set to the correct status: this quality of metadata is what later allows rules to be effectively refined using access control attributes. An object that is mistagged or has the wrong status can become invisible to users who should have access to it, or conversely remain accessible when it shouldn't.
Naming and Organization
- Adopt a consistent naming convention.
- Avoid generic names ("Rule 1", "Test", "New rule") that make maintenance impossible across multiple administrators.
- Systematically fill in the Description field to give context to the rule you're creating.
Regular Review and Maintenance
- Schedule a periodic review (for example, quarterly) of all active rules: are they still useful? are the users or teams involved still within the expected scope?
- Disable or delete rules that have become obsolete rather than letting them accumulate.
- Check that the attributes used in rules remain relevant: an attribute no longer useful elsewhere but still linked to a rule cannot be deleted (a system safeguard).
Common mistakes to avoid
- Creating one rule per user instead of going through teams.
- Creating a rule before configuring the necessary access control attributes: they simply won't appear in the modal.
- Applying an attribute that isn't linked to the module targeted by the rule, risking blocked object creation for the editors concerned.
- Multiplying overlapping rules on the mistaken assumption that "Edit over View" priority resolves all conflicts without any cleanup being needed.
- Assuming a parent-child link is automatically inherited: access to a parent object doesn't grant access to its children, and vice versa, which can cause confusion for users if this isn't anticipated.