Single Sign On

Use this when your site redirects to an identity provider such as Okta, Microsoft Entra, or any SAML setup. This is the option that asks the most of you, for a reason worth understanding: it is the only one where a password gets typed into a page on a domain you do not own. The safeguards around that are what make the setup longer.

​

What you need before you start

• Permission to create a user in your identity provider.
• Permission to change sign on policies, or someone who can.

​

Step 1: Create a dedicated account

Create a normal user account for Superflow. Do not reuse a person’s account.

• Give it a name that makes its purpose obvious, such as Superflow Agent.
• Set the password yourself.
• Turn off any “user must change password at next sign in” option.

​

Step 2: Exempt it from multi-factor authentication

This is the part with no workaround. Multi-factor means a code from a phone or a tap on an app. An agent has neither. Most providers let you exempt a single service account, and doing so for one non-human account is the normal way automation is granted access. If your security team will not allow it, single sign on cannot work for you, and the honest answer is to look for a bypass token instead. Exempting means more than one setting. Providers typically separate:

1. How you sign in to an application. Set this to password only for the service account.
2. How you establish a session with the provider at all. Multi-factor not required.
3. Whether you must enrol an authenticator app. This one is easy to miss and fails in a confusing way. If enrolment is still required, the agent lands on a “set up security methods” screen. That is an enrolment prompt rather than a sign in challenge, so Superflow reports a sign in that did not complete rather than telling you multi-factor is the problem.

​

Step 3: Connect it in Superflow

​

What Test access does, and why it is required

For every other option, Test access just tells you whether the details work. For single sign on it does something more: it records which sign in page is the right one for your project. After that, unattended agent runs only ever type your password into that same page. If your site starts redirecting somewhere else, the run stops rather than handing your corporate password to whoever controls the redirect. This is why an agent run before any successful test will refuse with a message asking you to run Test access first. There is deliberately no path where an unattended run decides for itself that a sign in page is trustworthy.