Manage User Access Rights Based on Access Control Attributes

This is an enriched, more advanced version of the user access rights management system. It lets you define access rules based not only on modules and sources, but also on tags, multi-value lists, hierarchies and object status. These are called access control attributes.

In practice, this lets you give access to a much more precise scope. For example, an administrator can allow all users to view all objects, while only allowing a specific team to edit a set of objects identified by a tag. This feature is available to workspace administrators.

Before reading further, make sure you've read the base version first: Manage Users' Access Rights.

How access rights are set up

Access rights are managed via rules. Setting up a rule takes two steps:

1. Configure the access control attributes that will be used to define access.

2. Create an access rule by filling in these fields:
   • Rule name

   • Users and/or teams

   • Permission level: Can view or Can edit

   • Modules and/or sources

   • Access control attributes

How to configure access control attributes

For each workspace, the admin can select, under the Tags section, up to 3 attributes of type tag, multi-value list or hierarchy (system or custom), plus the status. This selection is shared by all admins of the workspace: if several admins log in, they all see the same attributes selected.

As a workspace administrator, you configure these access control attributes via the dedicated button next to the + button on the Access screen. This button lists all the attributes that can be used as access control attributes, among the three types mentioned above. This must be done first, before creating any rules: the attributes only show up in the rule creation modal once they've been selected here.

A few guardrails protect this setup:

• You can't select more than 3 attributes under Tags. Trying to add a fourth one is blocked.

• You can't remove an attribute that is already used in a rule. This is also blocked.

• An admin can't permanently delete an attribute (from the client space administration) if it is used in a rule.

How to create a rule based on access control attributes

To create a rule that gives access to a precise scope instead of an entire module or source, add filters on the access control attributes (the ones you selected in the previous step) to your base rule.

A new section has been added to the rule creation modal, alongside the existing fields (Rule name, Users/teams, Permission level, Modules/sources): the Access Control Attributes section.

Here, an Add attributes button lets you pick the attribute you want to filter on to narrow down the rule's scope. Clicking it opens a dropdown with the attributes you selected earlier.

For example, you need a rule that gives edit rights to your CRM team (already created in the client space administration), but only for Glossary objects tagged CRM. To do this:

1. Enter the rule name.

2. Pick the CRM team in the Teams/Users field.

3. Set the permission level to Edit.

4. Pick the Glossary module.

5. In the Access Control Attributes section, select the tags attribute, then the CRM value.

6. Click Create.
   🖼️

   Screenshots: the rule form and the resulting rule. (Re-add these images here — the original Freshdesk links expire after a few days.)

Once created, the rule shows up on the Access screen with its name, the users it applies to, and the module and filters attached to it (in our example, the CRM tag).

Now say you want your CRM team to only edit Glossary objects tagged CRM and with the status Proposed:

1. Click the rule to open its preview.

2. Click the access control attributes button.

3. Select the Status attribute (already chosen during setup).

4. Pick the Proposed value.

5. Click Save at the top of the preview. The rule is now updated.
   🖼️

   Screenshots: adding the status filter and the updated rule. (Re-add these images here — the original Freshdesk links expire after a few days.)

How access rules work

Rule priority and combination

An access rule can be Can edit (edit rights) or Can view (read-only). If two rules apply to the same user on overlapping scopes, the edit rule always wins over the view rule.

Within a single rule, filters combine like this:

• Between different attributes (module, tag, status…), it's an AND: all conditions must be true. For example, a rule on module Glossary AND tag CRM AND status Proposed only covers objects that meet all three at once.

• Between values of the same attribute, it's an OR: just one needs to match. For example, a rule with tag CRM OR Hubspot covers all objects with either tag.

Rules apply object by object

Each rule applies to each object on its own: for a user to have access to an object, that specific object has to meet the rule's conditions (module, tag, status, etc.).

Parent-child links aren't taken into account automatically. If a parent object meets the rule's conditions, that doesn't automatically give access to all its children. The same goes the other way around: if a child object meets the conditions, that doesn't automatically give access to its parents.

This means you can run into a fairly common situation: a user has access to the parent but not to some of its children. For example, if a child object is marked confidential, it stays invisible to that user everywhere on the platform (hierarchy view, search, diagrams…). There's also a rarer, opposite case: a parent object that isn't accessible, with accessible children.

Access to sources and their child objects

When a rule gives access to a source with no other filter, the source and all its children (at every level) become accessible.

If you add a specific tag or status to the rule on top of the source, only objects under that source (including the source itself) and carrying that tag/status become accessible. An object with the tag/status but outside the targeted source won't be covered: the tag/status alone isn't enough, the object also needs to be under the source set in the rule. If a child object is moved out of its original source, it loses the access granted by the rule, even if it still has the tag/status.

What happens when you create or import objects

The object creation window has a new section for access rights attributes. The goal is to stop users from creating an object that would become inaccessible to them right after creation.

A new Access Control Attributes section now appears in the window, with this message: "Your workspace administrator uses these attributes to manage access. Choose values that match your scope of access so you can create this object." This section shows the fields that match the access control attributes set up by the workspace admin (here, Status and Tags).

These fields are mandatory: users must fill them in with values that match their access scope in order to create the object. Until they're filled in correctly, creation stays blocked, so the object stays accessible to the person who created it.

In the example, the user is on the CRM team, with an edit rule on the Glossary limited to objects with status Proposed and tag CRM. To create the object, they need to fill in status Proposed and tag CRM to match their access scope. Until they do, the Create button stays greyed out and creation is blocked.

What happens when you export objects

Export is available to everyone, editors and viewers alike: you just need access to a module or object to export it. The export only includes objects you actually have access to.

For the Dictionary module, full export is still admin-only. A user with partial access (viewer on some sources only) can only export the sources they have access to.

Read more

• Manage Users' Access Rights

• FAQ: Access Rights Management

• Best Practices Guide for Creating ACM Rules

• User Management Logging