Build long-running Approval Flows

[Karan_MSFT]

Flows make it easy to automate workflows that request approvals and act on responses to them. Currently, flow runs time-out after 30 days, causing any pending steps (like approvals) to time-out as well. While this isn’t a problem for most approvals, there are cases where responding to an approval can take longer than 30 days.

Creating long running approval flows

With approvals stored in the Common Data Service, you can now create flows that act on responses to approval requests, even after the original flow run has timed-out. To do this, we will use two flows – one to send an approval request and the other to run business logic on the outcome of the approval once responses to it have been received.

Step 1:  Build a flow that sends an approval.

Begin by adding the ‘Create an Approval’ action in your first flow . This action, in addition to sending approval requests, also creates a record in the Approval entity of the Common Data Service. This record is what enables us to run business logic based on the outcome of the approval, even after the flow run ends.

In the screenshot below, the definition of our first flow contains just two steps - one to manually trigger the flow using a flow button, and the second to create an approval. Note that once the approval is created, the flow run ends.

Flow 1: Create an approval

Step 2:  Build a flow to run business logic on the outcome of an approval

In this step, we’ll build a Flow that runs when an approval record in the Common Data Service is updated, checks the Result field of the approval (which stores the Outcome of the approval request) and executes business logic accordingly.

Begin by creating a new Flow that starts with the ‘When a record is updated’ trigger of the Common Data Service connector and set the Entity Name field to ‘Approvals’. To make sure we only run this flow when the Result field of the approval updated, select the 'msdyn_flow_approval_result' in the dropdown for the Attribute Filters Item

Flow 2: Trigger the flow when the result field of an approval record is updated

Let's say that onve the flow is triggered (i.e., an approval has been responded to and has an outcome), we want to do the following:

1. Get the email address of the requestor
2. Send an email notifying them of the outcome.

To get the user that requested the approval, we use the ‘Get record’ action of the Common Data Service connector, set Entity Name field to ‘Users’ and the Item identifier field to the Owner field from the list of dynamics values of the ‘When a record is updated’ trigger

Flow 2: Get information about the requester

To send them an email that’s worded based on the outcome of the approval, we add a condition that checks if the value in the Result field is ‘Approve’ and then use the ‘Send an email’ action to craft messages for when a request is approved and rejected respectively

Flow 2: Send an email based on the approval outcome

Here's our complete flow definition that runs when an approval has been responded to, and sends an email to the requestor based on its outcome:

Flow 2: Flow to run business logic based on an approvals outcome

[Anonymous]

Hello @Karan_MSFT ,

From what I can tell by this Flow is that it checks the status of an approval.  It doesn't Restart the Approval Flow if it times out after 30 days.  How is the approval restarted?

Thank you in advance.

[Anonymous]

I don't see how this helps with approvals that run for more then 30 days.

[WonderLaura]

What license level is required in order to use the common data service? I was under the impression that either a Flow plan 1 or 2, or E5 licenses was needed, to use this connector.

[dhock]

I guess this could work for generic approvals where, no matter what flow they're generated in, the exact same actions are carried out in response to the outcome. But if you need to generate a second approval to users associated with a particular SharePoint site that the first flow is associated with, I don't see how you would do that, unless you can save more information in the approval entity, such as what flow generated it or what site is associated with it. Then, you could have a switch statement or something.

[Tanner]

So a Flow can now run for longer than 30 days, according to the headline here, but what do we do when it's been 29, 30, 31 days, etc. and we need to check on our Flow, except Oops! The Flow History has been deleted. Why? Because of GDPR, supposedly (read: not really--GDPR makes no such demands).

Has this problem been fixed yet? If not, then it's still useless to try and make Flows that run for longer than 28 days.

Also, why was this not mentioned in email updates until today when the blog post was made over a month ago?

[Karan_MSFT]

@Anonymous - you're right in that the 2nd flow is triggered whenever the approval record in CDS is updated to have an outcome (Approve, Reject, or some custom response).

Instead of restarting the Flow that created the approval, we recommend using a 2nd Flow to define what happens when the approval has an outcome. As this Flow is only triggered when there is an outcome to an approval, it is able to run its business logic, even if the approval was created over 30 days ago.

It's worth noting that this is possible because with the V2 approval connectors, approval data is stored in CDS for as long as you need it. This means that in addition to creating flows like these, you can leverage CDS to view your full approval history.

@Anonymous, @Tanner - Hope this also provides some clarity for your questions 

[Karan_MSFT]

@WonderLaura - The Common Data Service connector is premium, meaning that you will need at minimum a Flow Plan 1 license to use it

[Karan_MSFT]

@dhock - Great observation. While approval entities in CDS are currently not customizable, one could add an identifying tag to the approval title/description (either when defining the approval, or once it's created using the 'Get a Record' and 'Update a Record' CDS actions) to help determine the business logic that need to be run based on its outcome

[mseklec]

Am I correct in stating that user-entered comments in an approval response are not stored in CDS? These are essential to my approvals process, is there any way to access them using the CDS approval methods?

[Anonymous]

@Karan_MSFT This is fantastic, thanks for the walkthrough! 

Is there a way to identify from the CDS which approval workflow generated the triggering approval (in the 2nd flow in the example)? 

Our use case is that we have a number of approval workflows that have different actions on completion, so I'd have to differentiate between originating flows.

[samrutur]

@Karan_MSFT  - Thanks for the information and updates. We are unable to see the Create an Aproval (V2) action in Flow on couple of our tenants. The account has a PowerApps P2 trial that is active. What needs to happen for this to show up in our tenant?

Thanks.

[ChadVKealey]

@Karan_MSFT , is there a way to do this without the use of CDS? We have a couple of P2 licenses for testing and evaluation, but I need to build production Approval Flows (NOT using CDS) that may run for longer than 30 days.

[Jaystechtips]

I'd like to know too. I just found out that the approval process takes on average 3 to 6 months in my company. Is there any way to do these without using CDS? Its a premium feature and we have to pay more for this.

And on top of that I have to recreate the flow again. Knowing flow, i cannot just paste a subflow into my flow

Hope you have a solution for this without using CDS

[Anonymous]

Hello @Karan_MSFT 

When a record is updated flow get triggered every time a approval action happens in any of the approval workflows. 

1) Is there a attribute in approval entity to find out which flow triggered the approval

2) If I have several approval actions in the workflow how do I differentiate which approval action caused the trigger. I am currently using get items and then title to filter the record that caused the trigger.

[Himanjan]

Hi @Karan_MSFT 

I have a small query here with regards to the above illustration and I had validated this approach before some months.

as you stated "It's worth noting that this is possible because with the V2 approval connectors, approval data is stored in CDS for as long as you need it"

- My understanding is the 1st approval flow is triggred and sent the approval email to approver that flow will get timed out after 29 days so as the approval process and if the approver will try to action on that after 30 days it will not allow as the token might have expired and it can not establish the conenction with the 1st flow to bind the outcome.

- I understood the 2nd part the CDS workflow will be triggered based upon the 1st flow outcome. But what we are looking for is the 1st flow will not generate any outcome within 30 days.

- Here is the simple query

Is that create V2 approval action runs/ remains valid for the approval for more than 30 days/indefinite time OR in other way if the approver will try to action the approval email after 30 days will it work?

[kvdudley]

Can you please rewrite this post using Dataverse?

[donalmc]

Am I correct in my assumption that this will only really work for single user Approvals?

[Nao_]

Is it possible to have this post using dataverse ?

[kudorje]

Hello! Can you help confirm which part of the flow actually re-triggers the workflow? 

[kudorje]

Hello  @Karan_MSFT - In your comment above, you mention to build a second flow, do you mean having the same workflow twice? 

[bsene]

@kudorje in my understanding, you build a first flow to start the approval. The approval result and status are stored in the Dataverse table (CDS). This will be used in the second flow that is not bound to the 30-Day Timeout issue.

Regards