You get a No flow available error

You make an authorization request, but that request is denied with the following error:

Considering the fact that an authorization request doesn’t have anything to say about a flow, how in the world could you be requesting a flow that doesn’t exist (or at least that isn’t available)?

As it turns out, the problem doesn’t lie with you; it lies with your application client. Each application client should include the default_flow_name and the default_flow_version settings; these settings identity the name and version number of the Identity Cloud flow used in the login and registration process:

📘

The flow helps determine such things as the screens that are shown to users during login and registration and the text that appears on those screens.

But suppose those settings are missing, or suppose they point to an invalid flow. For example, this application uses a flow named myFlow (possible) that has a version number of 5 (impossible):

Any authorization request made using this application client is doomed to fail: even if there is a flow named MyFlow, it’s version number can’t possibly be 5 (version numbers are timestamps, not single-digit numbers).

To correct this problem, update the client settings to point to the correct flow and the correct version number:

Two quick notes. First, flow names and flow versions can be found in the Registration Builder section of Console:

Second, instead of using a version number, you can set the version to HEAD. When you do that, the application client automatically uses the latest version of the flow. If you don’t set the version to HEAD then you’ll need to manually update the version number each time you make a change to the flow (assuming, of course, that you want to use the latest version of the flow).

That said, while using HEAD is acceptable in a testing or development environment, it’s not recommended in production environments. Why not? Well, suppose you make a change to a flow, and that change actually wreaks havoc with Hosted Login. The minute the change is made, however, any application client using HEAD begins using this new flow, and begins wreaking havoc with Hosted Login. If you stick to using version numbers, you’ll have plenty of time to test and verify your new flow version before using it with Hosted Login.