In Tines 3B, access is controlled by a single question: can this person, in this role, act on this thing? The "thing" is a scope, and scopes are how Tines 3B protects the resources you work with every day. Understanding scopes helps you reason about who can see and do what.
What a scope is
A scope is the target of a permission grant, the resource being protected. Every grant links three things together: a principal (a user or group), a role (a bundle of permissions), and a scope (the resource). When Tines 3B checks whether you can view a space or use a connector, it's looking for a grant that matches you and that scope.
Each resource carries its own permissions, prefixed by its scope kind. A space uses permissions like space:read and space:write, a connector uses connected_app:use, and so on. The prefix tells you which kind of resource the permission applies to.
Resource types
Tines 3B recognizes a fixed set of scope kinds, each corresponding to a type of resource:
Spaces. Where workflows, runs, and chats live.
Connectors. The connected apps your workflows and chats reach out to.
Skills. Reusable, build-time capabilities a space can draw on.
Networks. The routes that execution traffic can travel through.
Groups. Collections of users, which are themselves shareable.
Service accounts. Non-human identities that workflows can act as.
Above all of these sits the tenant scope. A grant at the tenant level applies across your whole Tines 3B tenant rather than to one resource, which is how tenant-wide abilities like creating spaces or viewing every connector are expressed.
Scopes have a hierarchy
Not every resource needs its own grants. Many resources are children of a space and simply inherit its access. Workflows, branches, runs, executions, and chats all resolve to their parent space's scope, so a workflow's access is whatever the space's access is. This keeps permissions simple: you grant access once, at the space, and everything inside it follows.
The tenant scope sits at the top. A tenant admin, holding the special allow_all permission there, bypasses every other check.
A group can be both sides
User groups are worth a special mention, because they play two roles.
A group is a principal when it holds access to something, for example when a whole team is granted editor access on a space.
The same group is a scope when the question is about its membership, since adding someone to a group is itself a grant on that group. There's no separate membership list; membership is modeled the same way as every other access decision.
Scopes can depend on each other
Resources rarely stand alone. A space that runs a workflow calling a connector depends on that connector, and a space routing traffic through a network depends on that network.
Tines 3B never copies access from one scope onto another. Instead it derives availability on demand by looking at the grants on both resources at once. Because grants stay the single source of truth, a change on either side takes effect the next time the check runs, with nothing to keep in sync.