> ## Documentation Index
> Fetch the complete documentation index at: https://docs.introw.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Access & Security

> Control who can see and do what on both sides of the partnership: internal team roles, partner team roles, and single sign-on for everyone.

export const Headless = ({children, intro = true}) => {
  const [copied, setCopied] = useState(null);
  const copy = event => {
    const row = event.target.closest("li");
    if (!row) return;
    const text = row.textContent.trim();
    try {
      navigator.clipboard?.writeText(text);
    } catch {}
    setCopied(text);
    setTimeout(() => setCopied(null), 1600);
  };
  return <>
      {intro ? <p>
          Introw is <strong>headless</strong> by design: run everything here in plain language from Claude, ChatGPT,
          Slack, Teams, or your own CRM through Introw's <a href="/features/developer/mcp">MCP server</a>, with every
          action written straight back to your CRM source of truth. The portal is one surface, never the only one.
        </p> : null}

      {children ? <div className="not-prose" data-prompts="block">
          <div data-prompts="head">
            <span>{copied ? "Copied" : "Try it from your LLM"}</span>
          </div>
          <div data-prompts="rows" onClick={copy}>
            {children}
          </div>
          <a href="/headless/prompts" data-prompts="more">
            See all prompts
          </a>
        </div> : <Card title="See the headless motion" icon="wand-magic-sparkles" href="/headless">
          The agentic motion - lifecycle deep dives and a Claude Code skill library that run your partner program from
          Claude, ChatGPT, Slack, and your CRM.
        </Card>}
    </>;
};

export const Rail = ({children}) => <div className="not-prose" data-overview="rail">
    {children}
  </div>;

export const Impact = ({children}) => <div className="not-prose" data-overview="impact">
    {children}
  </div>;

export const Personas = ({children}) => <div className="not-prose" data-overview="personas">
    {children}
  </div>;

export const Pains = ({children}) => <div className="not-prose" data-overview="pains">
    {children}
  </div>;

> Every partner program runs on trust, and trust starts with access. Decide exactly what your internal team can do, what each partner's people can do, and how everyone signs in, all configured by your team without engineering.

## The problem it solves

<Pains>
  | Without Introw | With Introw |
  | - | - |
  | Everyone has more access than they need | Roles grant only what is needed |
  | Partners need access, not CRM seats | Scoped portal users, never seats |
  | Adding a person is an IT ticket | SSO and SCIM do it for you |
  | Nobody knows who owns which partner | Partner team roles, CRM-synced |
</Pains>

## Impact

Partners notice a program that lets them run their own side of it. Adding their own colleagues and signing in with their own identity is a small thing that decides whether they use the portal at all.

<Impact>
  for your business

  * **Cost to run**
    Roles, partner team roles and SSO are configured by your own team, with no engineering and no ticket to add a person
  * **In your CRM**
    Partner and visitor access is scoped to the CRM data each partner owns, and no external user ever needs a CRM seat
  * **Trustworthy**
    Sign-in follows your identity provider and your existing policy, and the same scope governs Introw's AI agents

  for your partners

  * **Self-serve**
    A trusted partner manager adds their own teammates instead of emailing you about every new person
  * **Enabled**
    Their people sign in with their own identity provider, so nobody is blocked on another password
  * **Efficient**
    They see the accounts and records that are theirs, with no request to widen or narrow access

  [A day in the life of a distributor](/days-in-the-life/distributor)
</Impact>

<Personas>
  * **CRM Administrator** - identity and access policy in one place
  * **Partner Operations** - roles and ownership without a ticket
  * **Partner alliance managers** - adding their own colleagues
</Personas>

## How this area works

Access and security covers three capabilities. Provisioning is how people get in: partners, their
owners, and their contacts sync live from your CRM, and your own team is created, given a role, and
deactivated through single sign-on and SCIM. Team management is where you invite your internal team,
assign roles built from clear permission categories, and limit users to the partners they own. It is
also where you define partner team roles and assign the people who manage each partner. Single sign-on
lets your own team and your partners log in through your identity provider, so access follows your
existing security policies.

**Where this sits in a setup.** Access is foundation work: every [setup track](/tracks) does it before anything a partner sees, because a portal nobody can get into is not a program.

<Rail>
  * ![The Users tab of Team settings, where users provisioned through SSO appear with the role they were granted.](https://assets.introw.io/docs/features/access/provisioning/shots/users.png)

    [**Provisioning**](./provisioning)

    Partners, owners and contacts, live from your CRM.

    [How to · 1 guide](./provisioning/technical)

  * ![The Users tab of Team settings, listing each internal user with the role they hold, beside the Roles and Partner team roles tabs.](https://assets.introw.io/docs/features/access/team-management/shots/users.png)

    [**Team Management**](./team-management)

    Roles from permission categories, and who owns whom.

    [How to · 4 guides](./team-management/technical)

  * ![The Portal SSO configuration, with the service provider details, identity provider fields and attribute mapping that let partners sign in with their own identity provider.](https://assets.introw.io/docs/features/access/sso/shots/portal-sso.png)

    [**Single Sign-On**](./sso)

    SAML or OIDC, for your team and for the portal.

    [How to · 2 guides](./sso/technical)
</Rail>

All three are configured by partner operations and admins directly, with no code, and the permissions
you set apply consistently across every surface a user touches.

<Note>
  These permissions also scope Introw's AI agents. When an assistant connects over [MCP](/features/developer/mcp), its data access follows the signed-in user's partner scope - a partner's assistant reaches only that partner's data. What an agent may do on its own is governed by a vendor-configured [capability matrix](/headless#governance-and-trust), with sensitive actions kept behind human approval.
</Note>

## Introw's own access to your organisation

Security reviews ask this one, so it is worth stating plainly. Introw support can, by default, sign in as one of your users to reproduce a problem, and use internal CRM tooling against your connected CRM to diagnose a sync. Both are audited.

Either can be switched off for your organisation. Ask your Introw contact and we set it on our side, per organisation:

* **Impersonation off** means no Introw employee can sign in as one of your users or your partners' users, for any reason.
* **CRM tools off** means Introw's internal CRM tooling cannot be pointed at your connected CRM. It can also be narrowed to a named list of Introw staff instead of switched off entirely, so a nominated support contact keeps working while nobody else can.

Turning them off is a real trade-off, not a free win. With impersonation off, "can you see what my partner sees" becomes a screenshare rather than something support can check alone. Expect slower diagnosis on portal-specific issues. Regulated programs usually take that trade; most do not need to.

## Run it from your AI assistant

<Headless>
  * Reassign Acme's partner manager to another team member.
  * Who owns each of our partners?
</Headless>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.