Domo User Management Guide

• Model type: hybrid
• Description: Domo uses a combination of default security roles (Admin, Privileged, Editor, Participant, Social) and custom roles. Custom roles allow admins to define granular permission sets by toggling individual capabilities (e.g., 'Can export data', 'Can manage DataSets', 'Can share content'). Row-level security (PDP - Personalized Data Permissions) is applied at the DataSet level to restrict data visibility by user or group.
• Custom roles: Yes
• Custom roles plan: Enterprise (custom roles feature availability may vary by contract; confirm with Domo)
• Granularity: Role-level permissions control feature access (create, edit, share, admin); PDP policies control row-level data access per DataSet; content sharing controls object-level visibility.

1. Navigate to Admin > Governance > People (or Admin > People) in the top navigation.
2. Click 'Invite People' or the '+' / 'Add User' button.
3. Enter the user's email address.
4. Select a security role (Admin, Privileged, Editor, Participant, Social, or a custom role).
5. Optionally assign the user to one or more Groups.
6. Click 'Send Invite'. The user receives an email invitation to set up their account.

Required fields: Email address, Security role

Watch out for:

• Invited users consume a licensed seat as soon as the invitation is accepted (or in some configurations, when sent - verify with contract).
• If SSO is enforced, users must authenticate via the configured IdP; password-based login may be disabled.
• Admins should verify the correct role is assigned at invite time; changing roles later requires returning to the People admin panel.
• Users invited but who never accept still appear as 'Pending' and may count against seat limits depending on contract.

• Can delete users: Verify in tenant
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Navigate to Admin > Governance > People.
2. Search for or locate the user to deactivate.
3. Click on the user's name to open their profile.
4. Select 'Deactivate' or use the action menu to deactivate the user.
5. Confirm the deactivation. The user will immediately lose the ability to log in.

Watch out for:

• DataSet connectors authenticated with the deactivated user's credentials will fail to refresh; reassign connector ownership before deactivating.
• Content ownership is not automatically transferred; orphaned content may become inaccessible to other users without manual reassignment.
• Deactivated users still appear in the People list with a 'Deactivated' status; they are not removed from the directory.
• If SCIM is enabled, deactivation can be triggered automatically from the IdP when the user is removed or deprovisioned there.

• Where to check usage: Admin > Governance > People - shows total users, active users, and seat counts. Admin > Billing may show license consumption depending on plan.
• How to identify unused seats: Filter the People list by 'Last Login' date in Admin > Governance > People to identify users who have not logged in recently. Domo does not have a built-in 'unused seat' report natively; admins typically export the user list and sort by last login date.
• Billing notes: Domo moved to a credit-based pricing model in mid-2023. User seats are one component of credit consumption alongside data rows, API calls, and feature usage. Seat costs vary significantly by contract tier (Standard ~$50K-75K/year, Enterprise ~$100K-200K+/year, Business Critical ~$200K-500K+/year). Individual user license costs reported up to ~$700/user/year. Actual per-seat costs are negotiated and not publicly listed. Contact Domo account team for current seat pricing and credit allocation details.

Domo operates on a credit-based pricing model (introduced mid-2023), where user seats are one component of overall credit consumption alongside data rows and API calls. Seat costs are negotiated per contract and not publicly listed; individual licenses have been reported up to ~$700/user/year.

Participant and Social seats are typically lower cost than full-user seats, but whether pending (unaccepted) invitations count against seat limits depends on your specific contract terms - verify this before running bulk invite campaigns.

There is no built-in unused-seat report; admins must export the People list and sort by Last Login date to identify candidates for deactivation.

Practitioners managing Domo at scale flag a consistent set of friction points. DataSet connector ownership is not automatically transferred when a user is deactivated, which causes data pipeline failures that must be resolved manually before offboarding.

Deactivated users are never permanently removed from the directory, creating long-term clutter in large organizations. Privileged users can invite new users independently, which can silently consume licensed seats if not monitored.

Azure AD (Entra ID) SCIM provisioning requires additional configuration beyond what Domo's native setup wizard covers, and SSO SAML claims configuration is reported as error-prone.

Common complaints:

• Azure AD (Entra ID) SCIM provisioning is not natively supported without additional configuration; users report difficulty setting up automated provisioning with Microsoft Entra.
• SSO SAML claims token method is limited and can be difficult to configure correctly.
• No true permanent user deletion; deactivated users remain in the directory indefinitely, causing clutter in large organizations.
• DataSet connector ownership is not automatically transferred when a user is deactivated, causing data pipeline failures.
• Pending (unaccepted) invitations may consume licensed seats depending on contract terms, leading to unexpected seat usage.
• Custom roles feature availability and granularity varies by contract tier, causing confusion about what is included.
• The credit-based pricing model introduced in 2023 makes it difficult to predict costs as user counts and feature usage interact with credit consumption.
• Bulk user management via CSV is available but the import process is reported as cumbersome for large user bases.
• No built-in report for identifying inactive or unused seats; admins must manually export and analyze user lists.

Manual administration in Domo is viable for teams managing a stable, moderate-sized user base where every app in the provisioning workflow can tolerate a human-in-the-loop step.

The process is straightforward for individual adds and deactivations, but the absence of automatic content-ownership transfer and the lack of a native unused-seat report create compounding overhead as headcount scales.

Organizations on Enterprise contracts with Okta or Entra ID already configured should evaluate SCIM-based provisioning to eliminate the connector-ownership and pending-invite risks that manual workflows cannot prevent.

Bottom line

Domo's manual user management is functional but carries meaningful operational risk at scale.

The deactivation-only offboarding model (no permanent deletion), the absence of automatic DataSet connector reassignment, and the lack of a built-in stale-user report mean that every departure requires a multi-step checklist to avoid broken pipelines and orphaned content.

For organizations on the Enterprise tier with SSO already in place, SCIM provisioning via an IdP removes the most failure-prone manual steps and is the recommended path for teams managing more than a few dozen users.