Demandbase User Management Guide

• Model type: role-based
• Description: Demandbase uses a fixed role-based access model with three predefined roles: Admin, User, and View Only. Roles are assigned per user at the platform level. No custom role creation is available through the UI.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Platform-level role assignment only; no object-level or feature-level permission granularity beyond the three fixed roles.

1. Log in as an Admin and navigate to Settings → User Management.
2. Click 'Invite User' or 'Add User'.
3. Enter the new user's first name, last name, and work email address.
4. Select the appropriate role: Admin, User, or View Only.
5. Click 'Send Invite'. The user receives an email invitation to set their password and activate their account.
6. If SSO is enabled, the user must still be pre-created in Demandbase before their first SSO login; the invitation step is still required.

Required fields: First name, Last name, Work email address, Role (Admin, User, or View Only)

Watch out for:

• No SCIM provisioning is available; every user must be manually created in the Demandbase UI regardless of IdP configuration.
• No Just-in-Time (JIT) provisioning: users who attempt SSO login without a pre-existing Demandbase account will receive an error.
• Invitation emails may land in spam; advise new users to check junk folders.
• SSO configuration (Okta SAML) does not automate user creation or deactivation.

• Can delete users: No
• Delete/deactivate behavior: Demandbase does not permanently delete user accounts. Admins can deactivate a user, which revokes login access and removes the user from active seat counts, but the user record is retained in the system for audit and data-continuity purposes.

1. Log in as an Admin and navigate to Settings → User Management.
2. Locate the user in the user list.
3. Click the action menu (ellipsis or gear icon) next to the user's name.
4. Select 'Deactivate User'.
5. Confirm the deactivation in the prompt. The user's access is revoked immediately.

Watch out for:

• Because there is no SCIM, offboarding requires a manual deactivation step in Demandbase even if the user is deprovisioned in the IdP (Okta). SSO deactivation alone does not deactivate the Demandbase account.
• Annual contracts mean that reducing seat count mid-term may not result in immediate cost savings; verify terms with the account team.
• No automated offboarding workflow exists; admins must track departing employees and manually deactivate accounts.

• Where to check usage: Settings → User Management (shows list of active and inactive users; Admins can audit seat consumption here).
• How to identify unused seats: Review the 'Last Login' column in Settings → User Management to identify users who have not logged in recently. No automated idle-user reporting is available natively.
• Billing notes: Demandbase uses annual or multi-year contracts with custom pricing. Seat counts are fixed at contract signing. Adding seats mid-term requires a contract amendment. Reducing seats typically takes effect at renewal. Onboarding fees (~$29,000 typical) are separate from subscription costs.

Because there is no automated provisioning, offboarding carries compounding risk: revoking a user in Okta does not deactivate their Demandbase account, so a separate UI step is always required. Seat counts are fixed at contract signing, and mid-term reductions typically do not yield savings until renewal.

Unused seats from missed deactivations have direct cost implications given annual contract structures.

The most consistent friction reported by Demandbase admins centers on the absence of automated provisioning. No bulk CSV import exists, making large onboarding cohorts a fully manual, sequential process.

Admins also flag the lack of native idle-user reporting: identifying stale accounts requires manually reviewing the Last Login column in Settings → User Management, with no automated alerts or exports built in.

Common complaints:

• No automated provisioning (SCIM or JIT): every user must be created manually in the Demandbase UI, even when Okta SSO is configured.
• Manual offboarding risk: deprovisioning a user in Okta does not deactivate their Demandbase account; admins must perform a separate manual step.
• No bulk user import via CSV, making large-scale onboarding time-consuming.
• No custom roles or granular permission controls beyond three fixed roles, limiting least-privilege access configurations.
• Annual contract structure means unused seats cannot easily be reclaimed for cost savings mid-term.
• No native idle-user or unused-seat reporting; admins must manually audit last-login data.

Demandbase's permission model is fixed at three roles - Admin, User, and View Only - with no custom role creation available through the UI. Every app or workflow that depends on least-privilege access will hit a ceiling here, since there is no object-level or feature-level permission granularity beyond these three fixed roles.

Admin grants unrestricted platform access including billing-adjacent settings, so that role should be assigned conservatively. View Only seats may still consume a licensed seat depending on contract terms; confirm this with the Demandbase account team before provisioning read-only users at scale.

Bottom line

Demandbase requires fully manual user lifecycle management: every provisioning and deprovisioning action must be performed inside the platform UI regardless of IdP configuration.

The combination of no SCIM, no JIT, no bulk import, and annual fixed-seat contracts means that access hygiene depends entirely on admin discipline. Teams operating at scale should build explicit offboarding checklists that include a Demandbase deactivation step independent of any IdP workflow.