Suggested answer

An org can hold multiple SAML single sign-on configurations, so this is a configuration problem rather than an architecture problem. I create one configuration per identity provider and enable both — plus the standard login form if some population still needs it — on the My Domain authentication configuration.

For routing I use login discovery: the login page asks for an identifier, and a Login Discovery Handler Apex class decides what happens next based on it — redirect to identity provider A, redirect to identity provider B, prompt for a password, or send a one-time passcode. That gives one login URL for everyone, which matters because bookmarks and email links do not respect audience boundaries. The alternative is exposing both as buttons, which works but pushes the decision onto users who often do not know which company's directory they are in.

Two things I plan alongside it. First, the Federation ID namespace — if both directories issue employee numbers, they can collide, and the Federation ID must be unique across the org, so I would prefix or otherwise namespace them. Second, the merge path: this configuration should be explicitly temporary, with an agreed target of one identity provider, or it quietly becomes permanent and every future change has to be made twice.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.