Culture Amp User Management Guide

• Model type: role-based
• Description: Culture Amp uses a fixed role hierarchy: Account Admin, Survey Admin, Manager, and Employee. Permissions are tied to these predefined roles and cannot be granularly customized per user beyond role assignment. Survey Admin access can be scoped to specific surveys. Manager data visibility is driven by the org hierarchy in employee data rather than manual permission grants.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role-level only; no field-level or object-level permission customization available. Survey Admin scope is the finest granularity available.

1. Log in as an Account Admin.
2. Navigate to Settings → Account Users (or the People/Employee Data section depending on module).
3. Click 'Add employee' or 'Invite user'.
4. Enter required fields: first name, last name, email address, and any required demographic/hierarchy fields configured for the account.
5. Assign a role (Employee, Manager, Survey Admin, or Account Admin).
6. Save the record. The user will receive an email invitation to set up their account if SSO is not enforced.
7. If SSO is enforced, the user account is created but login is handled via the configured identity provider.

Required fields: First name, Last name, Email address, Employee ID (if HRIS sync is active, this must match the HRIS record)

Watch out for:

• Email address must exactly match what the identity provider (Okta, Entra, Google Workspace, OneLogin) will assert if SSO is enabled; mismatches prevent login.
• If an HRIS integration is active, manually added users may be overwritten or deactivated on the next HRIS sync if they do not exist in the HRIS.
• Demographic fields required for reporting (e.g., department, location, manager) must be populated for the user to appear correctly in survey filters and manager hierarchies.
• Culture Amp does not support SCIM; automated provisioning must be handled via HRIS integration (BambooHR, Workday, etc.) or CSV import, not via IdP directory sync.

• Can delete users: No
• Delete/deactivate behavior: Culture Amp does not permanently delete employee records from the admin UI. Users are deactivated (marked inactive), which removes their login access and excludes them from future surveys, but their historical data and survey responses are retained in the platform for reporting continuity. Permanent data deletion requires a formal request to Culture Amp support and is subject to their data retention and privacy policies.

1. Log in as an Account Admin.
2. Navigate to Settings → Account Users (or Employee Data).
3. Search for the employee by name or email.
4. Open the employee record.
5. Select 'Deactivate' or change their status to 'Inactive'.
6. Confirm the deactivation. The user will immediately lose the ability to log in.
7. If an HRIS integration is active, deactivation can also be triggered automatically when the employee is marked inactive or terminated in the HRIS system.

Watch out for:

• If HRIS integration is active, manually deactivating a user in Culture Amp may be reversed on the next sync if the HRIS still shows them as active. Deactivation should be driven from the HRIS where possible.
• Deactivated users still appear in historical survey data and reports; they are not anonymized automatically upon deactivation.
• Permanent deletion of personal data (for GDPR/CCPA compliance) requires contacting Culture Amp support directly and cannot be self-served.
• Deactivating a Survey Admin mid-survey does not automatically reassign their survey admin responsibilities; surveys they managed may become unmanaged.

• Where to check usage: Settings → Account Users → filter by Active status to see current active employee count. Billing seat count is typically reconciled by Culture Amp based on active employee records at contract renewal.
• How to identify unused seats: No built-in 'last login' report is prominently documented in the help center. Admins can review active employee lists and cross-reference with survey participation data to identify employees who have never logged in or participated. Contact Culture Amp support for usage reporting.
• Billing notes: Culture Amp pricing is per employee per year, billed annually, with custom pricing negotiated via sales. All active employees in the platform count toward the seat total regardless of how frequently they use the platform. Deactivating employees reduces the active count. No self-serve billing portal is documented; billing changes are managed through the Culture Amp account team.

Without an HRIS integration, every new hire requires a manual add in Settings → Account Users, with required fields including first name, last name, email, and any demographic fields needed for reporting hierarchies.

Missing or inconsistent demographic data breaks manager visibility and survey filters - meaning every app-level report downstream is only as accurate as the data entered at provisioning time.

Offboarding is deactivation-only; permanent deletion is not self-serve and requires a formal request to Culture Amp support. Deactivating a Survey Admin mid-cycle does not automatically reassign their survey responsibilities, creating an operational gap that must be caught and resolved manually.

The most consistently reported friction point is the absence of SCIM: teams using Okta or Entra ID for directory sync have no automated provisioning path and must maintain a parallel HRIS integration or manual CSV workflow.

SSO (SAML 2.0) is supported for authentication via Okta, Entra ID, Google Workspace, and OneLogin, but setup requires Culture Amp support involvement and cannot be fully self-configured.

Email address mismatches between the IdP assertion and the Culture Amp employee record are a recurring cause of login failures.

Admins also flag the lack of a read-only Survey Admin role - the finest available granularity is Survey Admin scoped per survey, which still carries write permissions.

Common complaints:

• No SCIM support means automated provisioning from Okta, Entra, or other IdPs is not possible; HRIS integration or CSV import is the only automated path.
• SAML/SSO setup requires involvement from Culture Amp support and cannot be fully self-configured.
• Email address mismatches between the IdP and Culture Amp employee records cause login failures that require admin intervention to resolve.
• Manual CSV imports are error-prone when demographic fields are inconsistent, leading to broken manager hierarchies and incorrect survey filters.
• No granular custom roles; admins cannot create a role with, for example, read-only access to all surveys without full Survey Admin write permissions.
• Deactivating users does not automatically reassign their manager relationships or survey admin responsibilities.
• No self-serve permanent data deletion; GDPR/CCPA deletion requests must go through Culture Amp support.
• Active employee count for billing purposes is not always transparent; customers report confusion about what triggers a seat count change.
• If HRIS sync is active, manual user changes can be silently overwritten on the next sync cycle.

Culture Amp is best suited to organizations that already run a supported HRIS (BambooHR, Workday, etc.) and can use that integration as the provisioning backbone. Teams without a connected HRIS will carry ongoing manual overhead for every joiner, mover, and leaver event.

The fixed role model is workable for most HR and People Ops teams but will frustrate organizations that need read-only reporting access without admin write permissions. No custom roles exist at any plan tier, so role design decisions are constrained from the start.

Bottom line

Culture Amp's user management is straightforward if your HRIS is connected and your org hierarchy data is clean - provisioning, deactivation, and manager visibility all flow from that single source of truth.

Without it, every joiner and leaver becomes a manual task with real downstream risk: broken survey filters, incorrect manager hierarchies, and deactivated users whose SSO sessions may still be active until the IdP is updated separately.

The absence of SCIM is the defining constraint; plan your provisioning architecture around HRIS sync or the REST API before committing to a manual workflow at scale.