When well designed, ACM (access control management) 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.
The best practices below cover what to do before, during and after creating an ACM rule.
User access rights management based on access control attributes has not yet been deployed to all clients. If this feature is not yet visible in your environment, contact your Account Manager to schedule its activation or to get information about its deployment date for your environment.
You may also refer to these related articles on access rights management:
What to check before creating a rule
- Define the exact scope: which users or teams, what permission level (Can view or Can edit), which modules/sources, and precisely which subset of objects.
- Check what already exists: look at 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.
How to avoid 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.
How to keep performance good
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: adding or removing a user from the team is enough for them to automatically inherit (or lose) the associated rights, without reconfiguring 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 illustrates why keeping the number of rules under control matters just as much as their functional relevance.
How to choose your access control attributes
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 metadata quality is what later lets you refine rules effectively with 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.
How to name and organize rules
- 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.
How to review and maintain your rules
- 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 the Edit-over-View priority resolves all conflicts without any cleanup.
- 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 confuse users if this isn't anticipated.