A brand asks you to switch its domain to federated-only sign-in, so how do you sequence that and who must keep a way in?

## What the flag actually is "Federated-only" is a per-tenant setting that says: for sign-ins arriving on this tenant's verified domains, the customer's identity provider is the only admissible authenticator. It is scoped to domains rather than to accounts, because the domain is what routing already resolves and what the customer verified. It is a property of the tenant, because in a group of hotel brands one brand will enforce a year before another and a global switch serves neither. ## Sequencing 1. **Connection live, routing off.** The record is validated and in a testing state; a handful of named pilot users reach the provider through an explicit link. Nobody else notices. 2. **Routing on, local sign-in still working.** The verified domain now resolves to the connection, so ordinary sign-ins go through the provider - but a person whose sign-in fails there can still use their existing credential. This is the step that earns the flip, and it needs to run long enough to cover the customer's real pattern: a full week, including the shift change, the weekend and whichever day their directory team makes changes. 3. **Measure.** Successful sign-ins by route, per day, per domain. A residual population still arriving locally is the list you must resolve before the flip, and it is never empty on the first look - it holds the contractors, the integration accounts and the two managers whose addresses sit under an old domain. 4. **Flip, reversibly.** The flag gates new sign-ins. Keep it revertible by a support engineer without a release, because the first flip sometimes finds a population the measurement missed. ## Who must keep a way in | Group | Why the provider cannot vouch for them | Route to keep | |---|---|---| | Contractors and agency staff | Their addresses are under their employer's domain, not a verified one | Invitation-bound accounts outside the enforced domains | | Integration and machine accounts | No human authenticates them at all | Their own credential type, never a person's password | | The tenant's own administrators | If the provider or the connection breaks, they are locked out of the controls that would fix it | A small named set, alarmed on every use, reviewed | That last row is the one to argue in the design review, and it is deliberately narrow: a named set, loud alerting on use, and the general doctrine for emergency access - how such credentials are stored, what approval their use requires - is somebody else's discipline and not re-invented here. The product constraint is simply that turning enforcement on must not be able to leave a customer with no way to reach their own settings. ## The lag nobody mentions until the audit The flag changes what happens at the next sign-in. It does not reach back: - A session issued ten minutes before the flip keeps working until it expires or is ended deliberately. - Any long-lived credential the account holds keeps working on the same terms. So if the customer's intent is "from now on, only our provider admits people", the flip alone does not deliver it - it has to be paired with ending the sessions those accounts already hold, which is the session-inventory work rather than this decision's mechanism. What belongs to *this* decision is owning the gap: telling the customer how long it lasts, and choosing whether to close it. ## The judgment underneath Every brand will ask for one more thing at this step: a different entry point, an extra attribute, an exception for one department, a bespoke error page. The question worth answering once, before the tenth brand asks, is **which divergences you absorb as configuration and which you decline**. A divergence that becomes a row in the connection record costs you a field and a test. A divergence that becomes a branch keyed on a customer's name costs you that branch forever, and the tenth brand will want its own. The honest answer is usually: absorb naming, endpoints, admission and entry point; decline anything that changes what a role means or the order in which your sign-in runs. The second judgment is what you promise. "Your staff can only get in through your provider" is a strong claim, and it is true only to the extent that the exception list stays short, the sessions gap is closed, and the accounts outside the enforced domains are reviewed. Sell the claim you can actually operate.