Team Roles and Permissions: Who Can See What in the Dashboard
The most common way a team dashboard goes wrong is not a security bug. It is one shared admin login, passed around, because setting up proper access looked like more work than it was worth on the day.
It works, right up until somebody leaves, or a member deletes a template nobody told them was load-bearing, and there is no way to establish who did what. This guide covers the roles AtlasLinq gives you, what each one can actually do, and how to pick.
There are three roles
Enterprise Admin is not a role you hand out. It belongs to the person whose subscription the team runs on, and it is the only role with access to billing, seats, and the ability to grant roles to anybody else.
Manager runs the team day to day. Members, object cards, templates, departments, company settings. A manager cannot touch billing and cannot change anybody's role, including their own, which is the boundary that makes the role safe to give out.
Viewer is read-only: analytics and leads, and nothing else.
Members with no role are not locked out of AtlasLinq. They keep their card, their own analytics, and everything else the app does. They simply have no access to the team dashboard, which for most of a team is the correct setting.
Who can do what
This table is generated from the same permission matrix the dashboard enforces, so it cannot drift away from the product:
| Capability | Enterprise Admin | Manager | Viewer |
|---|---|---|---|
| View analytics | Yes | Yes | Yes |
| View and export leads | Yes | Yes | Yes |
| See the team roster | Yes | Yes | No |
| Invite and remove members | Yes | Yes | No |
| Create and edit object cards | Yes | Yes | No |
| Edit card templates and departments | Yes | Yes | No |
| Edit company settings and branding | Yes | Yes | No |
| Assign dashboard roles | Yes | No | No |
| Manage billing and seats | Yes | No | No |
| View the audit log | Yes | No | No |
The same check runs on the server, not only in the browser. Hiding a button is a courtesy to the person using the dashboard; it is not access control, and it is not what is protecting your billing page.
Giving somebody a role
Roles are assigned from Team in the dashboard, and only the Enterprise Admin sees the controls.
- At invite time. The invite form has a role selector next to the email field. Pick one and the role is waiting when they accept.
- Afterwards. Each active member in the roster has a role dropdown. Change it and it takes effect on their next dashboard load.
Managers can invite people, but the invitations they send carry no dashboard role. Handing out access stays with the Enterprise Admin, so a manager cannot quietly widen the circle.
Everything is written down
Role and membership changes are recorded in an audit log, under the Activity tab in Settings. It is visible to the Enterprise Admin only.
It records who did it, to whom, and when, for:
- Granting, changing, and revoking a dashboard role
- Inviting and removing members
- Seat changes
The entries are written by the server rather than by the dashboard, which is what makes them worth having. A log the client writes records what the browser claimed happened. A log the server writes records what happened.
Picking a role
Default to Viewer. It covers the actual reason most people ask for dashboard access, which is wanting to see how the cards are performing and who has come in, and it cannot cause an afternoon of cleanup.
Promote to Manager when somebody is doing the work: running onboarding, maintaining templates, looking after object cards. The test is whether they need to change things or only to see them.
Keep Manager deliberately small. Not because managers are dangerous, but because a roster where everybody can edit everything gives you the same problem as the shared login: no way to tell, afterwards, who changed what.
Removing access is not removing a member
These are two different actions and it is worth knowing which one you want.
Revoking a role takes somebody out of the dashboard and leaves everything else alone. Their card keeps working, they stay on the team, their seat is still theirs. Use this when somebody changes jobs internally, or when a project finishes and the access was only ever for the project.
Removing a member takes them off the team entirely. Use this when they leave.
Dashboard roles and paid seats are separate things. A seat is a person on your team with a company card. A role is what that person can do in the dashboard. Most of your seats will have no role at all, and nothing about that is a problem.
A reasonable starting shape
For most teams: the Enterprise Admin is whoever owns the budget. One or two Manager accounts for the people who actually maintain the thing, usually someone in operations or marketing. Viewer for anybody who asks. Everybody else has a card and no dashboard access, and never notices.
If you are setting up a team from scratch, the Enterprise team setup guide covers the steps before this one.
Roles, the audit log, and the team dashboard come with Enterprise.
See how teams use AtlasLinq → or compare plans