Heroku User Management Guide

• Model type: role-based
• Description: Heroku uses a fixed role-based model at the Team level (Admin, Member, Viewer) and at the Enterprise Account level (Enterprise Account Admin). There are no custom roles or granular permission sets. App-level collaborator access exists for individual apps outside Teams. Within Teams, app access can be scoped per-app for Members.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Three fixed Team roles (Admin, Member, Viewer) plus Enterprise Account Admin. App-level access can be granted individually to Team Members, but role definitions themselves are not customizable.

1. Navigate to dashboard.heroku.com and select the Team or Enterprise Account.
2. Click the 'Access' tab.
3. Click 'Add member' (Teams) or 'Invite member' button.
4. Enter the user's email address.
5. Select the role: Admin, Member, or Viewer.
6. Optionally, select specific apps the member can access (for Member role).
7. Click 'Save' or 'Send invitation'.
8. The invited user receives an email invitation and must accept it to join the Team. If SSO is enabled, the user is provisioned on first SSO login (JIT).

Required fields: Email address, Role (Admin, Member, or Viewer)

Watch out for:

• Invited users must have or create a Heroku account to accept the invitation; the invitation is tied to the email address.
• If SSO is enforced on the Team, users must authenticate via the configured IdP; password-based login is disabled for SSO-enforced Teams.
• JIT provisioning via SSO creates the user on first login but does not pre-assign app-level access; an Admin must configure app access separately.
• Adding a user immediately creates a billable seat in Teams; there is no pending/unpaid state after invitation acceptance.
• There is no bulk CSV import for Team members; each user must be invited individually through the dashboard or API.

• Can delete users: Yes
• Delete/deactivate behavior: Heroku Teams does not have a 'deactivate' state for members. Removing a user from a Team immediately revokes their access to all Team apps and resources. The user's personal Heroku account continues to exist; only their Team membership is terminated. There is no soft-deactivation or suspension at the Team level.

1. Navigate to dashboard.heroku.com and select the Team.
2. Click the 'Access' tab.
3. Locate the member to remove.
4. Click the 'Remove' button (trash icon or 'Remove member' option) next to their name.
5. Confirm the removal in the dialog.
6. Access is revoked immediately upon confirmation.

Watch out for:

• Removing the last Admin from a Team is blocked by the dashboard; another Admin must be assigned first.
• Personal API keys or OAuth authorizations created by the removed user are not automatically invalidated; these must be manually revoked.
• If SSO is enforced, revoking the user's access in the IdP does not automatically remove them from the Heroku Team; the Admin must also remove them in the Heroku dashboard (no SCIM deprovisioning is available).
• Heroku does not have native SCIM support, so IdP deprovisioning does not sync to Heroku Team membership automatically.
• For Enterprise Accounts, removing a user from the Enterprise Account does not automatically remove them from individual Teams within that account; each Team must be managed separately.

• Where to check usage: dashboard.heroku.com → Select Team → Access tab (shows current member list and roles); Enterprise Account → Teams tab (shows all Teams and member counts)
• How to identify unused seats: No built-in 'last login' or activity report is available in the Heroku dashboard for Team members. Admins must cross-reference the member list manually or use the Heroku Platform API (GET /teams/{team_name}/members) to enumerate members and audit activity via app deployment logs.
• Billing notes: Team seats are billed monthly per user. All roles (Admin, Member, Viewer) cost the same per-seat rate. Dyno and add-on costs are separate from user seat costs. Removing a user mid-month may result in prorated credit depending on Heroku's billing cycle. Enterprise Account pricing is contract-based and does not follow the per-seat self-serve model.

Every app team running on Heroku Teams faces the same structural friction: there is no bulk import, no CSV upload, and no SCIM. Each member must be invited individually through the dashboard or API. For organizations managing dozens of users across multiple Teams, this compounds quickly.

Viewer seats cost the same per-seat rate as Member seats ($10/user/month, minimum 5 users), offering no pricing relief for read-only stakeholders. Removing a user from an Enterprise Account does not cascade to individual Teams - each Team must be cleaned up separately, manually.

Personal API tokens created by removed users are not automatically revoked. There is also no built-in last-login or activity report in the dashboard, so identifying inactive seats requires cross-referencing the member list against deployment logs or calling the Platform API directly.

The absence of SCIM is the most consistently cited pain point across Heroku's user base. Without it, revoking access in an IdP does not remove the user from Heroku Teams, leaving offboarding gaps that require manual intervention every time.

Admins also flag the flat seat pricing as a frustration - Viewer and Member roles cost the same, which makes read-only access expensive to grant at scale. The lack of any last-login visibility makes license audits guesswork without API scripting.

For Enterprise Account users, the non-cascading removal behavior (Enterprise Account removal does not propagate to individual Teams) is a recurring operational complaint, particularly in organizations with many Teams under a single Enterprise Account.

Common complaints:

• No SCIM support means IdP deprovisioning does not automatically remove users from Heroku Teams, requiring manual cleanup and creating offboarding security gaps.
• No bulk user import or CSV upload; each Team member must be invited individually, which is tedious for large teams.
• Viewer seats cost the same as Member seats ($10/user/month), which users find poor value for read-only access.
• No 'last login' or user activity reporting in the dashboard makes it difficult to identify and remove inactive seats.
• Removing a user from an Enterprise Account does not cascade to individual Teams; admins must remove users from each Team separately.
• Personal API tokens created by removed users are not automatically revoked, creating a potential security risk post-offboarding.
• Fixed role model with no custom roles or granular permissions is considered too coarse for organizations needing fine-grained access control.

Heroku's manual access management is workable for small, stable teams but becomes a liability at scale. The fixed role model covers most standard use cases - Admin, Member, Viewer - but offers no flexibility beyond those three tiers.

The SCIM gap is the sharpest constraint for any organization using a centralized IdP for provisioning. Every app that needs to stay in sync with your IdP will require a compensating workflow, whether that is a scheduled API audit, a manual removal checklist, or a third-party integration layer.

Enterprise Account customers should also account for the two-layer role model: Enterprise Account Admin and Team Admin are separate assignments. An Enterprise Admin is not automatically a Team Admin and must be explicitly added to each Team they need to manage directly.

Bottom line

Heroku's access model is straightforward but deliberately limited: three fixed Team roles, no SCIM, no bulk provisioning, and no cascading deprovisioning across Teams.

For every app under management, offboarding requires manual steps in both the Heroku dashboard and - separately - any IdP, since the two systems do not communicate automatically. Teams with stable headcounts and low turnover will find the dashboard sufficient.

Teams with frequent membership changes, strict offboarding SLAs, or large Enterprise Account footprints will need to build API-driven workflows or accept ongoing manual overhead to keep access state accurate.