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.

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.

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.

Accounts with the stakeholder package provision users as STAKEHOLDER by default instead of RESPONDER, when no role attribute is present.

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.