The enterprise portal has two roles. That is the entire permission model. There are no custom roles, no granular permissions, and no role hierarchies beyond these two.
Admin
Admins have full control over the organization. They can download deliveries, invite new team members, change anyone's role, remove anyone (except the last admin), configure delivery settings, access billing, and view the full activity feed for every action across the organization. Admins can also export the activity feed as CSV.
Member
Members have data access without management powers. They can download deliveries, see delivery history, view their own activity in the feed, and export their own activity as CSV. They cannot invite, remove, promote, or demote anyone. They cannot see other members' activity or modify settings.
Why two roles
Enterprise customers ask for more granular roles all the time (read-only, billing-only, delivery-only, etc.). We kept it to two because two roles cover 95% of real-world needs, stay simple to reason about, and eliminate the "who can do what" confusion that plagues larger role systems. If you have a genuine need we have not anticipated, contact support and we will discuss it.
Detailed reference
What you can expect
- Admin: invite, remove, promote, demote, configure settings, download data, view and export full activity feed
- Member: download data, view and export own activity only
- Both: see the team list, see delivery history, sign out of their own device
- Last-admin rule applies only to the admin role
Limits
- Custom roles are not available
- Billing-only, read-only, or delivery-only roles do not exist
- Tier-specific roles (e.g. "Scale admin") are not a thing, roles are the same on every tier
How it works
Every portal API route is protected by a server-side session check. The session includes the role, which is read from the enterprise_members table. Admin-only routes enforce the role check at request time, not just in the UI, members cannot bypass UI restrictions by calling the API directly.
Role changes take effect on the next request. If an admin demotes a member or removes them, they lose access immediately and their next API call returns a 403. Existing downloads they already completed remain valid locally.
Common misconceptions
- "Admins see more data", false. Admins and members see the same delivery files. Only activity feed scope differs.
- "Members can change their own role", false. Any role change requires an admin.
- "The first admin is special", false. The first admin (Stripe payer) has no superuser powers beyond the admin role. Any admin can demote any other admin, except the last one.
What to do
- Default new invites to member unless there is a specific reason they need admin
- Promote someone to admin before you want to demote or remove yourself
- Review the team list every quarter to catch stale admin grants
At a glance
Role comparison:
- Download deliveries: admin ✓ · member ✓
- View full activity feed: admin ✓ · member ✗
- View own activity: admin ✓ · member ✓
- Export activity CSV: admin ✓ (full) · member ✓ (own)
- Invite members: admin ✓ · member ✗
- Change roles: admin ✓ · member ✗
- Remove members: admin ✓ · member ✗
- Leave organization: admin ✓* · member ✓
- Access billing portal: admin ✓ · member ✗
Last-admin rule
Admins cannot demote or remove the final remaining admin (including themselves). This prevents an organization from being locked out. Add a second admin before attempting to hand over ownership.
Last updated 2026-04-13