Permissions and visibility

The principle: you see what you may do

Permissions in Bricksta are role-based access control (RBAC) — the same model as GitLab, Jira or monday.com. One rule applies: the interface shows exactly what you are allowed to do. Navigation and enforcement read the same rights, so there are no buttons without function and no contradictory grants. Grant someone a right and the matching area appears automatically; remove it and the area disappears.

The four member types

Every member has a type — their built-in starting role. The four types cover the vast majority of cases without touching individual rights. You set the type per person under Organization → Members.

One exception applies to the Administrator type: anyone allowed to manage members can switch freely between Manager, Contributor and External guest — but only an owner or administrator can grant or revoke Administrator. The reason: that type does not add one more permission, it adds all of them at once. If you lack the level, the “Administrator” card sits greyed out and read-only with a note above it; and if the member already is an administrator, every card is locked, because any switch would take the level away from them.

Administrator

May do everything: work on cases, configure templates and automation, manage members and roles, change settings. For the people who set up and maintain your Bricksta organization.

Manager

Works on cases — take, fill in, complete and assign tasks — and sees all cases in the organization, but no configuration (templates, roles, settings). The default type for your team; “Manager” denotes the organization-wide overview, not administrative rights (only the Administrator has those).

Contributor

Sees and works only on cases in which they themselves have an assigned task. For people who contribute selectively without seeing the whole case base.

External guest

No login. Fills in exactly one task via a secure link (e.g. a customer returning a form) and sees nothing else of your organization.

Custom roles: grant extra rights deliberately

Sometimes someone should be allowed to do more than their type provides, without becoming a full admin. For that there are custom roles under Organization → Roles: a named bundle of individual rights that you assign in addition. For example a role “Template editor” containing only the right to edit templates — a Manager with it may maintain templates without gaining everything else an admin has.

On the left you pick a role from the searchable role list; on the right you see who holds it — as a person, through a group, or as a default. Rights are no longer shown there: a role says WHAT someone is responsible for; WHAT they may do lives in the permission profile under Organization → Permissions. You create a new role by naming it. Two roles that mean the same thing can be selected in the list and merged into one via “Merge”. If content languages are configured for the organization, a custom role shows a language switcher below its title: you pick the target language and translate the role name (empty = base language) — member types are already translated.

The permission profile: what someone may do

A permission profile is a named list of rights — “work on cases”, “maintain templates”, “invite members”. You create it under Organization → Permissions and assign it to a person or a group. Someone holding several profiles may do everything they add up to.

Why two objects rather than one: a role answers WHAT FOR — who is the approver in this case, who does the work. A profile answers WHAT — who may complete at all, who may only read. The same person can be approver in one case and nothing at all in another, without anything about their rights changing. That is why a role no longer has checkboxes: it never had ones that could carry this distinction.

And that decides WHERE a right applies. Case-scope rights — everything around tasks — take effect where you are involved: you own the case, you are staffed on a role in it, or a task in it is yours. If a profile should apply everywhere, tick “applies to all cases” on the profile itself. Organization-wide rights such as “maintain templates” need no involvement; they always apply.

A new organization starts with no roles at all: which roles exist is your call — they describe your process, and bricksta cannot guess it. The list stays empty until you add the first one via “+”. If a role is marked “System”, it sits in its own “System roles” section above the rest and is read-only — you can see who holds it, but you can't change its name; it is assigned under Organization → Members. You only see that section if such roles exist in your organization. The base rights of the three member types live under Organization → Permissions, alongside the permission profiles: they answer the same question (“what may someone do”) and therefore belong there. Their case-scope rights apply where the person is involved in the case — they own it, are staffed on a role in it, have a task in it, or are named as its approver.

The baseline of a member type is changed under Organization → Permissions by whoever may manage members. Organization-wide rights — “Manage organization”, “Manage missions”, “Manage members / roles”, “Invite members”, plus “Manage templates”, “Create / start cases” and “Delete case” — additionally require the right “Manage organization”. The reason: a right on the baseline takes effect for every member of that type at once — including yourself. Without “Manage organization” exactly those checkboxes are greyed out and read-only, with a note above them; every case- and task-related right stays fully editable. Who holds a member type is shown in the same view, right below its name: the people of that type, read-only. To move someone to a different type, go to Organization → Members — here too, every thing has exactly one place where it is changed.

Roles can also be created automatically: when you generate a template with AI, it derives fitting roles from the process, assigns them to tasks as the default responsibility and creates them here — marked with an “AI” tag. If a role of the same name already exists, it is reused instead of duplicated. For similarly named roles (e.g. “Case handler” and “Handler”), role management shows a “Possible duplicates” hint: via “Merge” you combine two roles into one — all assignments, rights and template responsibilities move over to the role you keep.

If the two really are different functions, mark the pair as “Not a duplicate” — the suggestion is then gone for good and won't return on your next visit. That decision applies to the whole organization: roles are shared property, and what one administrator has settled shouldn't be put to the others again. Right after the click you can take it back with “Undo”; after that the way back is the “Hidden pairs” line below the hint. It expands the hidden pairs and restores each one individually via “Show again” — and it stays visible even when there is no open suggestion left. The decision is attached to the two roles themselves, not to their names: it survives a rename and only disappears once one of the two roles is deleted.

To see everywhere a role is attached, open the “Usage” tab in the role detail. It has two sections: “Assignments” shows who holds the role (organization-wide, in individual cases, as a default member, or through a member group), “Usage” shows where the role is expected (template responsibility, approver, task library, field permissions, open tasks, pending invitations). Each category expands on its own — entries load only then, so the view stays fast even with very many hits; large numbers appear as “200+”. You can release a link straight from its row, or clear a whole category at once with “Release all”.

A role can only be deleted once nothing depends on it any more — Bricksta checks up front and lists every remaining usage with its count in the delete dialog; “Show” jumps into exactly that category in the “Usage” tab, where you can release it. Nothing is removed silently on delete: a template must not lose its approval rule unnoticed. Completed tasks keep their responsibility permanently, so the record of your cases isn’t falsified after the fact — while the role sits there, deletion stays blocked. You then have two ways out. “Deactivate” is the simpler one: the role disappears from every picker and grants no rights any more, but nothing is rewritten — completed cases still show who was responsible, and you can reactivate the role at any time. Choose “Merge instead …” when the work genuinely moves to another role: pick a target role, every usage moves over and the old role disappears. That cannot be undone.

You deactivate a role from the ⋮ menu at the top right of its detail view. It then sits at the bottom of the list in its own “Deactivated” section, which you show or hide with the “Show” switch — the working list stays tidy and nothing is lost. People who hold the role keep the entry; it simply has no effect any more and is marked “(deactivated)” on them. Wherever the role is already assigned — on running and completed tasks, in templates, on pending invitations — its name stays visible; you just can't pick it again. A role marked “System” cannot be deactivated.

Permission check: why may this person do this here?

So far you have read where a right can come from: the member type, a permission profile (assigned directly or through a group) and involvement in a case. In a concrete dispute the question runs the other way round — „Why can this person not complete the task?“ That is what the permission check under Organisation → Permission check is for. You pick a person and a case; below it every right is listed with its state (granted or denied) and the source it comes from: „Case role: Reviewer“, „Permission profile (via a group): Accounting“ or, for a denied right, the reason — „No active profile carries this permission“.

The permission check does not recalculate anything: it asks the very rule Bricksta enforces. What it says therefore holds — even when it surprises you. Without a case only organisation-wide rights can be answered; case rights need a case, because they depend on involvement in it. And because the permission check exposes someone else’s permission situation, it is reserved for the people who may administer the organisation.

Visibility: making templates and categories private

Beyond “what may someone do” there is “what may someone see”. That is a separate layer. By default templates are visible to everyone. You can set an individual template or a whole category to private — then only the people and groups you explicitly grant can see its cases. You set the grant right on the template or category under Visibility; you maintain groups under Organization → Groups — there you pick a group on the left, add its members on the right and can rename it via the pencil icon next to its name, just like with roles.

Two exceptions always apply: admins see everything, and whoever has their own task in a private case sees that case — otherwise you could not assign them any work.

Field-level rights within a task

For fine tuning you can restrict individual fields in a template's form editor to specific roles — visible only to them or editable only by them. That keeps, say, an internal note reserved for the responsible role while the rest of the task stays open to all handlers. Without such a restriction a field is visible and editable for everyone.