Teams & Permissions
ADD CREATE uses a permission system that lets you control who can see and do what — both at the platform level and within individual projects.
Account Types
Section titled “Account Types”Every user account has a platform-level role:
| Role | Description |
|---|---|
| User | Standard project and generation usage, subject to project permissions |
| Power User | Elevated user role for expanded operational usage |
| Brand Manager | Brand governance access, including Brand Controls workflows |
| Administrator | Full administrative access across platform controls |
Teams are groups of users that can be granted access to projects together. Instead of adding each person individually to every project, you add the team once and all members get access.
Creating a Team
Section titled “Creating a Team”- Navigate to Teams in the sidebar.
- Click New Team.
- Enter a team name and an optional description.
- Click Create.
As the creator, you are automatically added to the team as a Team Admin.
Team Roles
Section titled “Team Roles”Within a team, each member has one of two roles:
| Role | Description |
|---|---|
| Member | Inherits the team’s project permissions |
| Team Admin | Can add and remove other team members |
Adding Members
Section titled “Adding Members”- Open the team detail page.
- Click Add Member.
- Enter the user’s email address and select their role.
- Click Add.
Only team admins and platform admins can add or remove members.
Project Access Levels
Section titled “Project Access Levels”Access to individual projects is controlled at three levels:
| Level | What it allows |
|---|---|
| Read | View the project, its files, and completed artifacts |
| Write | Upload files, run generation jobs, and view artifacts |
| Admin | Full access: manage permissions, edit project details, delete the project |
Granting Access
Section titled “Granting Access”You can grant access to a project for:
- Individual users — a direct permission for that person.
- Teams — all current and future members of the team inherit the team’s permission level.
How Permissions are Resolved
Section titled “How Permissions are Resolved”When the system checks whether someone can access a project, it resolves permissions in this order:
- Platform Administrator — always has full access.
- Project Owner — the person who created the project always has full access.
- Direct Permission — if the user has been granted a specific permission on this project.
- Team Permission — if the user belongs to a team that has been granted access.
Related Guides
Section titled “Related Guides”Operational Playbook
Section titled “Operational Playbook”Use this playbook for repeatable administration:
- Review metrics and policy thresholds on a regular schedule.
- Apply the smallest viable permission or policy change first, then observe impact.
- Communicate policy changes to affected teams before enforcement windows.
Troubleshooting
Section titled “Troubleshooting”If governance controls are not behaving as expected:
- Confirm scope (global vs team vs user) and precedence rules.
- Validate that users are assigned to the correct teams and role groups.
- Re-check policy thresholds and effective dates when behavior appears delayed.
Frequently Asked Questions
Section titled “Frequently Asked Questions”Why are users still blocked after a policy change?
Section titled “Why are users still blocked after a policy change?”They may be affected by a stricter scope layer or stale session context.
How do we avoid over-permissioning?
Section titled “How do we avoid over-permissioning?”Use role-based defaults and grant temporary exceptions with explicit review dates.
What should we monitor weekly?
Section titled “What should we monitor weekly?”Spend trends, failure rates, exception volume, and policy-threshold pressure by team.