Every week, our support team fields questions similar to "How do I make someone an admin?" or "Why can't my manager see their budget?" The answer almost always lives in one place: the Permissions tab.
This Tip Tuesday is your guide to understanding how roles work, how to assign them, and how to avoid the most common pitfalls.
How Roles Work in Awardco
Roles are the security layer that controls who sees the Admin button and what they can do once they're there. Every role has three components:
- Members β Who is in the role (specific users and/or metadata-based filters)
- Data Visibility β Whose data they can see (e.g., everyone, direct reports only, peers)
- Permissions β Which admin areas they can access (e.g., Reports, Budgets, Programs, SSO, Integrations)
Key concept: Any user assigned to any role will see the Admin button β but their view inside Admin is limited to exactly what that role allows. Users without a role simply won't see the Admin button at all.
Default Roles on Your Platform
When your Awardco instance was first created, three default roles were set up:
Role | What It Does |
|---|
Super Admin | Full platform access. All permissions are required and cannot be modified. |
All Reports | Broad reporting visibility, but not full Super Admin powers. |
Manager | Typical manager-level access and data visibility. |
Beyond these defaults, you can create custom roles tailored to your organization's needs β for example, "Finance Admin," "Reports Only," "SSO Admin," or "HR Coordinator." This lets you follow a least-privilege approach and keep Super Admin reserved for a small, trusted group.
How to Add Someone to a Role
Roles are managed exclusively in the Permissions tab β not by editing individual user profiles in User Management.
- Go to Admin β Users β Permissions.
- You'll see a list of all roles on your platform. Find the role you want to update.
- Click the three-dot menu (β¦) next to the role β Edit.
- In the Members step, you have two options:
- Users β Manually search for a specific person and check the box next to their name.
- Metadata filters β Automatically include users based on HR data fields (e.g., #Manager = Yes, #Department = HR). Within a single metadata field, multiple values use OR logic; across different fields, logic is AND.
- Click Next through Data Visibility (choose whose data this role can see) and Permissions (select which admin areas to enable).
- Click Save & Apply.
Pro tip: Metadata-based membership is the recommended best practice β roles will automatically update when your user file is refreshed, so you don't have to manually add or remove people as your org changes.
The Manager Role Gotcha
This is the single most common permissions issue we see in support: "My manager can't see their budget" or "A manager can't approve recognitions."
The root cause is almost always not a permissions problem β it's a user file problem. Here's why:
The Manager role often has a "Limit to supervisors" toggle enabled. When this is on, the platform checks whether the user actually has direct reports in the user file hierarchy (via Supervisor ID). If they don't, they're excluded from the role β even if their #Manager metadata says "Yes."
What to check first:
- Does the user have a correct Supervisor ID linking their direct reports to them in the user file?
- Is the "Limit to supervisors" toggle on for the Manager role?
- Does the user's metadata (e.g., #Manager = Yes) match the role's membership filter?
If your organization can't always keep Supervisor IDs perfectly accurate but does maintain a #Manager metadata field, consider relying on the metadata filter and turning off the supervisor-only restriction.
Common Role Scenarios
What You Want to Do | How to Do It |
|---|
Give someone reports-only access | Create or edit a role with Reports permissions enabled and other areas (Programs, Budgets, SSO) turned off. |
Let IT configure SSO | Create a dedicated "SSO Admin" role with only SSO/Login settings permissions, or temporarily add them to Super Admin. |
Grant API key access | Edit a role and enable the Admin Integrations / API permissions, then assign the user to that role. |
Make someone a Super Admin | Go to Admin β Users β Permissions β find the Super Admin role β Edit β add the user in the Members step β Save & Apply. |
Quick Myths vs. Facts
Myth | Fact |
|---|
"There's a default role called Employee." | There isn't. Users without any admin role are simply standard employees who don't see the Admin button. |
"Uploading a #Role column in my user file will assign permissions." | It won't. #Role metadata can be used to filter membership into a permissions role, but it doesn't automatically grant admin access. Roles are managed only in the Permissions tab. |
"SSO or HRIS automatically assigns permission roles." | No. SSO and HRIS manage user provisioning and login β not permission roles. Roles must be configured in the Permissions tab (manually or via metadata filters). |
Join the Conversation
Roles & Permissions is one of those areas that's easy to set up once but can drift over time as your org changes.
- Have you audited your roles recently to make sure the right people have the right access?
- Have you created any custom roles that have been a game-changer for your team (e.g., "Finance Only," "Regional HR")?
- What's the trickiest permissions issue you've had to troubleshoot?
Drop your tips, questions, and lessons learned in the comments β your fellow admins will thank you! π¬