Summary and recommendation
DataVisor 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.
DataVisor does not offer native SCIM provisioning, and its public documentation contains no structured guidance on admin console paths, user types, or permission models.
Pricing is enterprise-only with custom contracts, so no tier-based feature unlocks are documented publicly.
When every app in your stack lacks a provisioning layer, DataVisor is one more gap with no self-serve remedy.
Quick facts
| Admin console path | Administration / Settings > Users (exact labels vary by deployment) |
| SCIM available | No |
| SCIM tier required | N/A |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Can manage tenant configuration, integrations, and user access. | Cannot extend access beyond the modules and services licensed for the deployment. | Public docs do not fully enumerate built-in role variants. | ||
| Analyst | Can review fraud signals, cases, and workflows exposed to their role. | May not be able to manage tenant settings or other users. | Actual analyst privileges can vary by deployment and product module. |
Permission model
- Model type: role-based
- Description: DataVisor appears to use role-based access for platform administration and investigative workflows, but the detailed permission matrix is not publicly documented in full.
- Custom roles: Unknown
- Custom roles plan: Not documented
- Granularity: Expect separation between administrative access and fraud-operations access, with exact scopes configured per deployment.
How to add users
- Log in to DataVisor as an administrator.
- Open administration or settings and navigate to users.
- Choose the add or invite user action.
- Enter the user's work email or login identifier and assign the appropriate role.
- Save the user and complete any SSO or activation flow required by the deployment.
Required fields: Email address or username, Role
Watch out for:
- Public documentation for user administration is limited, so exact navigation labels may vary.
- If SSO is enabled, upstream IdP assignment may still be required.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | Unknown | Automatic domain-based user add |
| IdP provisioning | Unknown | Not documented |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Public docs do not clearly state whether DataVisor users are disabled, deleted, or both. Treat lifecycle behavior as deployment-specific unless confirmed in-product.
- Open the DataVisor users area as an administrator.
- Locate the user to offboard.
- Disable, revoke, or remove the account using the controls available in that deployment.
- Review any integrations or service credentials associated with the departing admin.
| Data impact | Behavior |
|---|---|
| Owned records | Cases, rules, and fraud-analysis artifacts remain tenant data; public docs do not describe user-owned content semantics in detail. |
| Shared content | Shared dashboards and investigative content remain available to the tenant unless separately removed. |
| Integrations | Review service credentials and integration ownership separately during admin offboarding. |
| License freed | Seat reuse behavior is contract-dependent and not publicly documented in detail. |
Watch out for:
- Offboarding should include token and integration review, not only interactive login removal.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Named platform user | Administrative or analyst access to the DataVisor deployment. |
- Where to check usage: Administration / Settings > Users
- How to identify unused seats: Review the current user roster and any visible last-login data in the platform. No public unused-seat report was verified.
- Billing notes: DataVisor is sold under enterprise contracts. Public seat costs and self-serve licensing details are not documented.
The cost of manual management
Without automated provisioning, hands-on intervention is required for every joiner, mover, or leaver event. For DataVisor specifically, there is no documented deactivation workflow, no confirmed delete-vs-deactivate distinction, and no usage visibility path - meaning offboarding risk is unquantified. License and seat management details are unavailable outside of a direct enterprise contract conversation.
The decision
Every app without a documented provisioning path adds untracked access risk to your environment, and DataVisor currently has no IdP app catalog entry across Okta, Entra, Google Workspace, or OneLogin to fall back on.
If your team is evaluating DataVisor for a regulated or high-velocity environment, assume manual provisioning will be the only option until DataVisor's enterprise solutions team confirms otherwise. Any access governance commitments made around DataVisor should account for fully manual lifecycle management.
Bottom line
DataVisor is an enterprise fraud-intelligence platform with no publicly documented user-management infrastructure - no SCIM, no admin console path, no permission model details, and no community signal on provisioning pain.
Every app without automated provisioning adds operational overhead to your IT and security teams, and DataVisor currently sits firmly in that category. Until the vendor confirms otherwise through a direct enterprise engagement, plan for fully manual access control with no self-serve tooling.
Automate DataVisor 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.
