Summary and recommendation
Meltwater user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Meltwater is a media intelligence platform with a role-based access model built around two tiers: Account Admin and User. Admins control module-level access (Explore, Engage, Analyze, Radarly) at the individual user level. There are no custom roles and no documented field- or object-level permissions beyond module assignment.
There is no native SCIM provisioning. Every app in a modern SaaS stack that supports automated lifecycle management via an IdP will handle onboarding and offboarding without manual steps - Meltwater does not. All user provisioning, role changes, and deprovisioning must be completed manually inside the admin console at Settings → User Management.
Quick facts
| Admin console path | Settings → User Management (accessible to Account Admin role only) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Subscription-based |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Account Admin | Full account access: add/remove users, manage roles, configure SSO, manage billing contacts, access all searches and dashboards, manage integrations. | All plans (at least one Account Admin required per account) | Counts as a licensed seat | Only Account Admins can invite new users or change roles; there is no secondary admin tier documented publicly. | |
| User | Access to searches, alerts, dashboards, and reports as configured by admin. Can create and share content within the account. | Cannot manage other users, change account settings, or configure SSO. | All plans | Counts as a licensed seat; seat count is negotiated at contract time | Seat count is fixed at contract signing; adding users beyond the contracted seat count may require a contract amendment. |
Permission model
- Model type: role-based
- Description: Meltwater uses a role-based access model with at minimum two tiers: Account Admin and User. Admins control access to specific modules (e.g., Explore, Engage, Analyze) based on the products included in the subscription. Granular module-level permissions are assigned by the admin at the user level.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Module-level access control (e.g., restrict a user to only the Engage or Explore module). No documented field-level or object-level permissions.
How to add users
- Log in as Account Admin.
- Navigate to Settings → User Management.
- Click 'Invite User' or equivalent button.
- Enter the new user's email address.
- Select the role (Admin or User) and applicable module access.
- Send invitation; user receives an email to set their password and activate the account.
Required fields: Email address, Role assignment
Watch out for:
- Adding users beyond the contracted seat limit is not self-serve; requires contacting Meltwater account management.
- Invited users must activate via email link before they can log in.
- SSO-enabled accounts may require the user's email domain to match the configured IdP domain.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | No | Not documented |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Meltwater's help documentation does not publicly confirm whether users can be permanently deleted or only deactivated/removed from the account. The admin interface includes a mechanism to remove user access, but the distinction between deactivation and hard deletion is not documented in publicly accessible help content.
- Log in as Account Admin.
- Navigate to Settings → User Management.
- Locate the user to be removed.
- Select the option to remove or deactivate the user.
- Confirm the action.
| Data impact | Behavior |
|---|---|
| Owned records | Searches, alerts, and dashboards created by the removed user may remain in the account but ownership transfer behavior is not publicly documented. |
| Shared content | Shared dashboards and reports created by the removed user are expected to remain accessible to other users, but this is not explicitly confirmed in public documentation. |
| Integrations | Any API keys or integration connections associated with the removed user's account may be affected; not documented publicly. |
| License freed | Removing a user is expected to free the seat for reassignment within the contracted seat count, but this is not explicitly confirmed in public documentation. |
Watch out for:
- Seat count reduction below the contracted minimum requires a contract renegotiation; removing users does not automatically reduce billing.
- No publicly documented self-serve offboarding checklist for transferring owned content before removal.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Named User Seat | Access to contracted Meltwater modules (e.g., Explore, Engage, Analyze, Radarly). Seat count and module access are defined at contract signing. | Custom; bundled into annual contract. Median contract ~$25,000/year per Vendr data. Per-seat cost varies by total seats and modules. |
- Where to check usage: Settings → User Management (shows active users and seat utilization; exact path not publicly confirmed)
- How to identify unused seats: No publicly documented automated unused-seat detection. Admins must manually review last-login data if available in the user management panel.
- Billing notes: All contracts are annual minimum 12-month agreements. Seat counts are fixed at contract time. Adding seats mid-contract requires a contract amendment with Meltwater account management. Reducing seats typically requires waiting for renewal.
The cost of manual management
Seat counts are fixed at contract signing under annual minimum 12-month agreements. Adding users beyond the contracted seat count is not self-serve - it requires a contract amendment through Meltwater account management. Reducing seats below the contracted minimum typically requires waiting until renewal.
There is no documented automated unused-seat detection. Admins must manually review last-login data in the User Management panel to identify inactive accounts. No self-serve offboarding checklist for transferring owned content before user removal is publicly documented.
What IT admins are saying
Reviewers on G2 and TrustRadius consistently flag contract lock-in as a friction point: seat counts are difficult to reduce without waiting for renewal, and scaling down mid-contract requires negotiation.
Adding users beyond the contracted count routes through a sales or account management process rather than a self-serve flow.
The absence of SCIM provisioning is a recurring complaint among IT and operations reviewers. The admin interface is noted as lacking bulk management features, which compounds the manual overhead for teams managing larger user populations.
Common complaints:
- Reviewers on G2 and TrustRadius note that seat counts are locked into annual contracts, making it difficult to scale down without waiting for renewal.
- Multiple reviewers mention that adding users beyond the contracted seat count requires going through a sales/account management process rather than self-serve.
- Some users report that the admin interface for user management is not intuitive and lacks bulk management features.
- Reviewers note the absence of SCIM provisioning makes automated user lifecycle management (onboarding/offboarding via IdP) unavailable, requiring manual admin steps.
- Contract lock-in and difficulty reducing seat count at renewal are recurring themes in pricing-related reviews on G2 and TrustRadius.
The decision
Meltwater fits teams that can accept fully manual user lifecycle management and whose seat count is stable enough to commit to annual contracts. The two-tier role model (Admin / User) with module-level access is sufficient for most media monitoring use cases but will not satisfy organizations that require granular, role-based access policies.
Teams that need IdP-driven provisioning and deprovisioning for every app in their stack should treat the absence of SCIM as a hard constraint, not a roadmap item - no SCIM support is documented in official Meltwater resources as of the policy date.
Bottom line
Meltwater requires fully manual user management: invitations, role assignments, module access, and deprovisioning all happen inside the admin console with no API or IdP automation available. Seat counts are locked into annual contracts, so both over-provisioning and under-provisioning carry real cost consequences.
Teams that operationalize every app through an IdP-driven joiner/mover/leaver workflow will need to maintain a separate manual process for Meltwater until SCIM support is introduced.
Automate Meltwater workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
