Team Roles and Permissions

Builders uses the role assigned to a member in the main Boilerplate Team workspace. The role controls actions inside team-owned projects, while the team's separate Builders access determines whether the team can use Builders at all.

Understand the four roles

Team Owner is the permanent owner of the team. It is not a role that can be assigned to another member or transferred. Viewer, Designer, and Team Leader are membership roles managed through the Team workspace.

A role never bypasses these additional gates:

• the team must have access to Builders;
• the project and resource must belong to that team;
• the current plan and usage limits must allow the action;
• an external provider must authorize the selected credential.

Compare project and pipeline permissions

Project ownership is the administrative boundary. A Designer can build and remove pipelines inside an existing team project but cannot create, rename, delete, or transfer the project itself.

Transfer is intentionally narrower than ordinary administration. Team Leader can manage and delete a project, but only Team Owner can transfer project or pipeline ownership.

Compare Designer permissions

Do not treat Designer as a non-destructive role. It can change diagrams, publish versions, run workflows, and delete pipelines. Assign it only when the member is trusted to author and operate the team's automations.

Viewer can inspect a diagram and use AI read but cannot modify the workflow or use AI write. It is suitable for review and operational visibility, not workflow authoring.

Compare runs, alerts, and budget access

Viewing budget information does not grant permission to purchase capacity or change the team's subscription in the main Boilerplate service. Product subscription administration and Builders workflow permissions are separate concerns.

A Viewer can inspect run history and alerts but cannot cancel an active run. Connect deterministic error handling and operational alerts rather than relying on a read-only member to intervene.

Compare shared-resource permissions

Builders evaluates shared integrations, database connections, AI agents, General Vault entries, and Static Drive access separately from project actions.

Designer can create and edit integrations, database connections, AI agents, and Drive items, but it cannot delete them. General Vault is stricter: Designer can list and read existing entries but cannot create, edit, or delete them.

Viewer may see integrations, database connections, AI agents, and Drive in their lists without being allowed to open their details. Viewer does not have access to the General Vault list. List visibility is not equivalent to detail access.

External provider permissions still apply. For example, a Team Leader can edit a team integration in Builders, but the stored provider account can reject an operation that exceeds its scopes.

Manage membership and Builders access

Team membership is managed in the Team workspace provided by the main boilerplate.com service. Use it to invite members, change assignable roles, remove members, and grant or remove the team's access to Builders.

Before changing a role or removing a member:

1. Identify projects, pipelines, and shared resources the person currently maintains.
2. Assign another operational maintainer where needed.
3. Save pending workflow changes and verify the last intended version.
4. Check active published triggers and running workflows.
5. Apply the membership, role, or Builders-access change.
6. Reopen Builders and confirm the resulting access with the affected account.

Removing a member does not transfer that person's private projects or resources to the team. Team-owned workflows should not depend on user-owned integrations, Vault values, database connections, AI agents, or files.

Removing the team's Builders access is broader than changing one member's role. It affects the team's ability to use its team-owned Builders workspace even though the team continues to exist in the main Boilerplate service.

Choose the least-privilege role

• Use Viewer for people who review diagrams, runs, alerts, and usage without changing workflows.
• Use Designer for workflow authors who need to edit, test, publish, and maintain pipelines.
• Use Team Leader for administrators who manage projects, shared resources, Vault values, and destructive cleanup but should not transfer ownership.
• Keep Team Owner for the permanent team owner and ownership-transfer operations.

Review roles after organizational changes and before giving a member access to production projects. A role should reflect the most sensitive action the person must perform, not their job title alone.

Troubleshoot forbidden access

• The team is absent in Builders: confirm that the user belongs to the team and that the team has Builders access.
• Project settings are disabled: Designer and Viewer cannot edit team project settings; use Team Leader or Team Owner where appropriate.
• Change ownership is unavailable: project and pipeline transfer requires Team Owner.
• A Designer cannot export a schema: export is available to Team Leader and Team Owner, even though Designer can import and edit workflows.
• A Viewer cannot run or cancel a workflow: Viewer has run visibility, not execution or cancellation permission.
• A Designer cannot change a Vault value: Vault mutation requires Team Leader or Team Owner.
• A Designer cannot delete an integration or Drive item: deletion of shared resources requires Team Leader or Team Owner.
• A button remains disabled after a role change: reopen Builders or refresh the authenticated session, then verify the current team membership and role.
• An allowed action still fails: check plan limits, resource ownership, provider permissions, credential status, and network access.

Next steps

• Workspace and Access
• Personal and Team Resources
• Project and Pipeline Ownership
• Move Pipelines and Change Project Ownership
• Collaborate on a Team Workflow in Real Time
• Resource Ownership and Workflow Visibility
• Integration Ownership and MCP Access