Overview

Permissions let one published app serve different users differently: an admin sees the delete button, an agent doesn't; a manager sees the payroll page in the navigation, everyone else never knows it exists. Instead of building separate apps per audience, you attach permission rules to the pieces of a single app, and each signed-in user sees only the pieces their access covers.

Permission checks evaluate the signed-in user's access and hide — not disable — elements the user lacks permission for. To the user, a piece of the app they can't access simply doesn't exist.

How Permissions Work

A permission rule names one or more permission groups, and within each group the specific permissions a user must hold. Permission groups and their permissions are defined in your platform's access management — the app states what a piece requires; access management determines who has what.

When a signed-in user opens the published app, their effective permission set is loaded once, up front. Each rule is then checked:

• The user must hold every permission listed across every group in the rule.

• One missing permission — or a group the user has no permissions in at all — denies the whole rule.

• A rule with an empty permission list for a group asks for nothing from that group and grants access.

Warning: A rule is an AND across everything it lists: every permission in every group must be held. You can't express "managers or auditors" in a single rule by listing both groups — that would require membership in both. Model either/or cases by finding a shared permission both audiences hold, or ask your administrator to create one.

Where You Can Attach Permissions

Permission rules attach at several levels, from the whole app down to a single button:

Denied Means Hidden, Not Disabled

Everywhere permissions are evaluated, denial removes the element. Nothing appears greyed-out or locked — to the user, a piece of the app they lack access to simply doesn't exist.

Design with that in mind: if you want users to know a capability exists but is unavailable, permissions are the wrong tool. Use a visibility condition with your own messaging instead — for example, show the button but display a tooltip explaining why it's disabled.

Navigation Groups and Denied Items

A navigation group whose items are all denied is removed entirely — users aren't shown an empty section. This is useful when a whole area of the app is admin-only: for everyone else the menu simply gets shorter. A navigation item pointing at a page also checks that page's permission rule, so a page the user can't access disappears from the menu along with its entry.

How to Attach a Permission Rule

On a Block

1. Select the block in the builder: Click the block on the canvas to select it and open its property panel.

2. Open the Permissions section: Scroll the property panel to the Permissions section, or find it in the block's inspector.

3. Select permission groups and permissions: Choose the permission group(s) and the specific permission(s) within each group that a user must hold to see this block. Leave the field empty to show the block to everyone.

On a Page

Open the page's settings (usually via the page list or a page-settings panel) and look for the Permissions setting. Assign the groups and permissions required to access this page. Users who fail the check cannot reach the page — the runtime returns them to a not-found or redirect behavior, and the nav item is hidden.

Public Apps and Anonymous Visitors

On a public app, visitors who aren't signed in have an empty permission set. A rule that requires anything from a group denies users with nothing in that group. Any block, button, or nav item carrying a permission rule is therefore invisible to every anonymous visitor.

If public visitors should see something, leave its permissions empty. Use the public/private page setting — not block permissions — to let anonymous visitors reach specific pages.

Note: App security (the Privacy Settings access level) decides who gets in the front door. Permissions decide what each person who is already inside can see. A private app with no permission rules shows everything to every signed-in user. Permissions add a second layer of access control within the app.

Gotchas

The builder shows everything — rules only bite in the published app

Inside the builder, every permission check passes: you always see and can edit every gated block. Enforcement happens only when the app runs for real users. Don't judge a rule by what you see while editing — check it in the running app as a user who lacks the permission.

Permissions load once per session

A user's permission set is fetched when the app loads and kept for the whole session. Granting or revoking a permission on the platform does not reshape an app the user already has open — they see the change on their next page load.

Hiding is experience, not security

Permission checks run in the user's browser, after the app definition has been delivered. They control what renders, not what exists — a technically savvy user could still learn what the app contains. Anything genuinely sensitive must be protected where the data lives: on the data source and the APIs behind it, not by hiding the block that displays it.

Example — Admin vs. Agent experience

You have a customer management app with:

• A Delete Customer button that only admins should see.

• A Reports page in the navigation that only managers should access.

• An Assign to Agent dropdown that only supervisors should use.

Setup:

1. On the Delete Customer button block, set permissions to require the customer:delete permission from the Admin group. Agents don't have this permission — the button is invisible to them.

2. On the Reports page, set permissions to require reports:view from the Manager group. Agents see no Reports item in the menu; managers do.

3. On the Assign dropdown block, set permissions to require ticket:assign from the Supervisor group. Regular agents can read the form but not see the assignment control.

All three user types use the same published app. Each sees a personalized experience without needing separate apps.

Related Pages

• App Settings & Privacy — the Privacy Settings access level that controls who can enter the app.

• Runtime & Access Control — how public/private pages work at runtime.

• User Management — managing the users, teams, and roles that permissions attach to.