Summary and recommendation
MadKudu 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.
MadKudu does not support SCIM provisioning, and the available documentation does not surface a structured admin console path, defined user types, or a documented permission model.
This means every app lifecycle action - adding seats, adjusting roles, removing leavers - must be handled directly inside the MadKudu UI with no automation layer available through standard IdP connectors.
Because no deactivation-vs-deletion distinction is documented, offboarding carries real access risk: without a confirmed deactivation flow, teams cannot assume that removing a user from an IdP group will revoke MadKudu access.
Manual verification inside the product is required at every offboarding event.
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: MadKudu appears to use role-based access for tenant administration and general product use, but the detailed permission matrix is not publicly documented in full.
- 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: Public docs do not clearly document whether users are disabled, deleted, or both. Treat lifecycle behavior as tenant-specific unless confirmed in-product.
- 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: MadKudu is sold primarily through custom or enterprise contracts. Public seat pricing and detailed licensing terms are not broadly disclosed.
The cost of manual management
Every app in a portfolio that lacks SCIM or a user-management API creates a recurring coordination cost - and MadKudu sits firmly in that category. Provisioning and deprovisioning must be triggered manually, which means access reviews, onboarding checklists, and offboarding runbooks all require a human step that cannot be delegated to directory sync.
License visibility is similarly limited: no documented path exists for checking seat usage or identifying unused licenses programmatically. Teams relying on MadKudu at the Growth ($999/mo) or Enterprise ($2,499/mo) tier should account for this overhead when estimating total administration cost.
The decision
MadKudu is appropriate for teams that can absorb fully manual provisioning workflows and do not require IdP-driven lifecycle automation. It is a poor fit for organizations with strict joiner-mover-leaver SLAs or audit requirements that depend on automated deprovisioning evidence.
Before deploying at scale, confirm directly with MadKudu support whether enterprise SSO or any private provisioning capability exists - the public documentation does not resolve this question.
Bottom line
MadKudu has no SCIM support, no documented user-management API, and no surfaced admin console path, making it one of the more operationally opaque tools in a typical GTM stack.
Every app that forces fully manual provisioning adds compounding overhead to IT and RevOps teams, particularly at offboarding where unverified access removal creates compliance exposure.
Teams at the Growth or Enterprise pricing tier should weigh that administration burden explicitly, and should contact MadKudu directly to determine whether any private or enterprise-tier provisioning options exist beyond what public documentation describes.
Automate MadKudu 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.
