RotorLab logo RotorLabDocs

Directory provisioning (SCIM)

Directory provisioning lets your organization's directory manage your members here. When you add a person to the directory, they become a member of your organization. When you rename them, move them between groups or deactivate them, RotorLab follows. It speaks SCIM 2.0, the standard Microsoft Entra ID and Okta use, so any directory that provisions through SCIM can use it. Reach for it when you already manage people in a directory and want leavers to lose access without anyone remembering to do it in two places.

Only an organization admin sees the Directory provisioning (SCIM) card. It is under Settings, then Sign-in and security, after the Single sign-on card. It is available on every plan.

Before you start#

  • Confirm your email domain. The directory adds people only under the domain your organization confirmed, on the Your email domain card above. Until it is confirmed, the card says so and Make a directory token is off. See Your email domain.
  • Set up the group to role map if you want groups to set roles. The map is on the Single sign-on card, in Group to role, and directory groups use the same one. See Single sign-on.
  • Check your member seats. The directory adds people inside your plan's limit, as an invitation does. A person past the limit is refused with the reason.

Make a token#

  1. Open Settings, then Sign-in and security, and find Directory provisioning (SCIM).
  2. Press Make a directory token. Name it after the directory that will use it, for example Microsoft Entra ID, and enter your password to confirm.
  3. Copy the token now. It starts with rlscim_ and is shown once; RotorLab keeps only a fingerprint of it and cannot show it again.

The card also shows the Base URL, which ends in /scim/v2, and lists each token with its name, the start of the token, when it was made and when it was last used. An organization holds two tokens at most, so you can make the new one before you revoke the old one. Revoke ends a token at once; the directory then gets a refusal on its next call.

A directory token works only for directory provisioning, and only for your organization. A sign-in cookie or a personal API key does not work there, and a directory token does not work anywhere else.

Connect Microsoft Entra ID#

  1. In Entra ID, open Enterprise applications, choose New application, then Create your own application, and make a non-gallery application.
  2. Open its Provisioning page and set the mode to Automatic.
  3. Under Admin credentials, enter the card's Base URL as the Tenant URL and the token as the Secret token. Press Test connection.
  4. Under Mappings, keep Provision Microsoft Entra ID users and Provision Microsoft Entra ID groups on. Map the user's sign-in name to userName. The directory sends the person's name as displayName, or as given and family name.
  5. Assign the people and groups that should reach RotorLab, then turn provisioning on.

Connect Okta#

  1. In Okta, add an application that supports SCIM 2.0 and turn on Provisioning.
  2. Enter the card's Base URL and choose userName as the Unique identifier field for users.
  3. Choose HTTP Header authentication and enter the token. RotorLab expects the header Authorization: Bearer followed by the token. If your Okta app asks for the whole header value, enter it that way.
  4. Turn on Create Users, Update User Attributes and Deactivate Users.
  5. To use groups for roles, push the groups you mapped with Push Groups.

What the directory can do here#

  • Add a member. A new address under your confirmed domain becomes a member, receives the usual email saying they were added, and holds a seat. An address that already signs in to RotorLab for another organization is sent an invitation instead and joins when they accept; the directory reads them as active in the meantime. A person already in your organization whose directory record has not been linked is linked, not duplicated.
  • Keep names current. The name in the directory replaces the name here. A name over 120 characters, or with a line break, is refused. RotorLab keeps the given and family name the directory sends and reads them back as sent. A PUT replaces the whole name, so a part it leaves out is cleared; a PATCH that sets only the display name or the formatted name clears the given and family name unless the same request sets them; a PATCH that removes a part clears it.
  • Deactivate a member. Their sessions and sign-in links end at once, their personal API keys for your organization are revoked, and the records they made stay under their name. The member shows as disabled under People, then Members. Deleting the person in the directory does the same and also forgets the link, so a later add of the same address links the same member again.
  • Reactivate a member. Turning the person back on in the directory enables the membership again, inside your plan's limit. The sessions and keys that ended do not come back; the person signs in fresh.
  • Set roles from groups. After any change to a group or its members, each member takes the role of the first mapping in Group to role that matches one of their groups, by the group's display name or its external id. Group names need not be unique: two groups with the same name both match, and the first mapping that matches wins. A member of no mapped group drops to Member if their role was one the map gives, and keeps a role you gave by hand.

What it never does#

  • It never makes anyone an organization admin, and it never changes an organization admin's tier or role. Admins are made and changed only here, by another admin.
  • It never deactivates your last active organization admin. The directory is refused for that one request, and the person stays active.
  • It does not change a member's email address. The address is the one the member signs in with, and a sign-in can span several organizations, so a directory renaming it here is refused. Change an address yourself, from People, then Members.
  • It does not set passwords. Members use the sign-in your organization already has, or single sign-on.
  • It does not create RotorLab groups. Directory groups are used only to set roles. They do not appear under People, then Groups.
  • It does not reach other organizations. A member who belongs to several organizations keeps their other access when your directory deactivates them here.
  • It does not delete records. Flights, maintenance and everything else a deactivated member made stay.

If your organization is suspended, the directory can still deactivate and delete members, but it cannot add or reactivate anyone.

What you see in RotorLab#

Every change the directory makes is a row in the activity log under the actor directory with the token's name: member added, invited, linked, updated, deactivated, reactivated or deleted, group created, changed or deleted, and role assigned. Making and revoking a token are rows too. The card's status line says how many members and groups come from your directory and when it last called.

When something is refused#

  • The directory says unauthorized. The token was copied wrongly, was revoked or has expired, or is a sign-in or personal API key. Make a new token.
  • The directory says too many requests. After 20 failed attempts in a minute from one address, or past 600 requests a minute on one token, RotorLab asks the directory to wait a minute. Most directories retry on their own. A working token is never held back by another app's failed attempts from the same address.
  • An address is refused as not valid. The user name or work email holds more than one address, or a comma, space or similar character. Send one plain address.
  • A change is refused as an unknown attribute. The directory sent an attribute name that is not part of the SCIM user schema, often a typo in a custom mapping. Standard attributes RotorLab does not keep, such as job title or phone numbers, are accepted and ignored.
  • A person is refused as outside your domain. The address is not under the confirmed domain. Confirm the right domain, or invite the person from People, then Members.
  • A person is refused for the plan's limit. Free a seat or raise the plan, then let the directory retry.
  • The directory reports a duplicate. The directory record is already linked to a member here, another member already holds the same externalId, or the address is a minimized member's. Every person's externalId must be unique in your organization. Change the record in the directory rather than adding it again.

What the endpoint supports#

For whoever sets up or troubleshoots the directory's connection:

  • Ids. RotorLab gives each user and group an id of 32 hexadecimal characters. Keep the directory's own id in externalId.
  • Filters. A list request reads filters of the form attribute eq "value", joined by and. Users filter on userName, externalId, id and emails.value; userName matches whatever its case. Groups filter on displayName, externalId, id and members.value (or members). Any other operator, such as co or sw, is refused with a message naming the forms read here.
  • Paging. startIndex starts at 1; a value of 0 or less is read as 1. Sorting is not supported, and a sortBy parameter is ignored.
  • Paths. A trailing slash on any address works. Searching by POST to .search answers that the method is not allowed, and /Bulk is not offered: send one request per change.
  • Updates. PATCH and PUT work on users and groups. A PATCH whose path names no attribute RotorLab knows is refused as an invalid path.