Roles and permissions

Roles decide who can see which screens and who can create, change, approve or delete which data. You ask Kuika AI for the roles you need, fine-tune them in a matrix, and test the app as each role before anyone else uses it.

Ask Kuika AI for roles

Describe the people and what each of them should be allowed to do. Kuika AI sets up the roles and protects the screens and the data behind them.

Add an admin role with full access and a member role that can view and create expenses but not approve or delete them

Say it in plain words, such as "only an administrator can approve expenses". Kuika AI turns that into a rule on the action itself, so it holds even if someone tries to call the app's data directly. Hiding a button is only a convenience. The real check happens on the server.

If your app has a default role, new sign-ups get it automatically.

How permissions are organized

A role is a named bundle of permissions. Permissions come in three kinds:

• Table permissions. Read, create, update, delete, approve or export on a table, such as approving expenses.
• Screen access. Which screens a role can open.
• Custom permissions. Actions that are not tied to one table, such as a monthly report or a workflow step.

The role matrix

Open More, then Users & access, then the Roles tab. You see each role and a matrix of tables, screens and custom permissions.

• Tick or untick permissions in a role's column.
• Rename or duplicate a role from its column menu, or ask the chat to add a new one.
• Every role needs its own title, because admins pick roles by title.

To give roles to people, open the Users tab. You can assign roles to up to 20 selected accounts at once.

If your company signs people in through its own identity provider, the Roles tab also has an Org roles section. There you map your company's roles or groups to the app's roles. The mapping takes effect on the next Test or Production deploy.

Test as a role

In the preview, open Preview as and pick a role. The app then shows what that person can see, and the server refuses what that role cannot do.

• Full access is your builder session with every permission. It is the default.
• Signed out opens the app without any session.
• Any other role opens the app as that role. You can also use Preview as from a role's column menu in the Roles tab.

Mobile apps have the same control in the corner of the phone-framed preview. Some previews cannot switch roles yet and say so.

Tests in the Testing panel use roles too. Each test runs signed out or as the narrowest role that can see the screen, and you can pick another role next to the run button.

Also good to know

• Assistants inside your app only act on what the signed-in person is allowed to do.
• For sign-up, verification and two-factor, see Sign-in and accounts.