Summary and recommendation
Terminus 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.
Terminus is an account-based marketing (ABM) platform covering display ads, website personalization, and intent data.
It does not offer native SCIM provisioning, meaning every app lifecycle action adding users, updating roles, removing leavers
must be handled manually through the Terminus UI or coordinated with a customer success representative.
Contracts typically run multi-year at significant spend, so provisioning gaps carry real operational and audit risk.
Quick facts
| Admin console path | Public Terminus documentation does not expose a detailed internal user-admin path; administration appears to happen in the authenticated Terminus workspace and gated support workflows. |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Manages workspace configuration, users, and ABM program settings in the Terminus tenant. | Detailed public permission boundaries are not documented. | Not publicly documented | Custom contract | Public docs do not enumerate a full internal role matrix. |
| Standard user | Uses assigned advertising, engagement, and reporting features within the tenant. | Exact limits versus admin roles are not publicly documented. | Not publicly documented | Custom contract | Role names and boundaries should be verified in the live tenant. |
Permission model
- Model type: role-based (public details not documented)
- Description: Public Terminus documentation confirms SSO setup, but detailed internal role and permission documentation is gated or not publicly exposed.
- Custom roles: No
- Custom roles plan: Not publicly documented
- Granularity: Not publicly documented
How to add users
- Use the authenticated Terminus workspace to invite the user through the tenant-specific administration workflow.
- Assign the available role or workspace access level required for the user.
- If enterprise SSO is enabled, validate the identity flow in the live tenant because public docs do not expose a complete onboarding runbook.
Required fields: Work email, Tenant-specific role assignment
Watch out for:
- Public Terminus support content is gated, so exact invite steps should be verified in the tenant before automation.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | Unknown | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Public Terminus documentation does not describe whether internal users are deleted or deactivated when access is revoked.
- Use the tenant-specific user-management workflow inside the Terminus workspace to revoke access.
- If SSO is enabled, remove or disable the user in the IdP first so authentication state stays aligned.
- Confirm data-retention and attribution impact directly in the tenant because public docs do not describe those semantics.
| Data impact | Behavior |
|---|---|
| Owned records | Not documented |
| Shared content | Not documented |
| Integrations | Not documented |
| License freed | Not documented |
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Custom contract | ABM platform access and modules defined by enterprise contract. | Custom |
- Where to check usage: Not documented
- How to identify unused seats: Not documented
- Billing notes: Custom pricing; contracts typically $20K–$150K+/yr depending on modules (display ads, website personalization, intent data), account database size, and usage volume. Multi-year contracts are common.
The cost of manual management
Without automated provisioning, every app in your stack that lacks SCIM creates a recurring manual burden. In Terminus, adding a new team member may require contacting a Terminus CSM rather than completing a self-serve flow.
Deprovisioning is equally manual: removing a user from your IdP does not deactivate their Terminus account, so a separate UI action is always required. At contract values ranging from $20K to $150K+/yr, unmanaged seats represent meaningful wasted spend.
The decision
If your team manages Terminus access today, plan for manual provisioning and deprovisioning workflows until SCIM support is confirmed by Terminus directly. SSO via SAML (Okta, Entra, OneLogin) is available and reduces authentication risk, but it does not substitute for lifecycle management.
Pair SSO with a documented offboarding checklist that includes a manual Terminus UI step to fully close out departing users.
Bottom line
Terminus has no documented SCIM or public user-management API, making every app access event a manual operation. SSO via SAML provides authentication coverage but leaves provisioning and deprovisioning gaps that require explicit UI actions.
Given multi-year contract values and limited self-serve admin controls, teams should build explicit manual checkpoints into their joiner/mover/leaver processes until Terminus confirms any future automation support.
Automate Terminus 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.
