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.
Built into the Swiftward service you run.
Sign-in through your identity provider
Each tenant adds its own identity provider as a setting, and people sign in over standard OIDC. The discovery URL you enter is fetched with protection against server-side request forgery (SSRF).
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 control access to every object type. Attributes narrow access to the rows a person may see. At field level, a field you classify as sensitive carries its own permission, and every read of it is audited separately.
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.
Separation of duties is declared: the role that writes rules does not have to be the role that promotes them.
Roles are derived at sign-in
A group change in your provider reaches Swiftward at the person's next sign-in. A session already open keeps the roles it started with. For offboarding, disable the account at your provider: that stops the next sign-in.
Multi-tenancy
One deployment carries several tenants with separate data, separate rulesets and separate operators. That is what lets you embed Swiftward in your own product: each of your own customers is a tenant, and none of them sees another. See sell into the enterprise.