You’re offline. This is a read only version of the page.
Hello!
I have built the below flow to extend an Approvals workflow past 30 days - I have followed @RezaDorrani's tutorial here
However it doesn't seem to be running as expected.
On the 'Apply to each 5' action, it is running through 100 records at a time and seems to be sending approvals to managers for the incorrect user in the SharePoint list even though 'Get user profile' is selected near the top of the workflow.
It's also been noted that approvals went out for people where the ‘FormStatus Value’ was not equal to "Manager Approval Needed" or "Exec Approval Needed".
Really could do with some help on this one.
Full flow details below:
Trigger: When an item or a file is modified (SharePoint)
We start this workflow with the SharePoint ‘When an item or a file is modified’ trigger action.
We have two trigger conditions set for this.
The first trigger condition checks that the ‘FlowName Value’ in the Declarations list is set to “WF3” – this would’ve been set by the previous workflow if the user had answered ‘Yes’ to any of the specific questions when the update item action would have set the Colleague Date ‘FormStatus Value’ to “Exec Approval Needed” or “Manager Approval Needed”.
The second trigger condition checks that the ‘StartWF’ value is not equal to ‘No’ - later on this value will be set to ‘Yes’ – this will allow the approval workflow to restart after the Approvals action has timed out after 29 days of inactivity.
Action: Get items (SharePoint)
Here we are getting items from the ‘Colleague Data’ list.
Action: Get user profile (V2)
Next, we retrieve the user profile details from the EmailAddress field in the ‘Declarations’ list – this is the email address of the user who submitted their Declaration of Interest.
Action: Get Manager (V2)
Again using the EmailAddress field from the ‘Declarations’ list, we get the details of the users manager.
Action: Apply to each
Next, we use the body value from the ‘Colleague Data’ list (Get items) and insert this into the ‘Output’ field in this ‘Apply to each’ action.
Action: Get user profile.
Next, using the ‘ExecDirectorEmail’ value in the Colleague Data list we are able to retrieve the user profile of the Exec Director.
Action: Switch
Next, we use the ‘Switch action’ which is compromises of three cases – each of which are dependant on the selected ‘FormStatus Value’ from the ‘Colleague Data’ list – these would’ve been selected from the second flow which checks which questions had been answered from the form.
We will now go through each of the Switch cases and explain how each one works.
Case: Exec Approval Needed
Action: Update item
Next, we are using the ‘Update item’ action to update the ‘Declarations’ list items ‘StartWF’ value with “No”.
Action: Start and wait for an approval
Next, we use the ‘Start and wait for an approval’ action where we are using one response of ‘Approve’.
This action uses dynamic fields from the both the ‘Get user profile V2’ actions above where we are getting the user profile of the user who submitted their declaration and the Exec Director – this is to enable personalisation in the Approval email that is sent to the Exec Director.
In the settings for this action, we have set the ‘Timeout’ duration to “P29D” – this means that the Approvals action will time out after 29 days (this is a day before Microsoft’s default 30-day timeout).
Next, the workflow is split into a ‘Parallel branch’ – we will start on the left of this branch with ‘Condition 2’.
Action: Condition
Next, we are checking that the ‘Outcome’ value from the above ‘Start and wait for an approval’ action is equal to ‘Approve’.
On the ‘If yes’ branch we start with a new ‘Apply to each’ action where we are using the ‘Responses’ output from the above ‘Start and wait for an approval’ action.
Action: Update item <Declarations – Update Approval as Yes (1) >
Here, we are updating fields on the ‘Declarations’ list (assuming that the Approval status is equal to ‘Approved’).
The ‘Approved’ field is set to ‘Yes’.
The ‘Comments’ field is filled with the ‘Responses Comments’ value from the Approval email sent to the Exec Director.
The ‘StartWF’ field is auto-filled with the ‘No’ value.
Action: Update item (Set Colleague Data FormStatus value as Exec Approved (1)
Finally, we update the ‘FormStatus Value’ on the ‘Colleague Data’ list with “Exec Approved”.
Next, we move over to the right-side of the Approvals parallel branch.
Action: Update item (Timeout for Exec Director Approval)
Here we are setting the ‘StartWF’ field value to “Yes” and we have configured it to run after ‘Exec Director Approval’ “has timed out” – this will occur after 29 days of approval inactivity.
Finally, because we have set ‘StartWF’ to “Yes” this this allows the workflow to re-trigger from the top and start the whole process again due to our trigger condition being set to: @not(equals(triggerBody()?['StartWF'],'No')) as detailed at the beginning of this flow. This will keep on lopping through until the Exec Director has approved the declaration item.
Case: Manager Approval Needed
Action: Update item (Update item 2)
Next, we are using the ‘Update item’ action to update the ‘Declarations’ list items ‘StartWF’ value with “No”.
Action: Start and wait for an approval
Next, we use the ‘Start and wait for an approval’ action where we are using two responses – these are either ‘Approve’ or ‘Escalate to Exec Director’.
This action uses dynamic fields from the both the ‘Get user profile V2’ actions above where we are getting the user profile of the user who submitted their declaration and their manager – this is to enable personalisation in the Approval email that is sent to the user’s manager.
In the settings for this action, we have set the ‘Timeout’ duration to “P29D” – this means that the Approvals action will time out after 29 days (this is a day before Microsoft’s default 30-day timeout).
Next, the workflow is split into a ‘Parallel branch’ – we will start on the left of this branch with ‘Condition’.
Action: Update item (Update item 2)
Next, we are using the ‘Update item’ action to update the ‘Declarations’ list items ‘StartWF’ value with “No”.
Action: Start and wait for an approval
Next, we use the ‘Start and wait for an approval’ action where we are using two responses – these are either ‘Approve’ or ‘Escalate to Exec Director’.
This action uses dynamic fields from the both the ‘Get user profile V2’ actions above where we are getting the user profile of the user who submitted their declaration and their manager – this is to enable personalisation in the Approval email that is sent to the user’s manager.
In the settings for this action, we have set the ‘Timeout’ duration to “P29D” – this means that the Approvals action will time out after 29 days (this is a day before Microsoft’s default 30-day timeout).
Next, the workflow is split into a ‘Parallel branch’ – we will start on the left of this branch with ‘Condition’.
We now move to the ‘If no’ branch of ‘Manager approval’.
Here, we are updating fields on the ‘Colleague Data’ and ‘Declarations’ lists (assuming that the Approval status is equal to ‘Exec Escalation’).
Action: Update item 6
Next, we use an ‘Update item’ action to change the ‘FormStatus Value’ field on the ‘Colleague Data’ list to “Exec Escalation”.
Action: Update item 7
Next, we use another ‘Update item’ action to set the ‘StartWF’ field on the ‘Declarations’ list to “Yes”.
This will trigger the workflow to start again based on it’s trigger condition and now that the ‘FormStatus Value’ is set to “Exec Escalation” – the next iteration will move to the Switch case of “Exec Escalation”.
This existing / preceding workflow will timeout after 29 Days and no further actions are required.
Next, we move over to the right-side of the Approvals parallel branch.
Action: Update item (Timeout for Manager Approval)
Here we are setting the ‘StartWF’ field value to “Yes” and we have configured it to run after ‘Manager Approval “has timed out” – this will occur after 29 days of approval inactivity.
Finally, because we have set ‘StartWF’ to “Yes” this this allows the workflow to re-trigger from the top and start the whole process again due to our trigger condition being set to: @not(equals(triggerBody()?['StartWF'],'No')) as detailed at the beginning of this flow. This will keep on lopping through until the Exec Director has approved the declaration item.
Case: Exec Escalation
Action: Update item (Update item 3)
Next, we are using the ‘Update item’ action to update the ‘Declarations’ list items ‘StartWF’ value with “No”.
Action: Start and wait for an approval (Exec Escalation Approval)
Next, we use the ‘Start and wait for an approval’ action where we are using one response of ‘Approve’.
Next, we use the ‘Start and wait for an approval’ action where we are using one response of ‘Approve’.
This action uses dynamic fields from the both the ‘Get user profile V2’ actions above where we are getting the user profile of the user who submitted their declaration and the Exec Director – this is to enable personalisation in the Approval email that is sent to the Exec Director.
Next, the workflow is split into a ‘Parallel branch’ – we will start on the left of this branch with ‘Condition 3’.
Action: Condition
Next, we are checking that the ‘Outcome’ value from the above ‘Start and wait for an approval’ action is equal to ‘Approve’.
On the ‘If yes’ branch we start with a new ‘Apply to each’ action where we are using the ‘Responses’ output from the above ‘Start and wait for an approval’ action.
Action: Update item <Declarations – Update Approved as Yes (3) >
Here, we are updating fields on the ‘Declarations’ list (assuming that the Approval status is equal to ‘Approved’).
The ‘Approved’ field is set to ‘Yes’.
The ‘Comments’ field is filled with the ‘Responses Comments’ value from the Approval email sent to the Exec Director.
The ‘StartWF’ field is auto filled with the ‘No’ value.
Action: Update item <Set Colleague Data FormStatus value as Exec Approved (2)>
Finally, we update the ‘FormStatus Value’ on the ‘Colleague Data’ list with “Exec Approved”.
Next, we move over to the right-side of the Approvals parallel branch.
Action: Update item (Timeout for Exec Director Escalation)
Here we are setting the ‘StartWF’ field value to “Yes” and we have configured it to run after ‘Exec Director Escalation’ “has timed out” – this will occur after 29 days of approval inactivity.
Finally, because we have set ‘StartWF’ to “Yes” this this allows the workflow to re-trigger from the top and start the whole process again due to our trigger condition being set to: @not(equals(triggerBody()?['StartWF'],'No')) as detailed at the beginning of this flow. This will keep on lopping through until the Exec Director has approved the declaration item.
#1
Michael E. Gernaey
566
Super User 2025 Season 1
#2
David_MA
516
Super User 2025 Season 1
#3
stampcoin
492
Share
Report
All responses (
Answers (