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

# B2B via Organizations

> Sync external B2B customers into FGA using Auth0 Organizations, organization membership, and optionally tenant roles.

Use this when your customers are external companies, each represented by an [Auth0 Organization](https://auth0.com/docs/manage-users/organizations), and access in your product follows who's a member of which organization, with, optionally, different roles within it (admin vs. viewer, for example).

## Model

If organization membership is all you need, every member gets the same access with no finer distinction. You only need:

FGA model · DSL

If different members need different access, add roles. Which shape those roles take depends on where they come from:

* **Static roles**, defined once by your application as a fixed set of named permissions (like an "Approver" role): model each as its own named relation directly on `organization`, per [Roles: Static roles](https://docs.fga.dev/relationship-sync/use-cases/roles.md#static-roles).
* **Dynamic roles**, defined by each customer or organization themselves, with names, IDs, and permissions your application can't know ahead of time: model these generically, wired through an intermediate `organization_membership` object so a role assignment can be revoked without knowing which roles a user held, as covered in [Roles: a user, within an organization membership](https://docs.fga.dev/relationship-sync/use-cases/roles.md#a-user-within-an-organization-membership).

Some applications need only one category; others need both, in which case add both sets of relations to the model above, following [Roles: Combining both](https://docs.fga.dev/relationship-sync/use-cases/roles.md#combining-both).

## Mapping

Every setup needs these two rules for organization membership itself:

```yaml theme={null}
version: "1"

rules:
  - name: "Add user to organization"
    when: input.type == "organization.member.added"
    variables:
      organization_id: input.data.object.organization.id
      user_id: input.data.object.user.user_id
    tuples:
      - user: "user:{{ variables.user_id }}"
        relation: "member"
        object: "organization:{{ variables.organization_id }}"

  - name: "Remove user from organization"
    when: input.type == "organization.member.deleted"
    variables:
      organization_id: input.data.object.organization.id
      user_id: input.data.object.user.user_id
    tuples:
      - action: delete
        user: "user:{{ variables.user_id }}"
        relation: "member"
        object: "organization:{{ variables.organization_id }}"
```

If you need roles, add the role-assignment rules from whichever [Roles](https://docs.fga.dev/relationship-sync/use-cases/roles.md) subsection matches your case on top of these.

## Known limitations

Roles have no CRUD events at all, and there's no event for assigning a tenant role outside an organization context; see [Known limitations](https://docs.fga.dev/relationship-sync/overview.md#supported-auth0-events) for the full list that applies to this use-case.