Provisioning lets your organisation's identity provider, such as Okta or Microsoft Entra ID, manage who is in your 50heads teams. It adds people when they join your company, sets their role from their groups, and removes them when they leave. It uses SCIM 2.0, the standard most identity providers use for this.

Security policies are sign-in rules for everyone in your organisation's teams: two-step sign-in, how long people stay signed in, and how often they confirm it's them.

We're rolling both out to organisations gradually. If you don't see Provisioning (SCIM) or Security policies in Settings, then Organisation, they aren't on for your organisation yet. Contact us if you'd like them.

Before you start

  • Your organisation needs at least one verified domain. We only add people whose email address is on a verified domain. See Your organisation and its domains.
  • You need to be an owner or admin of one of the organisation's teams, signed in on the website.
  • Every change needs a fresh check that it's you. Choose Confirm it's you when asked. The check lasts 10 minutes.

Make a token

In Provisioning (SCIM), choose Make a token and give it a label, such as Okta. You see two things to give your identity provider:

What Value
SCIM base URL https://api.50heads.com/scim/v2
Token Starts scim_. Shown once.

Copy the token straight away. We keep only a fingerprint of it, so nobody can show it to you again. If you lose it, make a new one.

  • Up to 5 tokens can work at once. The list shows each token's first characters and when it was last used.
  • Replace gives you a new token. The old one keeps working for the time you choose, 1 day unless you change it and up to 7 days, so you can update your identity provider without a gap.
  • Revoke stops a token at once.

A token can only ever read and change your own organisation's people and groups.

Set up Okta

  1. In the Admin Console, go to Applications, then Browse App Catalog, and add SCIM 2.0 Test App (OAuth Bearer Token). Or turn on SCIM provisioning in your own app integration.
  2. Under Provisioning, then Integration, enter the SCIM base URL, choose userName as the unique identifier, and choose HTTP Header authentication with the token.
  3. Turn on Push New Users, Push Profile Updates and Push Groups, then choose Test Connector Configuration.
  4. Under To App, turn on Create Users, Update User Attributes and Deactivate Users.
  5. Assign the people and groups who should use 50heads.

The default attribute mappings are right:

50heads Okta
userName user.email
name.givenName user.firstName
name.familyName user.lastName
emails (work) user.email
active Set by Okta when you assign or unassign someone

Set up Microsoft Entra ID

  1. In the Entra admin centre, go to Enterprise applications, then New application, then Create your own application (non-gallery).
  2. Under Provisioning, choose Automatic. Enter the SCIM base URL as the Tenant URL and the token as the Secret token, then choose Test connection.
  3. Check the user mappings below. Turn on group provisioning with displayName and members.
  4. Under Settings, choose Sync only assigned users and groups, then assign the people and groups.
  5. Set Provisioning Status to On. Entra runs about every 40 minutes. Provision on demand runs one person straight away.
50heads Entra ID
userName userPrincipalName, or mail if your sign-in names aren't email addresses on a verified domain
name.givenName givenName
name.familyName surname
emails (work) mail
active The default Switch([IsSoftDeleted], …)
externalId objectId or mailNickname

Other attributes, such as job title or phone number, can stay mapped. We accept them and don't keep them.

Give roles by group

Push the groups whose members should have a role. Then, under Roles by group, choose a group, a team and a role: admin, member, billing or viewer. Your identity provider never makes anyone an owner.

  • Someone in several groups gets the highest role in each team: admin, then member, then billing, then viewer.
  • Someone in no mapped group gets the role for people in no mapped group in your default team. It's member unless you change it.
  • Taking someone out of a group takes the role away at once. Renaming a group keeps its roles.
  • Provisioning only changes memberships it made. Someone an admin added by hand keeps the role the admin gave them.

When someone is added

  • If they already have a 50heads account with that email address, we link it. We never merge accounts. They keep their own credits, questions and keys, and join your teams.
  • Otherwise we make an account for them. They sign in with an email code, or with your company sign-in if you use single sign-on.

When someone is turned off or removed

When your identity provider turns someone off or deletes them, all their access to your organisation ends on their next request:

  • every session ends, on the web and in the app, and they're signed out;
  • API keys and connected apps they made in your teams stop working;
  • webhooks they set up for your teams stop;
  • they leave your teams.

Their questions and results stay with the team. The team's credits stay where they are, and asks already running finish as usual. Keys they made in their own personal account are theirs and keep working. Every step is in the activity log, and in the audit log where it's on for your organisation.

If your identity provider turns them back on, they rejoin your teams. Keys, connected apps and sessions that ended stay ended.

Owners and break-glass owners

  • Someone who owns one of your teams can't be turned off until another member owns it. Your identity provider gets an error naming the team. Open Settings, then Organisation, choose Hand over under the team, and pick the new owner. Only the team's owner, or the owner of your main team, can do this.
  • If you use single sign-on, a break-glass owner can't be turned off while they have break-glass access. An owner removes their break-glass access first, then your identity provider can turn them off.

How many requests your identity provider can send

Each token can send up to 1,200 requests a minute. Your organisation can send up to 2,400 a minute across all its tokens, so replacing a token never halves the limit. It's set to cover a first sync of a large directory.

If your identity provider goes over, we answer with HTTP status 429 and a Retry-After header that says how many seconds to wait. Nothing in that request is changed. Your identity provider should wait and send it again. If a request still fails, it shows as a provisioning error in your identity provider, and you can retry it there. The provisioning log shows these requests too.

The provisioning log

Provisioning log shows the last requests from your identity provider, newest first: the request, its status, what happened and when. We keep it for 90 days, without tokens or request contents. Use it to see why a person wasn't added.

Security policies

All policies are off until an admin turns them on. They apply to everyone in your organisation's teams, wherever they sign in. Someone in two organisations gets the stricter rule.

Policy What it does
Require two-step sign-in or a passkey People without either can still sign in, but can't do anything that needs them to confirm it's them, such as making a key, until they add one.
Maximum session age From 15 minutes to 90 days. People sign in again after this long, however active they are.
Idle timeout From 5 minutes to 30 days. People are signed out after this long without using 50heads.
Confirm-it's-you window From 1 to 10 minutes. How long a check that it's you lasts before a sensitive change. 10 minutes is the standard.

Policies apply to sessions that already exist. If you shorten the maximum session age or idle timeout, we show who it affects and ask before saving. Sessions older than the new limit end on their next request. Connected apps sign in again once they're older than the maximum session age.

What people in your teams see

  • With two-step sign-in required, people who don't have it see a notice on every page asking them to set up two-step sign-in or a passkey. The app asks too, after they sign in. Adding one is never blocked.
  • When a session ends because of a policy, or because an admin ended it, the website and the app sign them out and tell them, so they can sign in again.
  • Everyone can see your organisation's policies in Settings, then Organisation.

See everyone in your organisation

People lists everyone in your organisation's teams in one place. Open Settings, then Organisation and choose Open People. Only owners and admins of the organisation's teams can see it.

For each person, People shows:

  • their teams, their role in each, and whether your identity provider gave that role;
  • whether your identity provider added them, or has turned them off;
  • whether they use single sign-on;
  • when they last signed in, and on how many devices they're signed in now.

Someone your identity provider turned off stays in the list, in no team. Find someone by part of their name or email address. The list shows 50 people at a time.

End someone's sessions

In People, choose Sessions next to someone to see where they're signed in, on the web and in the app, and how they signed in. End all sessions signs them out everywhere: each session ends on its next request. Their keys keep working. Use it when a laptop or phone is lost. It's next to anyone who's signed in somewhere, and it needs a fresh check that it's you.