Summary and recommendation
CreatorIQ 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.
CreatorIQ uses role-based access control for platform users, but specific role names, permission boundaries, and tier requirements are not publicly documented.
Admin console paths and user object types are undisclosed in accessible official sources.
Teams needing a clear permission matrix should expect to work directly with a CreatorIQ customer success representative to map their org structure.
Quick facts
| Admin console path | Settings / Administration > Users and Roles (exact labels vary by tenant) |
| 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 |
|---|---|---|---|---|---|
| Admin | Can manage tenant settings, integrations, and user access. | Cannot grant capabilities outside the modules or features enabled for the tenant. | Detailed built-in role names are not fully documented publicly. | ||
| Standard User | Can use the core product features exposed to their assigned role. | May not be able to manage tenant settings, integrations, or other users. | Exact privileges can vary by tenant configuration and contract scope. |
Permission model
- Model type: role-based
- Description: CreatorIQ is documented as using role-based access control for platform users, but specific role names, permission boundaries, and plan-tier requirements are not publicly documented in accessible official sources.
- Custom roles: Unknown
- Custom roles plan: Not documented
- Granularity: Expect administrative access to be separated from standard user access, with exact scopes configured per tenant.
How to add users
- Log in as an administrator.
- Open settings or administration and navigate to users.
- Choose the add or invite user action.
- Enter the user's work email and assign the appropriate role.
- Save the user and complete any activation or SSO steps required by the tenant.
Required fields: Work email address, Role
Watch out for:
- Public documentation for user administration is limited, so exact labels may vary by tenant.
- If SSO is enabled, upstream IdP assignment may still be required before the user can sign in.
| 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: Official documentation on delete vs. deactivate behavior is not publicly accessible; cannot confirm either capability without authenticated access to help articles.
- Open the users area as an administrator.
- Locate the user to offboard.
- Disable, revoke, or remove the account using the controls available in that tenant.
- Review any integrations, service accounts, or credentials associated with the departing user.
| Data impact | Behavior |
|---|---|
| Owned records | Tenant data remains in the workspace; public docs do not describe user-owned content semantics in detail. |
| Shared content | Shared content and workspace records typically remain available unless separately removed or reassigned. |
| Integrations | Review service credentials, workflow ownership, and integrations 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, integration, and service-account review, not just interactive login removal.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Named User | Access to the tenant features exposed to the assigned role. Seat entitlements are generally tied to the subscription contract. | Custom pricing; determined by contract and plan. |
- Where to check usage: Settings / Administration > Users and Roles
- How to identify unused seats: Review the tenant user list and any visible login or activity metadata. No public unused-seat report was verified.
- Billing notes: Pricing is custom and contract-based, reported in the range of approximately $30,000–$90,000+ per year depending on tier. Seat-level billing details are not publicly documented.
The cost of manual management
Pricing is fully custom and contract-based, reported in the range of approximately $30,000–$90,000+ per year depending on tier. Seat-level billing details are not publicly documented, making it difficult to audit unused licenses without direct account manager involvement.
For every app in your stack where seat-level visibility is opaque, offboarding delays compound - and CreatorIQ is a clear example of that pattern.
The decision
If your team needs self-serve user provisioning or a documented permission model, CreatorIQ does not currently offer either publicly. Every app that routes user management through vendor support introduces a manual coordination dependency that slows both onboarding and offboarding. Teams operating at scale should factor in the support-mediated workflow when assessing operational overhead.
Bottom line
CreatorIQ's user management is opaque by design - role structures, admin paths, and seat-level billing are all handled through direct vendor engagement rather than self-serve tooling.
For IT and ops teams managing access across every app in the organization, this means CreatorIQ will require a manual, support-dependent process for provisioning and deprovisioning until the vendor expands its administrative documentation or self-serve capabilities.
Automate CreatorIQ 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.
