If you’ve ever had a project go sideways because someone “accidentally” deleted a critical file, you know why roles and permissions matter. This guide is for anyone using Bricks who wants to keep their workspace collaborative—but not chaotic. Whether you’re wrangling a small team or trying to avoid a security nightmare, we’ll walk through setting up user roles and permissions the right way. No fluff, no hand-waving, just what actually works.
Why bother with roles and permissions at all?
Let’s be honest: most people set up a new tool and invite everyone with the default settings. That’s fine for a test run, but it’s a mess waiting to happen. Here’s what you risk without proper roles and permissions:
- Sensitive data leaks (oops, everyone can see the admin dashboard)
- Unapproved changes that break stuff
- “Who deleted this?” moments that kill productivity
Bricks gives you control—if you set it up. Let’s get into it.
Step 1: Know What Bricks Actually Offers
Before you dive in, it’s worth understanding what Bricks’ permissions system can (and can’t) do.
What you get: - Predefined roles: Admin, Editor, Viewer (sometimes others, depending on your plan) - Permissions tied to roles: Who can create, edit, delete, view, invite users, etc. - Project-level control: Permissions can often be set per project, not just globally
What you don’t get: - Super-granular, custom permission sets (like “can edit this field but not that one”)—at least, not without workarounds - Enterprise-y stuff like SSO or audit logs—unless you’re on a higher-tier plan
Pro tip: If you need something crazy-specific, Bricks probably isn’t the right tool. But for 95% of teams, what’s built in is enough—as long as you use it.
Step 2: Map Out Who Needs What
You don’t need a whiteboard session. Just grab a notepad and jot down:
- Who needs to change things (admins, editors)
- Who just needs to see things (viewers, clients)
- Who shouldn’t have access at all (contractors, former team members)
Typical needs:
| Role | Needs To... | Bricks Role | |--------------|------------------------------|----------------| | Team lead | Full control | Admin | | Designer | Edit content, no settings | Editor | | Stakeholder | View only | Viewer | | Contractor | Access certain projects only | Custom/Viewer* |
*For project-limited roles, you’ll need to manage access by project.
Don’t overthink it. Fewer roles = less confusion.
Step 3: Set Up Roles in Bricks
Now, let’s get practical. Here’s the usual flow for setting up roles and permissions in Bricks (screens may look a bit different depending on your version, but the basics are the same):
1. Head to the Team or Workspace Settings
- Look for something like “Team,” “Workspace,” or “Organization” in the main menu.
- Open the “Members” or “Users” tab.
2. Add or Invite Users
- Hit the “Invite” or “Add User” button.
- Enter their email.
- At this point, you’ll usually assign them a role—don’t just click through!
3. Assign the Right Role
- Pick from Admin, Editor, Viewer, or any custom roles you’ve set up.
- Double-check what each role can actually do. Some platforms hide a “what’s this?” link that explains the permissions—worth reading before you give out Admin like candy.
4. Set Project-Level Permissions (if needed)
- Some teams want to restrict certain users to specific projects.
- In Bricks, go to the project, then “Manage Access” or similar.
- Add users here, and assign a role just for this project.
Honest take: The UI isn’t always crystal clear, especially if you have a lot of projects. If you’re not sure, test with a dummy account to see what each role can (and can’t) do.
Step 4: Review and Tighten Permissions
Just because you can give someone Admin, doesn’t mean you should. Here’s what actually works in the real world:
- Default to least privilege. Start everyone as a Viewer. Only bump up if they truly need it.
- Audit regularly. Once a month (or quarter), spend 5 minutes reviewing the member list. Remove anyone who shouldn’t be there.
- Limit Admins. Seriously, you probably only need 2-3—just enough to avoid getting locked out.
What to Ignore
- Don’t stress over “power users” unless you actually have compliance needs.
- Don’t create a new custom role for every single user. That’s a recipe for mistakes down the line.
Step 5: Handle Departures and Changes Fast
People leave. Projects end. Don’t let old accounts linger.
- Remove users immediately when they leave. Waiting “just in case” is how breaches happen.
- If someone changes roles, update their permissions right away.
- For contractors, set calendar reminders to review their access at project end.
Pro tip: Many incidents aren’t hacks—they’re old users who never got removed.
Step 6: Test Your Setup (Don’t Skip This)
Don’t assume you nailed it the first time. Here’s how to sanity-check your roles:
- Create a “test” user for each role.
- Log in as those users (or use incognito mode).
- Try to:
- Create, edit, and delete content
- Access admin settings
- See private projects
- Fix anything you catch. Better now than when a client finds out.
Common Gotchas & How to Avoid Them
“I thought they were just a Viewer, but they changed the main template.” - Double-check what each role really allows. Sometimes “Editor” is broader than you’d expect.
“Why is everyone getting admin emails?” - Only Admins should get system notifications. Check the notification settings and prune the admin list.
“A contractor can see every project.” - Use project-level permissions, not workspace-wide roles.
“It’s too complicated, so we just gave everyone Admin.” - That’s not a solution—it’s a security hole. Spend 10 minutes now to save hours of cleanup later.
Quick Reference: Bricks Default Roles
Here’s what each built-in role usually means in Bricks:
- Admin: Full control. Can invite/remove users, change settings, edit/delete anything.
- Editor: Can create and edit content, but can’t change workspace settings or manage users.
- Viewer: Can see stuff, but can’t change anything. Good for clients, stakeholders, or anyone who doesn’t need to edit.
If your organization is bigger or more complex, look into custom roles—but start simple.
Final Thoughts: Keep It Simple, Tighten as You Go
Permissions aren’t glamorous, but they keep your team from shooting themselves in the foot. Start with the basics, keep the number of Admins low, and review access every so often. Don’t get lost in the weeds of “what if” scenarios—if you need more controls later, you can always add them. For most teams, a clear, simple setup in Bricks is all you need to collaborate securely without slowing everyone down.
Now go set it up—and sleep a little better tonight.