How access works

When someone cannot see a module, cannot open a page or is refused an action, the reason is one of a small number of layers. This page explains each layer, what it controls today, and how to tell which one is in the way.

The layers#

Unobits checks these in order and stops at the first “no”. Some features also need something connected before they work — a mailbox, a payment provider, a social account. Pages in these docs list those under Also needs in their availability box.

1. Capability#

Most of the product is available today. Some areas are still being built and do not appear in these docs as available features until they are — see Feature availability. Where an area is partly built, its page says exactly what does not work yet.

2. Workspace#

Your workspace's business type decides which modules lead in the sidebar, and each person can add optional modules for themselves in Settings → Workspace → Add-ons. Solo workspaces hide the Team Portal.

This layer shapes navigation, not permission. Hiding a module from your sidebar does not stop you opening it by link, and adding it does not give you access you do not have.

3. Plan#

A handful of capabilities depend on the plan. Everything else is in every plan, with limits (seats, storage, credits) that grow with it.

When the plan is the blocker, Unobits says the feature is not available on your plan rather than that you lack permission. The Owner can change plan in Plan and billing. The exact numbers per plan are in Plan limits.

4. Experience#

Some modules present themselves differently in different kinds of workspace — different words, fields and stages. This changes how things look and read, never whether you may use them. See How Unobits adapts to your business.

5. Role and permissions#

Each person has a role — Owner, Admin, Manager or Member — and can be given extra permissions individually or through a preset. Most company modules need a View permission to open (View CRM, View Finances, View Projects …) and a Manage permission to change things. Personal areas — Inbox, Chat, Email, Calendar, Files, Office, Whiteboards, Automations, Integrations — open for every member.

The permissions that could do the most damage are owner-sensitive: no role includes them, and only the Owner can grant them. Managing finances, approving bills and expenses, managing and disconnecting shared integrations, managing Web Elements, deleting users and groups, and the admin console itself are all owner-sensitive. See Roles and permissions.

6. Record#

Within a module, some records have their own visibility:

• Projects are visible to their members, or to everyone when set to Public to organization.
• Files, documents, sheets, slides and boards are private until shared, and sharing can be read-only.
• Expense claims: a member sees only their own claims unless they review expenses.
• Email belongs to the person who connected the mailbox.

7. Action#

Even with a module open, specific actions have their own permission — approving bills (Approve bills), approving expenses (Approve expenses), exporting reports, deleting messages for everyone. Donna and automations run with exactly the same checks as the person who triggered them.

The same rules everywhere#

Permissions are checked by the server, not just hidden in the interface. The same rule that stops someone opening Finance also:

• removes Finance results from their search,
• stops Donna reading or changing Finance records on their behalf,
• hides Finance records in the Connections of other records they can see.

Working out why you were refused#

More in Account and access problems.