If you're wrangling a big team in Baton, you already know the default roles don't cut it. Maybe you need engineers to see more than interns, but less than admins. Or maybe you just want to stop waking up to a Slack ping that someone nuked a project by accident. Either way, this guide is for you. We'll walk through setting up custom user roles and permissions in Baton so your team can get stuff done—without the chaos.
Why bother with custom roles?
Let’s be real: The bigger your team, the more likely someone will click on something they shouldn’t. Default roles are fine if you’re a team of five, but once you have more people, one-size-fits-all roles become a problem:
- Too much access: People can mess with things they shouldn’t (not always maliciously—sometimes just by accident).
- Not enough access: Folks can’t do their jobs, so you end up rubber-stamping permission requests all day.
- Audit headaches: When something goes wrong, it’s hard to track down who did what if everyone has the same permissions.
Custom roles let you split the difference. You can give people just the access they need, and nothing more.
Step 1: Map out what your team actually needs
Before you even touch Baton, slow down and figure out what roles actually make sense for your team. Don’t just copy the org chart.
Ask yourself: - Who needs to create projects, but not delete them? - Who should be able to invite new users? - Who needs access to billing or settings? - Are there sensitive areas (like API keys, integrations) that only a few folks should touch?
Pro tip: It’s easier to start restrictive and loosen up later. If you make everyone an admin “just in case,” you’ll regret it.
Example roles you might need
- Admin: Full access (but maybe keep this to just a few people).
- Project Manager: Can create/edit projects but can’t change billing or invite users.
- Developer: Can view and edit assigned projects, but can’t delete projects or change settings.
- Read-only: Useful for auditors, consultants, or anyone who just needs to see what’s going on.
Step 2: Get familiar with Baton's permissions model
Baton takes a pretty standard approach: permissions are grouped into roles, and you assign roles to users. Each permission controls access to a specific action or resource—think “Can view projects” or “Can manage billing.”
Things to know: - Some permissions are global (apply everywhere), while some are scoped (just a project, workspace, etc.). - There’s no magic “undo” button. If you give someone too much access and they delete something, you’re probably restoring from backup. - Baton’s built-in roles are a starting point, not a prescription. You can copy and tweak them.
What you can ignore:
Don’t bother with permissions you don’t use. If your team doesn’t touch integrations, don’t stress about who can manage them.
Step 3: Create your custom roles
Here’s where you get your hands dirty.
-
Head to the Roles section:
In Baton, go toSettings
>Roles & Permissions
. You’ll see the list of built-in roles. -
Click “Create Role” or “Add Custom Role”:
Name your role something obvious—skip “Role 1” or “Custom Role 2.” Use “QA Lead” or “Support Viewer” so it’s crystal clear. -
Choose permissions:
You’ll get a list of every permission Baton tracks. Assign only what’s needed. If you’re not sure what a permission does, hover for a tooltip or check the docs. -
Start small: It’s safer to give too little access and add more later.
-
Copy from an existing role: If you like most of what “Project Manager” has, duplicate it and tweak.
-
Save the role:
Double-check your choices—especially destructive actions like “Delete Project” or “Manage Billing.” Save the role.
Pro tip:
Don’t create a dozen slightly different roles unless you have a real need. Complexity will bite you later.
Step 4: Assign roles to users (and groups, if you use them)
Now hand out your shiny new roles.
-
Individual assignment:
Go toUsers
in Baton, pick the person, and assign the relevant role(s). If someone wears two hats, Baton lets you stack roles—permissions are combined. -
Group assignment:
If you use groups (like “QA Team” or “Contractors”), assign the role to the group. Anyone in the group gets the permissions. -
Bulk changes:
For big orgs, Baton's bulk assignment tools can save you lots of clicking. No, you don’t have to do this one by one.
Got a lot of churn?
Set up onboarding checklists so new folks get the right roles from day one. Otherwise, you’ll play catch-up forever.
Step 5: Test before you trust
Don’t just assume your roles work as expected. Test with a non-admin account:
- Log in as a user with the role and try the things they should (and shouldn’t) be able to do.
- Double-check sensitive actions: deleting resources, accessing billing, changing settings.
- If possible, have a teammate try too—they’ll spot gaps you didn’t think of.
What can go wrong? - Someone can’t do their job—expect a lot of “I can’t see X” tickets. - Someone has too much power—expect accidental (or intentional) messes.
Step 6: Audit and tweak as you grow
Your team will change. People shift roles, projects evolve, and what made sense a year ago might be a disaster now.
- Review roles every quarter:
Look for old roles no one uses, or permissions that are too broad. - Remove unused roles:
If a role only has one user and they left months ago, delete it. Less clutter means fewer mistakes. - Adjust for new needs:
When new tools or workflows pop up, update your roles instead of giving everyone a one-off permission.
Don’t let permission creep take over.
If everyone ends up as an admin, you’ve just recreated the same mess you started with.
What works, what doesn’t, and what to ignore
What works: - Keeping things simple. Fewer roles, clear names, and only the permissions you really need. - Testing roles regularly—don’t “set and forget.” - Documenting what each custom role is for (even if it’s just a one-liner).
What doesn’t: - Over-engineering. You don’t need a role for every single job title. - Ignoring regular audits. Roles drift over time, and bad things slip through the cracks. - Giving everyone admin “for convenience.” It’s never worth it.
What to ignore: - Fancy permission schemes you’ll never use. - Roles for hypothetical “future hires.” Build for the team you have now.
Wrap-up: Start small, stay flexible
Custom roles and permissions in Baton aren’t rocket science, but they do take a bit of planning up front. The main thing? Don’t overthink it. Start with simple, restrictive roles, see how your team works, and adjust as you go. You’ll save yourself a lot of headaches—and maybe even a few frantic “who deleted this?” emails.
Got a big team? Keep it simple, review often, and don’t be afraid to tweak. That’s the real secret to keeping your Baton setup sane.