Understanding Roles and Permissions
Organization Admin · Event Coordinator · Treasurer · Board Member · Document Manager · Family Lead
StandShare manages sensitive financial data, personal information, and organizational operations. Not everyone should have access to everything. The role-based access control (RBAC) system ensures that each person can see and do only what is appropriate for their responsibilities.
Three types of users
Before talking about roles, it helps to understand that StandShare has three distinct user types. These are not roles — they are structural categories that determine the scope of what someone can access.
Platform Admin
A Platform Admin is a StandShare staff member who manages the platform itself. Platform Admins hold the Admin role, which grants a wildcard permission — every check in the system is automatically passed. Platform Admins work across all organizations and are not bound to any single tenant.
Platform Admins are required to have two-factor authentication (TOTP) enabled in production. They cannot disable it.
Org Member (Org User)
An Org Member is anyone who belongs to an organization's tenant — coordinators, treasurers, board members, family leads, and family workers. Their permissions are resolved through the roles assigned to them in the Admin > Users > Roles interface. This is the most common user type.
Permissions for Org Members are cached for up to 5 minutes. If an admin changes someone's role, the change takes effect on the user's next request after the cache expires — typically within 5 minutes.
Guest Worker
A Guest Worker is a person who participates in events but is not a full member of the organization. They are granted the Guest Worker role, which gives them access to only their own assignments, events, library content, the member directory, and the ability to submit feedback. They have no access to financial data, scholarship workflows, or any management features.
The building blocks: permissions
Permissions are the most granular unit of access control. Each permission represents a single capability, such as "view all family accounts" or "approve scholarship requests."
Permissions are organized into categories that correspond to different areas of the platform:
| Category | What it covers | Example permissions |
|---|---|---|
| Family Accounts | Viewing and managing family profiles and financial data | View own account, view all accounts, create families, edit transactions |
| Event Management | Creating events, assigning workers, settling financials | Create events, manage rosters, enter commissions, settle events |
| Scholarships | Submitting and processing scholarship requests | Submit own requests, view all requests, approve/deny, process payments |
| Fund Management | Organizational fund configuration and tracking | View fund balances, configure distribution rates, export fund reports |
| Documents | Uploading and managing compliance documents | Upload own documents, upload for any family, manage templates, view compliance |
| Communication | Announcements, notifications, and messaging | Create announcements, send bulk messages, manage notification templates |
| System Administration | Platform configuration and oversight | Create/edit roles, assign roles, configure security, view audit logs |
| Library | Document and media library content | View content, manage content, view analytics, manage categories |
| Ledger | Financial ledger entries and fund transfers | View ledger, create entries, void entries |
| Billing | Subscription and payment information | View billing, manage billing |
| Guest | Guest worker access | View own events, view own assignments |
| Venue Operations | Venue profile, users, and billing | Manage venue profile, manage venue staff, view venue billing |
| Operations | Operator dashboard and metrics | View operations dashboard, export metrics |
| Collaboration | Cross-organization partnerships and worker sharing | Manage partnerships, manage assignments, settle collaboration payouts |
The "view_all implies view_own" rule
Within a category, holding the "view all" permission automatically satisfies a "view own" check. For example, a user with family_account.view_all can also pass a family_account.view_own check — they do not need both assigned explicitly. This applies only to view permissions; edit permissions do not chain in this way.
Roles: bundles of permissions
A role is a named collection of permissions. Instead of assigning dozens of individual permissions to each user, you assign one or more roles, and the user inherits all the permissions from their roles.
A user can have multiple roles. When a user has more than one role, their effective permissions are the union of all permissions from all their roles. For example, if Role A grants "view events" and Role B grants "manage rosters," the user can do both.
The Admin role
The Admin role is special. It is one of two system roles that cannot be modified or deleted. Users with the Admin role automatically bypass all permission checks — they can access everything and perform any action. This role is intended for Platform Admins (StandShare staff) and the organization's designated top-level administrator.
The Venue Admin role
Venue Admin is the other system role. It is used for venue portal administrators and carries a fixed set of venue-specific permissions. Like Admin, it cannot be edited or deleted.
Built-in role templates
StandShare seeds each new tenant with 12 pre-configured roles covering common organizational structures. These are regular roles — they can be renamed, edited, or deleted (with the exception of Admin and Venue Admin, which are system roles). See the Permission Matrix for the full capability breakdown.
NPO organization roles:
- Organization Admin — full tenant-scoped access across all features
- Event Coordinator — full event lifecycle management, including settlements (but not reversals)
- Treasurer — finance-only: accounts, scholarships, fund management, ledger, billing view
- Board Member — read-only oversight: accounts, events, funds, compliance, ledger/billing view
- Document Manager — full document lifecycle: upload for any family, templates, distribute, compliance
- Family Lead — own-scope: view/edit own family, transactions, scholarships, documents
- Family Worker — single permission: view events only
- Guest Worker — view own assignments and events, library content, directory, submit feedback
Venue and operator roles:
- Venue Admin (system role) — full venue portal: profile, settings, users, billing
- Venue Coordinator — day-to-day venue operations; no billing or user management
- Gate Attendant — scan-only access: view venue profile and venues
- Operator Admin — venue portal + operations dashboard + event reports + groups + API keys
- Operator Coordinator — read-only: venue view, operations dashboard, event reports, groups
Custom roles
Every role other than Admin and Venue Admin can be edited. You can also create entirely new roles:
- Navigate to Admin > Users, then click the Roles tab.
- Click Create Role.
- Enter a name and description.
- Select the specific permissions this role should have from the category list.
- Click Save.
The new role is immediately available to assign to users. For step-by-step instructions, see Manage Users and Roles.
When you edit a role's permissions, the change applies to all users who hold that role. Saved changes take effect on those users' next request (within the 5-minute permission cache window).
How permissions control what you see
Permissions do not just control what actions you can perform — they also control what you see in the user interface. StandShare dynamically adjusts the navigation, dashboard, and page content based on your permissions:
| If you have this permission | You see |
|---|---|
family_account.view_own (only) | Your family's account page with your balance and transactions |
family_account.view_all | A searchable list of all family accounts |
scholarship_requests.approve_deny | A "Pending Approvals" section on your dashboard and the approval queue page |
system_admin.create_edit_roles | The "Role Management" page in the admin section |
event_management.create_edit_events | "Create Event" buttons and the event management interface |
operations.view_dashboard | The "Operations" section in the admin navigation |
admin_panel.view_users | The Users section under Admin |
Navigation items, action buttons, and entire pages are hidden when you do not have the corresponding permission. This keeps the interface clean and focused on what is relevant to your role.
How role changes work
When a user's roles change, their cached permissions are invalidated. The next request they make loads their updated permissions from the database. Role changes take effect within the 5-minute cache window — the user does not need to sign out.
Changing someone's roles requires step-up authentication because it is a sensitive operation. The admin making the change will be prompted to re-verify their identity before the change is saved.
Role changes also require the system_admin.assign_roles permission. Role edits (changing what permissions a role contains) require system_admin.create_edit_roles.
Example: how it all fits together
Imagine an organization with this role structure:
Maria — Organization Admin
- Can access everything within the organization's tenant
- Can manage events, finances, documents, users, and roles
James — Event Coordinator + Treasurer
- Has two roles assigned
- Can create events, manage rosters, enter commissions, and settle events (from Event Coordinator)
- Can also view all accounts, approve scholarships, and export financial reports (from Treasurer)
- Cannot change system settings or manage other users' roles
Keisha — Family Lead (Carter Family)
- Has the Family Lead role
- Can view her family's balance, transactions, and documents
- Can submit scholarship requests for her children's activities
- Cannot see any other family's data
David — Family Worker (Carter Family)
- Has the Family Worker role
- Can see that he is assigned to work Stand 148 at Saturday's game
- Cannot see the Carter Family's account balance or transactions
Angela — Guest Worker
- Has the Guest Worker role
- Can see her event participation history
- Cannot see any family's financial data
Each person sees a different version of the platform, tailored to their responsibilities.
Key takeaways
- StandShare has three user types: Platform Admin, Org Member, and Guest Worker
- Permissions are granular capabilities organized into categories
- Roles are bundles of permissions — users can hold multiple roles simultaneously
- Admin and Venue Admin are the only system roles; all others can be edited or deleted
- Permissions are cached for up to 5 minutes — role changes take effect within that window
view_allimpliesview_ownin the same category- Role changes require step-up authentication
Next Steps
- Manage Users and Roles — invite users, assign roles, and manage the Users page
- Permission Matrix — full table of what each built-in role can do
- Security and Privacy — how step-up authentication protects sensitive operations