Flow Orchestrator – UnofficialSF

Currently there are two ways you can launch a flow orchestration: using a record trigger, or auto launch from Apex, But what if I want to be able to launch an orchestration from a button and mimic the good old “Submit for Approval” button?
I looked at alternative ways to start orchestrations, and this is what I found:
1. Launching an orchestration from a URL button was not user friendly as the user was presented with a blank auto launched flow screen and was not redirected back to the record when finished even if the the return URL was part of the button definition. Overall, while this may work, the user experience was not smooth
2. Trying to include the submit flow as an interactive step assigned to the current user, resulted in a warning when saving the flow and an error during execution saying that no assigned user was found

I ended up with the following solution that worked well and gave a smooth user experience:

1. An action button to launch the submit flow on the record page
2. A submit screen flow that will update a field on the record to indicate the record was submitted and who the approver is
3. An orchestration that will listen to the field updated by the submit flow and will run the approval flow, routing to the approver that was updated on the record by the submit flow
4. The approval flow will update the record again with the final approval status

Here is an illustration of the overall process:

Both the submit and approve flows are very simple and only have one screen followed by an update records step

Launch the submit flow from an action button added to the page layout

The flow orchestration only has one stage and one step

It starts when the record’s approval status is updated to submitted

And routes the approval to the username that was updated on the record by the submit flow

Here is a short video demonstrating the complete process

Some notes about the flows:

1. The submit flow clears any previous approval status and rejection notes
2. The approval flow only displays rejection notes if the user selects to reject, using a visibility rule
3. In both flows, I’m using a record input variable and this saves having a get records element in the flow as the whole record gets passed in from the button or from the orchestration step

Possible enhancements:

1. The approval request flow can include a message with approval details to the approval request flow by using a display text with merge fields from the record and related records information
2. The submit flow can select the approver automatically by using criteria from the record or an approval matrix stored in custom metadata
3. The submit flow can also be used to recall or not allow to submit an approval by displaying another screen based on the approval status

Launching an orchestration from a button opens up a lot of possibilities, please share if you come up with other use cases.

I was eager to test the new flow orchestrator and found a use case to try. When a user submits a case to be provisioned as a partner user, we need to process two manager approvals and then provision the contact and the user under the partner account. I built an orchestration to complete the approvals and then provision the user

I used the tutorials provided here by Alex to build this. The overall design uses three flows that share data using input and output variables.

My starting conditions were based on case creation

The manager approval is routed to the approving manager lookup field from the case

The supervisor approval is routed to a specified username

My approval flow is very simple and includes just one screen. It outputs the approval, and some user data from the case, that will be consumed by the provisioning flow. I used some interesting formulas to parse the supplied Web Name from the case to a first name and a last name, and since only variables can be designated for output, I’m assigning my formulas as the default value of the output variable

Here is how the approval request screen looks to the approving manager

Next, I created an autolaunched flow that evaluates both approvals and outputs the special “isOrchestrationConditionMet” boolean value that tells the next step to start. This flow also updated the final approval status on the case record.

Then my provisioning flow will start and show as a work item to the case owner

Here is how the provisioning screen looks to the user. The first name, last name, email, and account name, are populated from the approval flow and case record data.

In this screen I’m using the Quick Lookup flow screen component to dynamically filter the user role list based on the selected partner account

And after the provisioning is complete, the flow shows the success scree

I used some special formulas to set the alias, email, nickname, and username for the new user.
To avoid a mixed DML error, I used the Commit Transaction action between creating the contact and creating the user.

When the orchestration completed, I was able to view all the completed stages, and steps in the flow orchestration instance history

Overall, building this orchestration was fun and easy. I can see how powerful this tool can be for handling complex processes. I would like to be able send an approval request to non Salesforce users, that can approve by replying to the email, or by going to the work item component publicly exposed on a community page.
I’m looking forward to seeing how this tool will evolve and to all the enhancements that will be made.

Posts

From Tamar Erlich – Submit an orchestration from a button

Flow Orchestration Use Case – approve user provisioning