Hello everyone! In this blog, we will demonstrate how to schedule a flow that sends emails to all the owners of opportunities using Power Automate Flow. Scheduled flows are the best option for actions that need to be automated on a schedule and will run at a specific time or date. For instance, using this approach, you might schedule a daily data upload to Dynamics 365 or SharePoint. Use Case: Power Automate flow sends a reminder notification to the owners of Opportunities. To avoid multiple emails being sent to the same owner, we need to remove duplicate email addresses. Step 1: Log in to the required Power Apps environment using URL make.powerapps.com by providing username and password, click on Create on the left-hand side as shown below, and click on Scheduled cloud Flow. Step 2: Mention the date and time. It will appear as this. Step 3:  Initialize a variable ‘Email_addresses’ of type Array which will store all the email addresses. Step 4: Use List Rows to find the desired records from the required table. Select the table name. Also, I added the FetchXML code to fetch the required details of an entity. Step 5: Add an ‘Apply to Each’ loop and insert the previous step’s value. This is done so that the value in every iteration is stored in the Array Variable. Add a step of ‘Set variable’ to store the email addresses in the Array. Step 6:  Add a new step ‘Compose’ and declare an empty array. This helps to save time when comparing with larger sets. Step 7: Apply the Union function which removes duplicate values. union(variables(‘Email_addresses’),outputs(‘Empty_Array’)) Step 8: Apply the Join function to extract the email addresses. join(array(outputs(‘Union_function_to_remove_duplicate_mail_Values_in_Array’)),’,’) Hope this helps!

Hello everyone, You may have encountered a scenario in which Cloud Flow failed unexpectedly or failure from Server or certain conditions were not met during execution due to an asynchronous process. As a result, the Flow must be re-submitted, which is accomplished by selecting the Run History and clicking on Re-submit. In this blog, I’ll show you how to use configuration settings to automatically re-submit Failed flows. I’ll use the Parent-Child Flow concept to accomplish this. I made a simple Parent-Child Flow in which the Parent calls the Child Flow, the Child Flow sends Approval to the User, and the response is passed back to the Parent, indicating that the request was successfully completed.If the user rejects the request, it will be resent only when certain conditions for the execution are met. The steps for implementation and a guide to achieving this are outlined below. Step 1: For having Parent-Child Flows, you need to create a Solution and have 2 Flows (Parent – with any Trigger, Child – should be Manual Trigger) Step 2: Below is the Child Flow (I have used PowerApps V2 Manual Trigger) Tip: PowerApps Trigger can be seen and added later into the solution but if Manual Trigger (Blue Icon) is used then it may not show in existing Flows and cannot be used as Parent-Child is not in any solution A simple Flow, where I have sent an Approval to myself where if I have Approved it would send a response back to Parent Flow but if I reject the Approval then it will execute as Failed without passing a response to Parent Flow. Note: I have used Scope block, so if you have many Action controls and anything fails then it won’t send a response to Parent unless you have configured the flow as such. Here, the Red outlined Block, is the deciding block and the Blue block is the responding Block that will execute only if User Approves the Approval Request. Step 3: Configure the ‘Run-Only’ user for Child Flow on the main page. ‘Run-Only’ defines on who’s behalf to run the flow in the context of, since Child Flows are independent. Step 4: Below is the Parent Flow and the configuration for re-sending Child Flow in case of failure As you see, I have called the Child Flow once and displayed the output of the Child Flow. Because I’m only invoking the Child Flow once, I need to change the configuration for dealing with failed responses so that it can retry the submission of a failed response. On the Child Flow action, click the ellipse (3 dots) and then settings. For the specific action, a settings page will appear. Now we see the ‘Retry Policy,’ which determines whether the flow should retry in the event of a failure with certain conditions. In this case, I used a fixed interval; see the screenshot below. Step 5: That’s all. Now I have tested initially by rejecting the 1st request and the Retry Policy triggers and sends the 2nd request and I approve it. Thus completing the entire flow. Here’s the count of retries that occurred when you see the Run History of Parent Flow with deeper insights Hope this helped 👍🏻

At times, if there are some operations which your Flow wants to perform while it waits to get back, it’s best to use Parallel Branching in Flows. Here’s a quick tip on it! Scenario Some Flows need you to include Approvals or Adaptive Cards that halt the execution of the Flow until the Response from the target is sent back to the Flow. If there are some steps to be taken after the Response is received. Parallel Branching You can use Parallel Branching Select Parallel Branching instead of a normal Step. Now, all the Response dependent Actions should be in one of the Branches – (Denoted by Red Box and arrow). And the other part where the execution is expected to be carried forward should be in the other branch – (Denoted by Green Box and arrow) The execution will then wait where the parallel branches merge finally. Else, each branch can choose to end independently if there are no inter-dependent actions to be take, like taking Response from the Parallel Branch as well. The Waiting state will look like this – Now, when the Response is submitted back, the Flow execution will continue from the point of convergence of the two parallelly separated branches. With this, you can separate dependent activities by using Parallel Branching.