Medallia User Management Guide

• Model type: role-based
• Description: Medallia uses a role-based access control model where roles define both feature access and data visibility. Data access is further scoped by organizational hierarchy units (e.g., region, location). Roles are assigned per user and can be combined with data access rules to restrict what feedback records a user can view.
• Custom roles: Yes
• Custom roles plan: Not documented
• Granularity: Role-level feature permissions combined with hierarchical data-access scoping. Granularity of custom role configuration is not publicly documented.

1. Log in to the Medallia platform as an Administrator.
2. Navigate to the Administration section (exact path not publicly documented; typically Administration > Users or similar).
3. Select the option to create or invite a new user.
4. Enter required user fields (see required_fields).
5. Assign one or more roles to define feature access.
6. Assign data access rules or organizational unit scope.
7. Save or send invitation to the user.

Required fields: First name, Last name, Email address, Role assignment

Watch out for:

• Medallia's admin UI is behind a customer-authenticated portal; exact steps may differ by implementation version or contracted modules.
• Role and data-access configuration complexity often requires involvement from a Medallia implementation consultant, especially for large organizations.
• SSO-provisioned users may still require manual role assignment within Medallia if SCIM is not configured.
• No native SCIM provisioning is documented publicly; user lifecycle management via IdP is limited to SAML SSO authentication, not automated provisioning/deprovisioning.

• Can delete users: Unknown
• Delete/deactivate behavior: Medallia's public documentation does not confirm whether users can be permanently deleted. Deactivation (disabling account access) is the commonly referenced approach. Permanent deletion behavior is not publicly documented.

1. Log in as an Administrator.
2. Navigate to the user management section of the Administration console.
3. Locate the target user account.
4. Disable or deactivate the account to revoke platform access.
5. Confirm the action.

Watch out for:

• Because Medallia pricing is based on data record volume rather than named seats, deactivating a user does not automatically reduce costs.
• Without SCIM, deprovisioning is not automated via IdP; administrators must manually deactivate users when employees leave.
• No public documentation confirms whether deactivated users can be reactivated or if their historical data access is preserved.

• Where to check usage: Not documented
• How to identify unused seats: No publicly documented method for identifying inactive or unused user accounts within the admin console. Admins would need to review last-login data if exposed in the UI.
• Billing notes: Medallia does not use a per-seat licensing model. Costs are driven by EDR volume. Adding or removing users does not directly affect the contract cost. Pricing is negotiated with Medallia sales and is not publicly listed.

Because Medallia's pricing is based on EDR volume rather than seats, adding or removing users does not directly change contract costs. However, the operational cost of manual user management is real: without SCIM, IT teams must manually provision and deprovision accounts when employees join, move, or leave.

Role and data-access configuration is complex enough that large organizations frequently require involvement from a Medallia implementation consultant. Changes to role assignments or data access rules can take time to propagate, and some changes may require opening a support ticket with Medallia directly.

Reviewers on G2 and Gartner Peer Insights consistently flag that Medallia's user management and permissions setup carries a steep learning curve, particularly for enterprise deployments with complex organizational hierarchies.

The admin interface is described as complex, and role plus data-access configuration is frequently cited as requiring professional services involvement.

The absence of native SCIM provisioning is a recurring pain point: IT teams report that offboarding must be handled manually, increasing the risk of orphaned accounts. Some users also note that role assignment changes can be slow to take effect.

Common complaints:

• Users report that the Medallia admin interface is complex and that role and data-access configuration often requires professional services or implementation consultant involvement.
• Reviewers on G2 and Gartner Peer Insights note that user management and permissions setup has a steep learning curve, particularly for large enterprise deployments with complex organizational hierarchies.
• The lack of native SCIM provisioning means IT teams must manually manage user lifecycle events (onboarding/offboarding) rather than automating them through an IdP.
• Some users report that changes to role assignments or data access rules can take time to propagate or require admin-level support tickets to Medallia.

Medallia is appropriate for enterprise organizations that need deep experience data management and can absorb the operational overhead of manual user lifecycle management. Teams with a dedicated Medallia administrator or an implementation partner will be better positioned to manage the role and data-access complexity across every app account in their environment.

Organizations that require automated provisioning and deprovisioning through an IdP should confirm SCIM availability directly with Medallia before contracting, as no public documentation confirms a SCIM 2.0 endpoint exists. SSO via SAML (Azure AD, Okta) is documented, but it handles authentication only - not provisioning.

Bottom line

Medallia delivers robust experience management capabilities at the enterprise tier, but its user administration demands hands-on effort: every app account must be created, role-assigned, and deactivated manually without SCIM automation.

The EDR-based pricing model means seat counts don't drive cost, but the absence of automated provisioning creates real IT overhead at scale.

Organizations should factor in consultant involvement for initial role and hierarchy configuration, and should validate SCIM support directly with their Medallia account team before assuming IdP-driven automation is possible.