Skip to main content

​
Summary

Roles and permissions determine who can manage configuration, who can operate workflows, and who can see or change more sensitive details in TruAgents. The current app clearly exposes role and teammate management as first-class concepts, which means access is part of the operating model, not an afterthought.

​
Who this is for

  • Owners and admins managing teammates
  • Teams troubleshooting access confusion
  • Anyone trying to understand why different users may see different actions or details

​
What the current app suggests

The team-management surface appears to include:
  • teammate email
  • locked status
  • role
  • organization membership
Other parts of the app also suggest that some details or controls are admin-sensitive, which means role affects both navigation and what users can do inside specific workflows.

​
The right mental model

  • roles are about responsibility, not just identity
  • permissions shape both setup access and operational access
  • access issues are often role issues, not product bugs

​
What roles usually govern

Even without documenting every rule inline, the product model strongly suggests roles affect:
  • who can manage teammates
  • who can change organization-level defaults
  • who can access more sensitive setup pages
  • who can operate or review workflows with elevated responsibility

​
Permission problems usually fall into one of three buckets

​
The user has the wrong role

The person exists in the organization, but their level of access does not match the job they are expected to do.

​
The account is locked

This is different from limited permissions. A locked teammate is an account-state issue, not just a role mismatch.

​
The user is asking for the wrong surface

Sometimes the person expects a self-service profile action, team-management action, and org-admin action to all live in one place. They do not.

​
How to reason about access safely

  • start by asking what the person is trying to do
  • decide whether it is self-service, teammate management, or organization admin work
  • only then decide which role level should own that action
Simple version: do not ask “why is access weird?” before asking “what kind of access is this supposed to be?”

​
Good team habits

  • assign roles based on responsibility, not convenience
  • keep owner/admin access limited and intentional
  • use role changes as deliberate workflow decisions
  • check locked state separately from role when troubleshooting
  • document who should own sensitive settings and approvals

​
Common misunderstandings to avoid

  • Adding someone to the organization is not the same as giving them the right level of access.
  • A locked teammate is different from a teammate with limited permissions.
  • Permission questions should usually be answered with the dedicated matrix or team-management docs, not guesswork.
  • A user seeing less than another user does not automatically mean the product is inconsistent.

​
Plain-English example

If someone cannot update organization defaults, the first question is not “Is the page broken?” It is:
  1. is this an org-admin action
  2. does this teammate have the right role
  3. is the account active and unlocked