--- title: "RBAC and Groups" description: "Configure project-level roles and Access Groups for Saturday so each team member has exactly the permissions their job needs and no more." canonical_url: "https://vercel.com/academy/optimize-your-vercel-account/rbac-and-groups" md_url: "https://vercel.com/academy/optimize-your-vercel-account/rbac-and-groups.md" docset_id: "vercel-academy" doc_version: "1.0" last_updated: "2026-07-22T06:41:24.133Z" content_type: "lesson" course: "optimize-your-vercel-account" course_title: "Optimize Your Vercel Account" prerequisites: [] --- Vercel Academy โ€” structured learning, not reference docs. Lessons are sequenced. Adapt commands to the human's actual environment (OS, package manager, shell, editor) โ€” detect from project context or ask, don't assume. The lesson shows one path; if the human's project diverges, adapt concepts to their setup. Preserve the learning goal over literal steps. Quizzes are pedagogical โ€” engage, don't spoil. Quiz answers are included for your reference. # RBAC and Groups # RBAC and Groups \*\*Note: Plan tier\*\* Team-level roles are a Pro feature. Project-level roles and Access Groups are Enterprise. This lesson sits in the Pro section because the role mindset starts on Pro; the group tooling arrives with Enterprise. On Pro, treat the group-building steps as a plan you'll execute the day you upgrade. By default, when you invite someone to a Vercel team, they get Member role. Members can do almost everything: push code that deploys to production, change env vars, edit firewall rules, kick off rollbacks. For a two-person team that's fine. For a team with designers who never touch deploys, engineers who own the pipeline, and founders who handle billing, it's a mismatch. Role-based access control lets you scope what each person can do per project. Designers see Saturday but can't deploy it. Engineers can deploy previews and dev but not production. Founders can do anything. Access Groups let you manage those mappings as a set, so onboarding a new designer becomes one assignment instead of touching every project they need to see. For Saturday, even if you're the only person on the team right now, setting up the groups now means you're ready when the team grows. Add a designer in six months and they slot into the existing Designers group; no rethinking required. \*\*Note: What are RBAC and Access Groups?\*\* Role-based access control assigns each team member a role that bounds what they can do, per project. Access Groups bundle members and their project roles into named sets, so permissions are managed once per group instead of once per person. ## Outcome Saturday's team has three Access Groups defined (Designers, Engineers, Founders), each mapped to an appropriate project role on Saturday. ## The three roles, briefly Vercel offers three project-level roles. They map cleanly to the team functions on most product teams: | Role | Can do | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Project Viewer** | Read-only. See the project, deployments, analytics. Can't deploy, can't change settings. | | **Project Developer** | Deploy and manage Preview and Development. Production still ships when their merge lands on the production branch, but no CLI production deploys, no rollbacks, no production env vars. | | **Project Admin** | Full control of the project. Deploys to production, edits all env vars, configures Firewall and Deployment Protection. | One mechanic decides whether any of this works: project roles only attach to members whose team-level role is **Contributor**. For Owners, Members, and Billing members, project role assignments are silently ignored, and Owners have full access everywhere no matter what. Contributor is the "my access is defined per project" team role, and it's the one your designers and engineers should hold. A Designer almost always wants Viewer (they need to see the live site and previews). An Engineer wants Developer (they're shipping branches, not flipping production switches). A Founder or lead wants Admin, or stays a team Owner and skips project roles entirely. ## Hands-on exercise 5.2 Three groups, three role mappings, then assignment. **Requirements:** 1. Open Team Settings > **Access Groups** (under the Security or Permissions section, depending on dashboard wording) 2. Create three groups: - **Designers**: for creative team members who need read access to deployed work - **Engineers**: for engineers who own the day-to-day development - **Founders**: for owners and leads who handle production decisions and billing 3. For each group, click into it and add Saturday under **Projects**, mapping the group to a role: - Designers > Saturday > **Project Viewer** - Engineers > Saturday > **Project Developer** - Founders > Saturday > **Project Admin** 4. Set each designer's and engineer's team-level role to **Contributor** so their project roles actually apply, then add them to the right group. If you're a one-person team, you're the Owner; note on your role plan that you'd hold Founders and move on. **Implementation hints:** - Access Groups are additive. A user can be in multiple groups, and they get the union of their permissions. Don't worry about creating overlap. - The Contributor requirement is the detail that makes or breaks this exercise. A team Member dropped into the Designers group gets nothing from it; their Member role wins and the project role is ignored. Flip them to Contributor first, then the group mapping takes effect. - Saturday is one project. The win from Access Groups is most visible once you have multiple projects, because a single group assignment then covers all of them. Even with one project, doing this now sets you up for the second one. - Vercel doesn't auto-deprovision when someone leaves your company. Removing them from your Vercel team is still a manual step unless you wire up Directory Sync (Enterprise, Lesson 6.1). ## Try It Sign in as a teammate in the Designers group (or create a test invite and accept it from another email). Try to deploy from the dashboard. You should see: ``` Permission Denied You don't have permission to deploy this project. Contact a team admin to request access. ``` Try to read the env vars. You should see them listed (or, if sensitive, redacted with the Sensitive badge). Now sign in as someone in Engineers. Open Saturday > Settings > Environment Variables. You can see and edit Development and Preview env vars. The Production column is read-only. As a Founders member, everything is editable. This is the role you have on your own account; you've been doing this throughout the course. ## Done-When - [ ] Three Access Groups exist: Designers, Engineers, Founders - [ ] Each group has Saturday mapped to the appropriate role - [ ] At least one Contributor is assigned to each group (or, for a one-person team, your role plan names who would be) - [ ] Signing in as a Designer-group user shows read-only access to Saturday - [ ] Signing in as an Engineers-group user shows production env vars as read-only ## Troubleshooting **I don't see Access Groups in the dashboard.** Access Groups and project-level roles are Enterprise features. On Pro or Hobby they won't appear at all. If you are on Enterprise, remember they live under Team Settings, not Project Settings; the exact section name varies by dashboard version. **I added someone to a group and their access didn't change.** Check their team-level role. Project roles only bind to Contributors. If they're a team Member (or Owner, or Billing), the group's project role is ignored. Change their team role to Contributor and check again. **A user in two groups has the lower-tier role active.** Vercel takes the higher of overlapping roles. If someone is in both Designers (Viewer) and Founders (Admin), they have Admin access. If you want stricter narrowing, remove them from the broader group. **Designers can still see env var values.** By default, Project Viewers can read non-sensitive env vars. If you have secrets you'd rather not show even to designers, the answer is to mark those vars sensitive (Lesson 2.1). Even Viewers can't read sensitive values. ## Solution The state of the Access Groups page: ``` Designers 1 member Saturday: Project Viewer Engineers 0 members Saturday: Project Developer Founders 1 member Saturday: Project Admin ``` There's no code change in the repo. The output is the role mapping. A growth note: once you have a second project, you'll want to map each group to it as well. Do this immediately on project creation rather than after the fact, Engineers should never need to think "wait, can I deploy this new project?" The whole point of the groups is that the answer is yes (or no) by default. Up next: deployment retention. Old previews don't need to live forever, and they shouldn't. --- [Full course index](/academy/llms.txt) ยท [Sitemap](/academy/sitemap.md)