Rights Granted and Revoked Once, Not Per Application

What you can do together

• Have a leaver's access to the library end at the same moment as the rest of their access, rather than on a separate checklist line.
• Drive a mover's rights from one event instead of application by application.
• Notify BetterCloud of events here over webhooks, so its policy view includes the library.
• Establish whether SCIM or BetterCloud handles provisioning, rather than running two paths at once.

How it connects

The direction is worth being precise about, because it is the opposite of what people assume. BetterCloud would act on the platform by calling its REST API, driving a joiner, mover or leaver change at the same moment it drives the rest of the estate. The platform's webhooks run the other way: they call out to a BetterCloud endpoint when something happens here, covering media actions, metadata changes, live sessions and workflow completion, with authentication configured per webhook.

What the REST API can do to an account is the first thing an engagement confirms, because that determines whether this is a full lifecycle integration or a narrower one. Where the organization's identity provider supports SCIM, that is the standard provisioning path and usually the better answer for joiners and leavers, with BetterCloud covering the policy and licence enforcement around it. An engagement would establish which system does which rather than building a second provisioning path beside an existing one.

BetterCloud stays the lifecycle and policy system. Its rules, its licence tracking and its estate view are unchanged.