Content under development
You can use the Swimlane element to use different authentication strategies for some parts of the flow. For example, you can split the same process to take different lanes for different people, groups of people, or subprocesses.
Let’s say you want to create a flow where everyone with the URL of the app can access the first screen, but users need to authenticate themselves (with a service that supports authentication, like Salesforce, or Box) to proceed to the second and third steps.
Here’s how you can create a swimlane:
- Drag a Swimlane element from the sidebar to the canvas.
This opens a Configuration Panel on the right.
- Enter a name for the swimlane in the Name field. Example: APeJ Only.
- Select the service you want the users to authenticate themselves with from the drop-down Which Service will users authenticate with? menu. Example: Box. The menu shows a list of services that support authentication in your tenant.
- Select Any user that can login with the selected identity service can run this flow from the What type of user authentication should be used? drop-down menu.
- Select None from the Social feed for collaboration drop-down menu.
- Click Save Swimlane.
This is what the canvas looks like now:
- Drag a Step from the sidebar to the swimlane. The border of the swimlane element changes from orange to blue and then orange again.
This also opens the Configuration Panel for the Step element.
- Enter a Name for the Step in the Name field, enter the content for the Step in the Content Editor, and click Save Step.
This is what the canvas looks like now:
- Create an outcome Go from Step 1 to Step 2. This is what the canvas looks like now:
Let’s run the flow now and see what happens…
The first Step does not need users to log in before proceeding. You can see the Step has gotten rendered into a screen, and the Outcome is now the Go button.
The log in screen of the service (Box in this case) shows up when you click Go.
|Note: When you are using a swimlane element, the default behavior of the ManyWho runtime is that the user will not be excluded from the flow, and can continue to get status updates and collaborate. However, the user cannot view any pages or take any actions.
When you are building a flow, make sure you create the swimlane first, and then add the elements. If you configure a set of elements on the canvas first, and then drop a swimlane element on top of them – the authentication will not work and the flow will error; even though it looks correct on the canvas. For example, this is the same flow as above. Only, we created the Steps first, and then added the swimlane.
When you run the flow, and click Go, the flow does not proceed to Step 2 or show the authentication screen. This is the screen we get:
A swimlane will not work if it is the first element in the flow. If you intend to build an app for authenticated users only, select a service that supports authentication when you are creating a flow. For example, a flow like this will NOT work:
You can have a flow with multiple swimlanes. For example, the first swimlane can use Salesforce for authentication, the second swimlane could use a different authentication service.
|ManyWho Ninja The engine will provide you with the authorization context as part of the response. The authorization context can then be used against our authentication API to log the user in to the correct directory to get the required authentication token. The authorization context object will be returned for initialization, execution, and join requests on the engine. We do not return the authorization context for “response” requests, as part of an asynchronous execution.
If you need to take a closer look, click on the images to enlarge them. Have a question? Click the Help button on the bottom right-hand corner of this page to ask.
Check out the ManyWho glossary for a definition of terms and key concepts that appear in the ManyWho website, Drawing Tool, technical documentation, blogs, and marketing communications.