Application Access

Application access lets a Business tenant restrict an entire application to users who hold specific roles — a gate that sits in front of the app, before any of the per-collection access rules or security policies come into play.

Where access rules decide who may call a collection and security policies decide which rows they see, application access decides who may open the application at all.

note

Application access is a Business tenant feature. If your tenant isn't a Business tenant, the Access panel described below doesn't appear, and the gate is never applied — your app and APIs are governed by access rules and security policies alone.

What it gates — and what it doesn't

This is the single most important thing to understand: role access gates delivery of the web app bundle, not your data.

It gates the hosted web app — the HTML, JavaScript, CSS, and other static assets served from your app's hostname. A user whose roles don't match is never handed the app bundle.
It does not gate data. Every request to a collection, query, or function is still independently authorized by that entity's access rules and security policies. Enabling a role here grants it no data permissions.

The practical consequence: application access is a convenience and presentation gate, not a data-security boundary. Two users who both clear the app gate can still see completely different data — or be denied entirely — based on the access rules on each collection. Conversely, a role you enable here gains nothing at the data layer until you also name it in the relevant access rules.

Don't treat the app gate as your data firewall

Because the gate only controls who is served the app files, a determined caller who already holds a valid token can still call your API endpoints directly, bypassing the app entirely. Always secure data with access rules and security policies — never rely on application access alone to protect records.

Empty list means open

The allow-list is fail-open:

No roles selected → every authenticated user can open the application. The Portal shows an amber warning to make this explicit: "No roles selected — all authenticated users can access this application."
One or more roles selected → only users who hold at least one of the selected roles can open the application. Anyone else is turned away.

This is the opposite of a deny-by-default model, so be deliberate: an app with an empty list is open to your whole authenticated user base, not locked down.

How a request is evaluated

When a request hits a Business-tenant application that isn't marked public, the gate runs in this order:

Not signed in? The user is redirected to the login flow and returns to their original destination after authenticating. The gate never rejects an anonymous user outright — it sends them to log in first.
Signed in, role matches (or the allow-list is empty) → the app bundle is served normally.
Signed in, no matching role → the user is shown a branded access-denied page: "You don't have a role that grants access to this application. Contact your administrator."

Public apps are exempt. An application marked public skips the gate entirely — it's served to anyone, signed in or not, regardless of the allow-list.

Configuring application access

In the Developer Portal, open the application and find the Access card:

Application → General tab — the primary place to manage it.
Control Center → Access Review — the same panel is mirrored here so a tenant administrator can review and adjust app access alongside the rest of the tenant's access review.

In the Access card:

Each row is a role (a group of end-users) defined on the API's Users & Roles page. Define your roles there first if the list is empty.
Toggle a role on to grant its members access to the application; toggle it off to revoke it. Changes save one role at a time and take effect on the next request.
Use the search box and Only active filter to manage long role lists, and hover a role to see which users it contains.

Only tenant administrators (and Softeria staff) can change application access. Removing a role that would lose access is treated as a breaking change and is guarded against accidental removal.

Linked applications in a Business tenant

Business tenants can link several applications together under a master application, so users move between sibling apps from a single directory (see Linked applications). Application access shapes that experience:

The app directory only lists apps you can reach. When a user lists the linked applications (or fetches the combined API description), the directory is filtered to the sibling apps whose role gate they pass. Apps they can't open simply don't appear.
Navigating to a sibling you lack a role for is denied. Following a link into a sibling application whose allow-list doesn't include any of your roles returns 403 Forbidden — "User does not have a role that grants access to the target API."

As everywhere else, a sibling app with an empty allow-list is reachable by any authenticated user, and a user's own app is always visible to them.