Permissions

Access is granted per role, per entity, per operation (read, create, update, delete), as a scope:

A user with several roles gets the widest scope any of them grants.

Beyond scopes

• Workspaces grant access through membership, and flow to related records.
• Record sharing grants a specific record to a user, team or role.
• Rule-based filters add stored conditions per role.
• Named permissions control screens and components.

The data engine applies all of this to every read and write. Field-level security is not available yet.

Layers of access

• Tenant scope. Applied first. Records, configuration and users are scoped to the caller's tenant, app and environment.
• Entity access. What each role may do with an AppObject's records, and which records.
• Permissions. Whether a screen, menu item or component is available to a user.
• Record sharing. Exceptions for individual records.

Roles

The platform has built-in roles for running the platform and building apps: Tenant Administrator (organisation settings and users; given to whoever registers the organisation), App Builder (designs apps), App Administrator (administers one app: security, lifecycles, workflows, imports; given to whoever creates the app) and Guest (the default for new users, with view-only access).

For your app's own users, add roles that match their jobs:

1. Go to Administrator > Security > Roles and choose Add Role.
2. Enter the role name (for example Project Manager), a normalised name (for example project_manager) and a description, and save.
3. Select the role and add or remove its users in the list on the right.

In TAF Studio, use TAF: Roles & Permissions, TAF: New Role…, TAF: Users & Licences and TAF: Teams. A new role can also start from a copy of an existing role's access, which is applied once, to a role that has no access configured yet.

Entity access and scopes

Open the entity under App Builder > App Setup > Entity, go to the Access tab, and edit a role with the pencil icon. For each of Create, Read, Update and Delete, pick a scope:

There is exactly one access row per role and entity. When an entity is registered, App Administrator gets All and every other role gets None, so a new entity is closed until you open it. To remove a role's access, set all four operations to None.

Common patterns

Start from None or Own and widen access only where a role needs it.

How scopes filter rows

Every query, from a grid, a report, an import or a script, goes through the same steps. The platform works out the user's effective scope for the operation, then:

• Read with Own: returns only records whose creator or owner is the user.
• Read with Team: returns records whose creator or owner is a member of the user's team. The team comes from the organisation hierarchy: people who report to the user, directly or through dotted lines, optionally with peers and the user's manager. If the user has no team members, Team behaves like Own.
• Read with All: adds no filter beyond the tenant.
• Update and delete with Own or Team: the record's creator and owner are checked before the change is made, so a user cannot change a record outside their scope even by id.

Scopes merge across roles by taking the broadest per operation. A user who is both QA (read Own) and Developer (read Team) reads with Team. A narrow grant has no effect while a broader one exists for the same user, so to restrict someone, remove the broader grant.

Screen, menu and component permissions

Named permissions control what people can open and use, separately from which records they see. They can be set in the screen designer, in an entity's Permissions tab, on menu items, and in the central permissions list.

1. Create a permission with a clear name and description, for example canViewApprovalButton.
2. Assign it to users, roles or teams.
3. Apply it: in a component's Permissions tab, pick the configured permission or a data access permission (create, read, update, delete) that decides whether the component is shown or editable.

A whole screen can be restricted to roles in the same way. Those roles still need read access on the entity for the screen to show data. If no permission is applied to a component, it follows the screen's default access. See Screens and forms.

Sharing a single record

When one record must be visible to someone outside their scope, share it with a user, a team or a role instead of widening the role. Sharing is available on entities with Allow Sharing on, which is the default.

Test and troubleshoot

• Impersonate or sign in as a user in the role, and check they can do exactly what you intended and no more.
• If a change does not show immediately, refresh the cache. Effective permissions are cached for a few minutes.
• If a query returns an error rather than rows, the role probably has None for that operation.
• If a user sees too much, look for another of their roles that grants a broader scope.
• If an app's own administrators are refused access to its tables, Studio's TAF: Repair App Access re-runs the app's access setup.