Manage Users' Access Rights

Open up a closed workspace by adding administrators and creating view or edit rules for users and teams.

5 min read

Within a workspace, access to modules and sources is governed by access rules. They let you grant rights per user or per team, at view or edit level, and control access to modules and sources based on your organization's needs.

Only workspace administrators can manage access to that workspace.

What access a new workspace has by default

When a user creates a new workspace, it's automatically configured as closed by default. The creator then becomes that workspace's primary administrator.

This means:

  • Only the administrator has immediate access to the workspace.
  • No other user can access it until specific access rules have been defined.

The administrator is responsible for managing access rights. They can grant access to other users by creating and applying suitable access rules (per user, or per team).

How to add an administrator to the workspace

By default, a workspace's creator becomes its first administrator. To reflect this right, a system rule is automatically created in the Access tab, under the Features tab, in the workspace's administration area.

This system rule can't be deleted, but it can be edited to add other administrators. To do so:

  1. Click the Settings button to access the workspace's administration.
  1. Go to the Access tab.
  1. Select the Features tab.
  1. Click the pencil icon to edit the system rule defining administrators.
  1. In the dropdown, select one or more users to add as administrators.
    Only users with a Steward license appear in this list and can be designated as workspace administrators.
    Screenshot: selecting users to add as administrators. (Re-add this image here — the original Freshdesk link expires after a few days.)

What a workspace administrator can do

When the administrator assigns the administrator role to a user in the workspace, that user gets full access to the following:

  • Edit all objects, modules, and sources.
  • Manage and run Online connectors.
  • Manage the workspace's users' access rights.
  • Manage versioning.
  • Manage roles within the workspace.
  • Manage the workspace's screens.
  • Create and delete campaigns.
  • Customize the workspace's home page.
  • Manage the workspace's details and information.

How user rights are managed

Since every workspace is closed by default, no user (other than the administrator) has access to modules or sources as soon as the workspace is created.

To let certain users or teams access the workspace's modules and/or sources, the administrator must create custom access rules.

These rules let you:

  • Define who can access the workspace (a user or a team).
  • Specify what they have access to (modules and/or sources).
  • Determine the level of access granted (view-only or edit).

Fine-grained access management therefore relies on creating these rules, which can be adapted to organizational needs, user profiles, or specific use cases.

How to grant access to a module or source

Access to one or more modules/sources is granted by creating a custom rule. This rule lets you precisely target users or teams and define the desired access levels.

The access-rights system uses two levels of rights:

  • Can view: the user can see objects in the modules and sources, without editing them.
  • Can edit: the user can create, view, edit, and delete objects in the modules and sources.

The access-rights system lets you apply a rule to one or more recipients, as needed. You can target:

  • A single user.
  • Several users.
  • A team.
  • Several teams.
  • A combination of users and teams.

The rule applies to every selected member, whether individuals or teams.

To create a new rule, the administrator must:

  1. Click the + button under the Access tab in the workspace's administration.
  1. Fill in the following fields:
    • Rule name.
    • Users and/or teams concerned.
    • Access level: Can view or Can edit.
    • Modules and/or sources the rule applies to.
  1. Click the Create button.

You can choose the Apply to all users option, meaning all existing users with a license will be included in this rule, as well as any future users created later (for example, via auto-provisioning).

For the Dictionary module: selecting the whole dictionary applies the rule to every source that exists in the dictionary at the time the rule is created. Selecting only certain existing sources limits the rule to those sources. Selecting the whole dictionary and checking Include all existing and future sources applies the rule to every existing source, plus any future ones.

How to create an open-access rule

By default, every new workspace is closed: only administrators have access. However, the administrator can open access to every user in the client space in a few clicks, so they can view all of the new workspace's modules.

To do this, create an open-access rule:

  1. Click the Create an open-access rule button.
  1. Check the pre-filled fields:
    • Selector: All users.
    • Selector: All modules and sources.
    • Access right: Can view.
  1. Click Create.

Confirming the rule as-is creates an open-access rule within seconds. It grants view-only access to every client-space user, across every module and source in the workspace.

This is a dynamic rule, which automatically applies to current and future users, with no manual updates needed.

What does the platform look like for a user without access rights to a module?

  • If a user doesn't have access rights to a module or source, it's hidden from the side navigation bar, the breadcrumb, and the object-creation modal. As a result, the user can't view the sheets of objects belonging to that module. Example: a user without access rights to the Glossary:
    Screenshot: the Glossary module hidden from navigation. (Re-add this image here — the original Freshdesk link expires after a few days.)
  • If a user doesn't have access rights to a module or source, inaccessible objects are never returned in search results. Every filter related to inaccessible objects is also hidden. Example: search results for a user without access rights to Usages:
    Screenshot: search results with an inaccessible module's filters hidden. (Re-add this image here — the original Freshdesk link expires after a few days.)
  • If a user doesn't have access to a module, they won't see MetaBot's suggested links for objects they can't access. Example: link suggestions for a user with full access, vs. one without access to the Dictionary's 'Sales' source:
    Screenshot: link suggestions shown with full access vs. restricted access. (Re-add this image here — the original Freshdesk link expires after a few days.)
  • If a user doesn't have access to a module, but objects in that module are linked to objects in an accessible module, they're told the link exists — but can't see the linked object's label or preview it. Also, when exporting the accessible module, inaccessible objects aren't included in the CSV files. Examples: linked objects, lineage, and diagram views for a user without access to the relevant module/source:
    Screenshot: linked-object display for a restricted user. (Re-add this image here — the original Freshdesk link expires after a few days.)
    Screenshot: lineage display for a user without Glossary access. (Re-add this image here — the original Freshdesk link expires after a few days.)
    Screenshot: diagram display for a user without Usages access. (Re-add this image here — the original Freshdesk link expires after a few days.)
In summary, across every screen — including the Implementation tab, Dashboard & widgets, tasks, Analytics, and more — users can never view the sheets of inaccessible objects, nor see their labels displayed.

Read more

Related articles

Was this page helpful?