> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/users-and-access-management/single-sign-on/auto-provisioning-users-and-teams.md).

# Auto provisioning users & teams

Have SAML attributes create ilert users and teams on first login, with the right role, contact details and team membership already in place.

With **Provision new users on first sso login** enabled, ilert creates a user the first time someone authenticates successfully through your identity provider — no invitation, no manual setup.

By default that user arrives with the **Responder** role and nothing else filled in. Sending extra SAML attributes lets you set their role, their team, and their profile details at the same moment.

{% hint style="info" %}
Auto provisioning runs **only** when the user does not already exist. Sending new attributes for someone who has signed in before changes nothing; ilert does not re-apply them on later logins.
{% endhint %}

Every attribute below is optional, and Google (OAuth 2.0) supports none of them — this is a SAML feature.

## User attributes

| Attribute          | Values                                                                                  | Default                     |
| ------------------ | --------------------------------------------------------------------------------------- | --------------------------- |
| `firstName`        | String                                                                                  | Parsed from the email claim |
| `lastName`         | String                                                                                  | Parsed from the email claim |
| `position`         | String                                                                                  | Empty                       |
| `department`       | String                                                                                  | Empty                       |
| `role`             | `STAKEHOLDER`, `GUEST`, `VIEWER`, `RESPONDER`, `USER`, `ADMIN`                          | `RESPONDER`                 |
| `mobileRegionCode` | Region code, e.g. `DE`                                                                  | Empty                       |
| `mobileNumber`     | National number without the country code, e.g. `0221 123 123`. Needs `mobileRegionCode` | Empty                       |
| `userProfileImage` | Absolute URL to a 500×500 image                                                         | Empty                       |

`ACCOUNT_OWNER` cannot be assigned this way. A value ilert does not recognize falls back to `RESPONDER` rather than failing the login.

{% hint style="info" %}
Accounts with the stakeholder package provision users as `STAKEHOLDER` by default instead of `RESPONDER`, when no `role` attribute is present.
{% endhint %}

## Team attributes

| Attribute  | Values                                                | Default                                    |
| ---------- | ----------------------------------------------------- | ------------------------------------------ |
| `teamName` | String                                                | Empty — no team is assigned                |
| `teamRole` | `STAKEHOLDER`, `VIEWER`, `RESPONDER`, `USER`, `ADMIN` | Derived from `role` when `teamName` is set |

If no team of that name exists, ilert creates it on this user's first login. Either way the user is added to it.

## When the values do not agree

ilert never fails a login over a bad attribute. Invalid values, and combinations that are not allowed — `role = ADMIN` together with `teamRole = USER`, for instance — are resolved to the nearest valid state so the person still gets in. Check your identity provider's assertion if someone lands with a role you did not expect.

Provisioning does fail if the account has no free seat of the right kind. Stakeholder, Viewer and regular user seats are counted separately, so a full Viewer quota blocks a `VIEWER` provisioning even when regular seats remain.

## Preventing unwanted auto-provisioning

Restricting access at your identity provider — an app assignment, an LDAP group — is the primary control. ilert offers a second one on its own side, for cases where an assertion reaches ilert before the person is ready to be onboarded.

The **Check provisioning attribute** field on the **Single sign-on** tab is empty by default and never required. Fill it with the name of a SAML attribute — `role`, or anything else you choose — and ilert checks for that attribute immediately before provisioning:

* **Attribute present** — the user is provisioned and signed in. Its *value* is ignored; only presence is checked.
* **Attribute absent, and no ilert user exists yet** — the sign-in stops on an error page telling the person to contact an account admin.

Existing users are unaffected, so turning this on does not disturb anyone already signed up.

Use it when you want provisioning to be a deliberate act: nobody arrives in ilert until an admin has added the attribute to their profile at the identity provider, by which point their role and team are set correctly too.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ilert.com/users-and-access-management/single-sign-on/auto-provisioning-users-and-teams.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
