Skip to main content

Permissions

Overview​

OutDo controls access with two elements:

  1. Role: one of five roles (Dono, Administrador, Editor, Utilizador or Leitura), assigned to a whole organization or to a workspace.
  2. Access profile: sets what a Utilizador or a Leitura sees and can do with records. Editor and above do not use profiles: they see everything in the workspace.

The same rule applies in the app, on the server and in the API. Access is configured in the Permissões section of the Admin panel, which only organization Administrador (or Dono) accounts see.

Roles​

RoleAPI valueWhoCanCannot
Dono (owner)ownerPays for and answers for the organization. One per organization.Everything, including billing, transferring and deleting the organization.Be removed or demoted by anyone else.
Administrador (admin)adminManages people and access.Everything an Editor can, plus members, access profiles, API keys, automation connections (credentials), organization and workspace settings, and deleting workspaces.Billing, transferring or deleting the organization.
EditoreditorBuilds.Design mode; create, change and delete structure in the workspaces where they are Editor; create workspaces; create, apply and test automations; all records.Members, access, connections with credentials, deleting workspaces.
Utilizador (user)userWorks on records.View, add, edit and delete records in open or granted workspaces, as the profile allows. By default, add, edit and delete are allowed.Any structure change.
Leitura (read-only)viewOnly reads.What the profile grants.Write anything.

The Editor role replaces the former dev role. Existing access keeps working and shows as Editor.

Kiosk is a separate concept: a flag on the user account, not a role. A kiosk user typically also holds the Utilizador role in the workspace it is pinned to. See Organizations & Workspaces.

How roles combine​

A role can be assigned to a whole organization or to a workspace. A person's role in a workspace is the highest of their organization role and their role in that workspace.

  • A workspace role only counts inside that workspace.
  • A workspace role raises access, never lowers it.
  • Organization actions (members, permissions, API keys, settings, creating workspaces) read organization roles only.

To restrict someone, use an access profile. Never use a lower workspace role.

Example: a person with the Utilizador role in the organization and the Editor role in one workspace is Editor in that workspace and Utilizador in all the others. An organization Editor with the Leitura role in a workspace is still Editor there.

Access profiles​

Access profiles apply only to the Utilizador and Leitura roles. Editor and above see everything in the workspace.

Every organization has the default profile Acesso total. With it, a Utilizador adds, edits and deletes records by default. To restrict someone, create another profile and assign it to that person.

The «Permissões» configurator​

Open the Admin panel and go to Permissões. Only organization Administradores (and the Dono) see it. The sidebar has three entries: Sujeitos, Perfis de acesso and Auditoria.

For each subject, the configurator shows:

ElementWhat it shows
Papel máximoThe person's highest role.
Perfil de acesso atribuídoThe profile that applies to a Utilizador or a Leitura.
ExceçõesDifferences from the profile.
VisibilidadeWhat the person sees.
AçõesWhat the person can do.

Changes are staged as a draft and only take effect when you publish them with Publicar.

API keys​

API keys have one of the roles editor, user or view. A key scoped to a workspace stays inside it: it answers 403 in any other workspace and on organization actions.

Plan limits​

The role hides, the plan explains. The Adicionar workspace button stays visible and explains the plan limit when tapped.

Tips​

  • To limit what a Utilizador sees or does, assign an access profile. A lower workspace role restricts nobody.
  • If someone cannot delete records, check the role and the profile: only Utilizador and Leitura are subject to the profile.
  • If someone does not see the Permissões section, they lack the Administrador role in the organization. An Administrador role in a single workspace is not enough.
  • To give someone build access in a single workspace, assign them the Editor role in that workspace.