Workspace access is intentionally layered. A role decides what a member can do inside the Workspace; a connected project’s delegation decides whether that Workspace may perform the same category of work for that specific project.
Check owner authority
Is the user the Workspace owner? If yes, the action is allowed immediately. If no, proceed.
Check Workspace role
Does the member’s Workspace role grant the required permission? If no, the action is denied. If yes, proceed.
Check project delegation
For connected-project actions: did the technical owner delegate that category to the Workspace? If no, the action is denied. If yes, proceed.
Action allowed
The team member is successfully authorized to perform the action.
Permission groups
Default and custom roles
Workspaces may use default roles and owner-defined custom roles. A custom role should contain only the permissions needed for the job—such as a Finance Manager with billing access or a Developer with provider configuration access.
When assigning a management permission, also grant the matching view permission. A user who cannot view the relevant state cannot safely manage it.
Invitations
An email invitation does not add a user immediately. The invited AvraAPI account reviews the Workspace name, assigned role, and requested permissions, then accepts or rejects the invitation. Membership and role assignment happen only after acceptance.
Owner authority
The actual Workspace owner retains Workspace authority even if a temporary role assignment is missing or being repaired. Ownership is not merely a role label that can be changed by another member.
Frontend visibility is only a convenience. Every permission is enforced again by AvraAPI on the server. Do not rely on a hidden button as an authorization control.
