Access control decides who can do what in Tines 3B: who can open a space, edit a workflow, use a connector, or manage your team. This article explains the model behind it, so the day-to-day tasks like sharing a space or creating a role make sense. Once you understand the handful of ideas here, the rest of access control is just applying them.
Every access decision in Tines 3B comes down to a single thing called a grant. A grant answers one question:
A grant has three parts:
A principal, the "who," such as a member or a group.
A role, the set of things they're allowed to do.
A scope, the resource the grant applies to.
Part of grant | What it answers | Examples |
Principal | Who is acting | A user, or a group |
Role | What they can do | edit, use, manage, create or share |
Scope | What they can act on | A space, a connector, a group or a network |
For example, giving Alice the "Space editor" role on your Security space is one grant. Everything else builds on this. When you share a space, add someone to a group, or create a service account, you're creating or changing grants.
Principals: the "who"
A principal is whoever a grant applies to. In Tines 3B that's one of two things:
A member, an individual person in your tenant.
A group, a named set of members.
Groups exist so you don't have to grant access person by person. Grant a group access to a space, and every member of that group gets it. A person's overall access is the combination of the grants they hold directly and the grants held by every group they belong to.
Roles and permissions: what someone can do
A role is a named bundle of permissions, and a permission is a single capability, such as "Edit space workflows" or "Use connectors in workflows."
Roles come in two kinds:
Built-in roles ship with Tines 3B and cover the common cases, for example Space viewer, Space editor, and Space manager.
Custom roles are ones your admins define when the built-in roles aren't a precise fit.
Every role is tied to a type of resource. A space role can only be granted on a space, and a connector role only on a connector, so you can't accidentally give someone a space permission on a connector.
One role stands apart: the tenant admin role grants full access across the entire tenant and bypasses every other check. It's deliberately reserved and can't be recreated as a custom role, so keep the number of tenant admins small.
Scopes: the resources you protect
A scope is the resource a grant applies to. Tines 3B protects these scopes:
Spaces, where your workflows live.
Connectors, which hold credentials for the tools you integrate.
Skills, the reusable instructions your AI can draw on.
Networks and service accounts, for routing and automated access.
Groups, since a group is a resource you manage access to as well as a principal that holds access.
The tenant itself, which sits above everything for organization-wide permissions.
How access is inherited
You don't grant access to every workflow or run one at a time. Many resources inherit their access from a parent:
Workflows, drafts, runs, and build chats inherit the access of the space they live in. If you can edit a space, you can edit its workflows.
The tenant sits at the top, so a tenant-wide role applies everywhere beneath it.
This keeps access simple to reason about: to change who can touch a workflow, you change access to its space.
How Tines 3B decides
When you try to do something, Tines 3B checks your grants in order:
Are you a tenant admin? If you hold full tenant access, you're allowed.
Do you have a direct grant on the resource that carries the needed permission? If so, you're allowed.
Does one of your groups have that grant? If so, you're allowed.
If none of those is true, the request is denied.
One thing to know: denial is invisible. Instead of an "access denied" message, Tines 3B simply behaves as if the resource isn't there. This is intentional, so people can't discover what exists by probing for it. If a teammate says they can't find something you can see, it's usually an access question, not a bug.
A few things that work differently
Most access follows the rules above, but a few areas are handled specially:
Personal workflows have fixed access that can't be changed. Every member gets their own, and only they can use it.
Personal chats with Tines 3B are private to the person who created them. No one else (excluding tenant admins) can see them, regardless of other access.
Some resources depend on each other. A connector, skill, or network is only usable inside a space if the space's members also have the right access to that resource. Tines 3B works this out from your grants automatically, which is why adding a connector to a workflow, or adding a member to a space, can occasionally be blocked until access lines up.
Good to know
The access indicators and controls you see in the Tines 3B interface are there to guide you, but they're a convenience, not the security boundary. Every action is checked again on the server when it runs, so what you can actually do always comes down to your grants.
Have a look at the set up your tenant in the right order article to see what you should do next