Sequence first. "Nobody can sign in after the SSO change." Check in this order. One. Can you still reach the administrator sign-in route? Two. Does the username the provider asserts match what the domain expects? Three. Was the configuration tested before activation? Four. Is the identity provider itself reachable? Five. Are the affected users assigned to the application at the provider end? Six. Is a sign-on policy involved?
Question one first, always — because the answer determines whether you are fixing a problem or opening a support case.
Then eight cases.
One. "We activated an untested configuration and locked ourselves out." The failure this module exists to prevent. Recoverable through support. Slowly. And visibly.
Two. "Username mismatch." Attribute mapping. The most common single cause.
Three. "Web works, Excel does not." Client testing skipped.
Four. "Automation failed silently overnight." Service account authentication after the change.
Five. "Sign-out does not sign out." Logout URL not configured.
Six. "Users were not told and support was overwhelmed." Communication, not configuration. Entirely predictable.
Seven. "The identity provider was down and nobody could work." No understanding of the administrator route as a contingency. Know it exists before you need it.
Eight. "Cross-account federation is unmaintainable." Module 3's cloud account decision, arriving late.
THE FIRST CASE IS THE ONE THAT ENDS CAREERS, AND IT IS PREVENTED BY TWO WORDS IN LESSON 4: TEST FIRST.