Carta User Management Guide

• Model type: role-based
• Description: Carta uses a predefined role-based access model. Admins assign users to fixed roles (Full Admin, Limited Admin, Legal Viewer, etc.) that carry preset permission bundles. There is no documented ability to create fully custom roles with granular permission toggles. Stakeholder-level access is scoped strictly to the individual's own holdings.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role-level granularity only; permissions are bundled per role. Admins cannot mix-and-match individual permissions outside of the predefined role set.

1. Log in to Carta and navigate to your Company Dashboard.
2. Go to Settings → Users & Permissions (or 'Team' depending on account version).
3. Click 'Invite User' or 'Add User'.
4. Enter the user's email address.
5. Select the appropriate role (Full Admin, Limited Admin, Legal Viewer, etc.).
6. Click 'Send Invitation'. The user receives an email to accept and set up their account.
7. For stakeholders (shareholders/option holders), they are typically added automatically when a security is issued to them via the cap table workflow, and Carta sends them a separate invitation to claim their holdings.

Required fields: Email address, Role selection

Watch out for:

• Stakeholders are added to the stakeholder count (and thus affect plan tier) as soon as a security is issued to them, regardless of whether they accept the invitation.
• If a user already has a Carta account under a different company, they will be prompted to link accounts; this can cause confusion.
• Invitations expire; if a user does not accept within the expiry window, the admin must resend.
• SSO-enforced accounts (Scale plan and above) may require users to authenticate via the configured IdP before they can accept an invitation.

• Can delete users: No
• Delete/deactivate behavior: Carta does not permanently delete user accounts or stakeholder records because equity records must be maintained for legal and audit purposes. Admins can revoke access (deactivate) an admin or team user, which removes their login access. Stakeholder records persist as long as they hold securities; access can be restricted but the record cannot be deleted while securities are outstanding.

1. Navigate to Company Dashboard → Settings → Users & Permissions.
2. Locate the user in the user list.
3. Click the options menu (three dots or 'Edit') next to the user.
4. Select 'Remove Access' or 'Deactivate User'.
5. Confirm the action. The user's login access is immediately revoked.
6. For stakeholders with outstanding securities, their portfolio access is suspended but their record remains on the cap table.

Watch out for:

• Deactivating a stakeholder does not remove them from the stakeholder count if they still hold securities; the plan tier is unaffected.
• If the deactivated user was the sole Full Admin, the account may become unmanageable; Carta recommends always maintaining at least two Full Admins.
• Carta support may need to be contacted to handle edge cases such as deceased stakeholders or disputed equity records.
• SSO-provisioned users deactivated in the IdP (Okta/Entra) will lose SSO access but their Carta record persists until manually deactivated in Carta as well, unless SCIM deprovisioning is configured.

• Where to check usage: Company Dashboard → Settings → Users & Permissions (for admin users); Company Dashboard → Cap Table → Stakeholders (for stakeholder count)
• How to identify unused seats: Carta does not provide a native 'last login' report for stakeholders in the standard UI. Admins can review the stakeholder list and filter by invitation status (pending vs. accepted) to identify stakeholders who have never logged in. Contacting Carta support may be required for detailed usage analytics.
• Billing notes: Pricing is based on total number of security holders (stakeholders), not on the number of admin users. Upgrading to a higher tier is required when stakeholder count exceeds the current plan's limit. Multi-year discounts of 8–15% are available for 3-year commitments. SSO is only available on the Scale plan and above. 409A valuations are included from the Starter plan onward.

Because Carta has no SCIM deprovisioning, an IdP deactivation alone does not revoke Carta access for users with a direct login - both systems must be updated independently whenever someone leaves. Stakeholders who have never logged in still count against the plan's stakeholder limit, which can silently push a company into a higher pricing tier.

There is no native last-login report in the standard UI, so identifying inactive accounts requires either manual review of invitation status or a support request to Carta.

Practitioners consistently flag three friction points. First, SSO is gated to the Scale plan ($67,200+/year), which many mid-stage companies consider a baseline security feature that should be available earlier.

Second, the absence of granular role creation forces admins to grant broader permissions than intended when predefined roles do not map cleanly to internal job functions - Full Admin access exposes all stakeholder compensation and ownership data.

Third, the stakeholder-count billing model catches teams off guard: every security holder counts toward the plan limit the moment a security is issued, regardless of whether that person ever logs in.

Common complaints:

• Enterprise and Scale pricing is not transparently listed; users report needing to contact sales for exact quotes above the Growth tier.
• Scale plan required for SSO, which many mid-stage companies consider a basic security feature that should be available at lower tiers.
• Stakeholders who have never logged in still count against the plan's stakeholder limit, which can unexpectedly push companies into a higher pricing tier.
• No native 'last login' or usage reporting for stakeholders makes it difficult to audit inactive accounts without contacting support.
• SCIM deprovisioning requires Scale/Enterprise plan; lower-tier customers must manually deactivate users in both the IdP and Carta separately.
• Lack of granular, custom role creation means admins must grant broader permissions than needed when predefined roles do not fit the use case.
• Users report that the deactivation workflow for stakeholders with outstanding securities is unclear and requires support intervention in some cases.

Every app that lacks automated provisioning creates the same operational drag, and Carta is no exception - admins must add and remove users by hand in Carta and separately in their IdP for every joiner and leaver.

The role model is sufficient for most cap table workflows, but teams that need tight access controls, automated onboarding/offboarding, or SSO without a large spend commitment will hit real limits.

Before committing to a plan tier, audit your current and projected stakeholder count carefully - the jump from Growth to Scale pricing is significant, and inactive stakeholders do not reduce your count.

Bottom line

Carta delivers strong cap table and equity management functionality, but its access control model is deliberately constrained: roles are fixed, SCIM is absent, and SSO requires the Scale plan.

A departed employee's Carta access survives IdP deactivation unless an admin also removes them directly in the Carta UI, making clean offboarding a fully manual two-step process.

Teams with straightforward equity workflows and a small, stable stakeholder base will find the overhead manageable; teams scaling headcount quickly or operating under strict access-control requirements should factor in the cost of fully manual user lifecycle management.