Aha! User Management Guide

• Model type: hybrid
• Description: Four primary workspace-level roles (Owner, Contributor, Reviewer, Viewer) combined with three orthogonal administrator sub-roles (Account, Billing, Customization) that can be layered onto any primary role. Permissions are per-workspace, so a user can have different roles in different workspaces. On Enterprise+, custom account-level and workspace-level roles can be created and assigned additively.
• Custom roles: Yes
• Custom roles plan: Enterprise+
• Granularity: Per-workspace role assignment; custom roles map to individual account-settings pages or workspace-settings pages. Custom workspace roles require the assignee to hold at least a Contributor seat.

1. Ensure an open paid seat exists (or that the plan allows free Reviewer/Viewer addition).
2. Navigate to User menu → Settings → Account → Billing and add seats if needed via 'Add or remove paid seats' modal.
3. Navigate to User menu → Settings → Account → Users.
4. Click 'Add user'.
5. Enter the new user's email address, first name, and last name.
6. Select the product from the Product dropdown (only subscribed products with available seats appear).
7. Assign workspace-level permissions (Owner, Contributor, Reviewer, or Viewer) per workspace.
8. Optionally assign administrator sub-roles (Account, Billing, Customization).
9. Click Save / Send invite. The user receives an email invitation.

Required fields: Email address, First name, Last name, Product selection, At least one workspace permission or admin sub-role

Watch out for:

• Inviting a user when no paid seats are available is blocked; seats must be purchased first.
• Adding a paid user triggers an immediate pro-rated charge to the credit card on file.
• For manually-billed accounts, adding users requires contacting Customer Success at support@aha.io.
• Default permissions can be pre-configured at User menu → Settings → Account → Users → 'Set default permissions' to speed up bulk invitations.
• SSO JIT-provisioned users are created automatically on first login but receive no workspace permissions by default - an admin must assign permissions manually after account creation.
• Removing a user from the IdP does NOT remove or disable them in Aha!; manual deactivation is required.

• Can delete users: Yes
• Delete/deactivate behavior: Both Disable and Delete are available from User menu → Settings → Account → Billing → Users. Disable suspends access and frees the paid seat while retaining the user record and all created content indefinitely. Delete permanently removes the user from the user list but retains all records, documents, and comments they created; however, reports can no longer be created or filtered by the deleted user. The sole billing administrator cannot be disabled or deleted.

1. Navigate to User menu → Settings → Account → Billing → Users.
2. Locate the user using the search bar, filter dropdowns, or sortable columns.
3. Click the user's name to open their profile.
4. Click 'Disable' to deactivate (or 'Delete' to permanently remove).
5. Click the appropriate confirmation button to save changes.
6. Alternatively, use bulk edit: check one or more user checkboxes, click 'Bulk edit users', set enabled/disabled status, and click Apply.

Watch out for:

• Removing a user from the IdP does NOT disable or delete them in Aha!; deprovisioning must be performed manually in the Aha! admin console.
• If total seat count is reduced below the current number of active users, Aha! automatically deactivates users, retaining those who logged in most recently.
• Deleted users' profile information is retained until they are deemed inactive by Aha!; the user is removed from the visible user list immediately.
• The sole billing administrator cannot be disabled or deleted; a second billing admin must be designated first.
• Bulk disable is available but bulk delete is not documented as a supported bulk action.

• Where to check usage: User menu → Settings → Account → Billing → Current plans (shows paid seats purchased, allocated, and active per product). User menu → Settings → Account → Billing → Users (sortable 'Last active' and 'Seat in use' columns for per-user visibility).
• How to identify unused seats: Export the full user list to CSV via User menu → Settings → Account → Users → 'Export users' button (requires Billing admin). Exported file includes 'last active' date and 'seat in use' flag, enabling identification of inactive paid-seat holders.
• Billing notes: Adding a paid user triggers an immediate pro-rated credit card charge. Seat reductions apply at end of the current billing period. Manually-billed accounts must contact Customer Success to add users. Billing frequency changes also require contacting Customer Success. Ideas portal users are always free and unlimited regardless of plan.

Adding a paid user (Owner or Contributor) triggers an immediate pro-rated charge to the card on file. Manually-billed accounts must contact Customer Success at support@aha.io to add users at all, adding a process step to every hire. Removing a user from your IdP does not disable them in Aha!

• deprovisioning must be performed separately in the Aha! admin console. If seat count drops below active users, Aha!

auto-deactivates by recency of login, not by role or team - meaning the wrong users may lose access. Reviewer and Viewer seats are included at no additional charge on Enterprise and Enterprise+ plans, but on Premium every user including Reviewers consumes a paid seat.

The absence of SCIM is the most consistently raised operational complaint in the Aha! community.

Users report that JIT-provisioned accounts arrive with no workspace access, requiring a manual follow-up step for every new hire who authenticates via SSO. Offboarding is a documented risk: departed employees remain active until an admin manually disables or deletes them.

The Reviewer role draws separate criticism - Reviewers cannot change idea status, score ideas, or post public portal comments from within Aha! without switching to the ideas portal.

Custom roles that could address these gaps are locked to the Enterprise+ tier.

Common complaints:

• No native SCIM means all user provisioning and deprovisioning is manual; removing a user from the IdP does not remove them from Aha!.
• JIT via SAML creates accounts for any IdP-authenticated user on first login, but assigns no workspace permissions - an admin must manually configure access after account creation.
• No automatic deprovisioning: offboarded employees remain active in Aha! until an admin manually disables or deletes them.
• Reviewer role is too restrictive for many use cases: Reviewers cannot change idea status, score ideas, or post public portal comments from within Aha! without switching to the ideas portal.
• Per-seat pricing at the Owner/Contributor level is considered expensive for users who only need light access, with no mid-tier between Contributor and Reviewer.
• Custom roles (which could address Reviewer limitations) are locked to the Enterprise+ plan, the highest pricing tier.

Representative quotes (verbatim):

Reviewers are currently unable to change an idea's status, visibility in the portal, score ideas, or even post public comments without navigating over to the idea portal.

• Community user comment on Aha! Big Ideas feedback portal (https://big.ideas.aha.io/ideas/APP-I-3078)

We have 8 people that desire to work as reviewers... but we would currently have to upgrade them to Premium level to make them Contributors with access to much more than they need - and at a steep price.

• Community user comment on Aha! Big Ideas feedback portal (https://big.ideas.aha.io/ideas/APP-I-3078)

Aha! is a viable choice for product teams that can absorb manual provisioning overhead or that operate at a scale where IdP-driven automation is not yet critical.

The hybrid permission model - four workspace roles plus three orthogonal admin sub-roles, with per-workspace assignment - gives granular control but requires deliberate configuration for every app and every user. Teams on Enterprise+ gain custom roles and seat-group allocation, which partially offset the SCIM gap.

Teams on Premium or Enterprise should budget admin time for every onboarding and offboarding event, and should establish a recurring audit cadence using the CSV export (Billing admin required) to catch stale paid seats.

Bottom line

Aha! requires fully manual user lifecycle management: no SCIM, no automatic deprovisioning, and JIT SSO that creates accounts without workspace access.

Every app without SCIM adds friction at both onboarding and offboarding, and Aha! is a meaningful example - departed employees stay active until an admin acts, and new SSO users need a second manual step before they can do any work.

The permission model is capable and granular, but that granularity comes with configuration overhead. Teams should maintain a regular audit of the user list via CSV export and treat IdP removal as a trigger for a separate Aha!

deactivation step, not a substitute for one.