Skip to main content
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.
If your site also sits behind Cloudflare Access or Vercel, a bypass token takes two minutes and works even with single sign on behind it. Check for one first.

​
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.
  • The site’s address already added to your Superflow project, under Settings → Manage domains. Site Access takes the address from there and never asks you to type it, so with no domain set its buttons stay greyed out.

​
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.
If “must change password at next sign in” is left on, the agent is sent to a change password screen it cannot complete, and the run reports a sign in that did not finish. Nothing in that message points at this setting, so it is worth getting right first time.

​
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.

Okta, step by step

The verified walkthrough for Okta, with a video. Other providers use different names for the same three things.

​
Step 3: Connect it in Superflow

1

Open your project's Site Access settings

2

Turn on This project is password protected

3

Under How the site is protected, choose Single sign on (Okta, SAML)

4

Enter the service account's username and password, and press Save password

You should see “Saved. Agents will use these credentials on the next run.” The password box empties after saving. That is normal: the password is stored, and is never shown again.
5

Type the password into the box again

Test access stays greyed out until you do.
6

Press Test access once, and give it up to a minute

A real browser is signing in. You should see “Unlocked. Agents can read this site.”
Save first, then test. If you press Test access before the first save, the first agent run stops and asks you to run Test access again. If that has already happened, press Test access once more now that the credential is saved.
Press Test access once, then wait. It is limited to five tries a minute, and repeated failed sign ins can lock the service account in your identity provider. If a test fails, fix the cause it names before trying again.

​
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.
If your provider is on your own domain (for example login.yourcompany.com rather than yourcompany.okta.com), Test access will stop and ask you to confirm it: “This site sent us to login.yourcompany.com. Confirm this is your sign in page and we will use it from now on.” Nothing has been typed at that point, so it is safe to be shown the address. The button now reads Confirm and sign in, and pressing it once is what establishes trust. This is normal and expected for companies using their own single sign on address.