Who runs the control layer, and how they sign in.
Your operators are the people who write rules and work review queues. Who may make a call at request time is a different question, on authentication and authorization.
A service you deploy.
Sign-in through your identity provider
Your provider is an object in the system that you configure, and the standard OIDC authorization and callback flow runs against it. Discovery goes out through a network client hardened against server-side request forgery, because the discovery URL is an address the customer supplies.
Groups on your side map to roles on ours, so you manage membership where you already manage it. The first sign-in creates the account, so a new employee needs no ticket here. MFA and password policy stay with your provider.
Access runs in three layers
Roles on every object type. Attributes narrowing access to the rows a person may see. Then field level: a field you classify as sensitive carries its own permission, and reading it is audited on its own.
An operator can act as another user only by giving a reason and a duration. The session expires on its own, and every action inside it is audited under both identities: the person acting and the account acted as.
Duties are separated the way you declare them. The role that writes rules does not have to be the role that promotes them, and a field marked sensitive can be readable by one role and invisible to another.
Roles are derived at sign-in
Move someone between groups in your provider and the change reaches Swiftward at their next sign-in, not at the moment you make it. Plan offboarding around that. Disabling the account at your provider stops the next sign-in, and that is the control that matters. A session already open carries the roles it was issued with.
Multi-tenancy
One deployment carries several tenants with separate data, separate rulesets and separate operators. That is what makes embedding work: each of your own customers is a tenant, and none of them sees another. See sell into the enterprise.