Permission Handling Guidelines

This document helps you design products where users might be restricted to access specific functions on the screen. These restrictions can be handled by platform features like the Permission System or the Content Tagging System.

General Rules

1. The main workflow should always be visible: the main workflow's elements, that covers the main use-cases of the product, should be visible to all users, even if they might not have access to every function. Completely hiding these elements might make the product appear confusing or incomprehensible.

2. Disable restricted elements: if the user can't access a certain function of the main workflow, it should appear disabled, with a tooltip explaining why that function cannot be accessed.

3. Only show extra functions to those who can access them: If there are extra functions outside the main workflow only selected users can access, these elements can be displayed only to users who have the permission to access them.

What we consider the "main workflow" vary from product to product, so there's no hard rule on which functions to disable and which functions to completely hide.

Disabling Functions

If the user doesn't have permission to access a specific function of the main workflow, its UI element should still be displayed on the screen, but in a disabled state.

Hovering these disabled UI elements should show a tooltip, explaining why the function is not accessible.

We have a Tooltip component variation for Permission System messages.

Example:

• If the user doesn't have permission to create a new segment, disable the "Create Segment" button on the segments overview page, with the hover tooltip "Permission Denied: Segments / Create".
• If we didn't disable the button, the user would've been taken to a page that's not accessible to them. Taking users to "dead-end" pages is not a desirable experience.
• If we completely hid the button, the user might have started looking for it on the screen, as creating a segment is considered part of the main workflow.

Disabling Screens

If the user doesn't have permission to access a specific screen, a full-page Empty State component should be displayed, explaining why the screen is not accessible.

If possible, avoid redirecting the user to a screen they cannot view, e.g. by disabling the button that would take them to the inaccessible screen.

Example content:

• Title: "Permission Denied"
• Description: "You need the following permission to access this page: [Permission Name]"
• Action: "Back" button that takes the user back to the previous page.

Hiding Functions

If the function is part of the main workflow, we recommend not to completely hide its UI element, as this can make the screen and product appear incomplete, confusing, or incomprehensible.
If you must hide an element in the main workflow, please make sure that the UI remains comprehensible even for users who won't see the hidden element.

We only recommend hiding elements if the function is not part of the main workflow, and only accessible to selected users, e.g. a button only account owners can use.