Tearing Down Azure Resources and Replying to Emails Using Power Automate Flows and Azure Runbooks

Microsoft Power Automate Flows, UI Flows, & Automation Runbooks: Part Seven of a series


In this last post of the blog series, I will cover how I used Power Automate flows and Azure runbooks to tear down my Azure resources and reply, with proof, to the original flow requester that execution was successful.


There are two parallel branches that complete the flow. These actions include deleting all of the resources used by the UI flow in the test environment and responding to the original flow requester by email. All of the resources used for testing were deleted so that I did not incur any additional Azure charges for the test environment. The easiest way to do this was to delete the entire resource group. To do this, I used the Az PowerShell command Remove-AzResourceGroup. Once authenticated, Remove-AzResourceGroup only requires only the Resource Group parameter in order to execute. The runbook, with service principal authentication, looks like this:


[Parameter (Mandatory= $true)]

#Service Principal Authentication
Connect-AzAccount -CertificateThumbprint $Thumbprint -
ApplicationId $ApplicationId -Tenant $TenantId -ServicePrincipal

#Remove Resource Group
Remove-AzResourceGroup -ResourceGroupName $ResourceGroup -Force


The screenshot below shows the flow action with variable Vendor as a prefix to -ResourceGroup, which is the only required parameter in the runbook shown above.


Microsoft Power Automate Flows_Part7_image 1


As this action is taking place, a parallel branch is also running. The parallel branch sends an email reply to the original flow requestor of the email notifying them that the flow has completed successfully.


Microsoft Power Automate Flows_Part7_image 2


In the email reply, I wanted to add evidence that the user workflow tested was successful. I could have just added the paths to the Azure blob, but I decided to attach the screenshot zip file from the Azure storage container to the email. To accomplish this, first I needed to initialize a variable which was the container location of the WinAutomation screenshots.


Microsoft Power Automate Flows_Part7_image 3


The value of the blob is the path to the container and blob. The initialize variable action is necessary because at the time of the flow creation, the winautomation.zip file, which is the storage blob, does not exist. The file is not created until after the UI flow action is run. With the variable configured, I used the Get blob content action under the Azure Blob Storage service connector.


Microsoft Power Automate Flows_Part7_image 4


The blob value in the Get blob content action is the blob variable that is defined under initialize variable. The blob variable represents /winautomation-logs/WinAutomation.zip.


Microsoft Power Automate Flows_Part7_image 5


Now that the blob content is established in the flow, I was able to use the Reply to email (v3) action from Office 365 Outlook to respond to the sender of the original email trigger and add the blob content as an attachment.


Microsoft Power Automate Flows_Part7_image 6


The only required value in this action is message id. The required message id is the dynamic value of the message id found in the “When a new email arrives (V3)” original flow trigger seen in the image below.


Microsoft Power Automate Flows_Part7_image 7


The body is not a required value, but I wanted to add some text with the Vendor variable selected for parts of the body that may change, based on the vendor software being upgraded or patched.


Microsoft Power Automate Flows_Part7_image 8


With the message id and body of the email defined, the last step was to attach the blob content as an attachment to the email. First, I needed to define what the attachment name was. I used the (vendor variable) _Flow_Screenshots.zip as the name attachment. Note: it is important to define the extension. The attachments content is the dynamic value of File Content from the Get blob content action or it will not be attached correctly.


Microsoft Power Automate Flows_Part7_image 9


Below is an example reply that the original email requestor receives:


Microsoft Power Automate Flows_Part7_image 10


Parallel Actions


Microsoft Power Automate Flows_Part7_image 11


Final Flow


Microsoft Power Automate Flows_Part7_image 12


The final flow steps:


  1. Email is received as the trigger.
  2. Email body is searched for separate regex matches for Owner, Vendor and IP using the Plumsail connection.
  3. In parallel, the Flow checker workaround VM is turned OFF.
  4. Separate variables are initialized for Owner, Vendor and IP.
  5. Each matching regex pattern is set as separate variables for Owner, Vendor and IP.
  6. Azure Resources are created, and the Resource Group is tagged with the Owner name.
    • Resource Group
    • Virtual Machine (from an existing snapshot)
    • Network
    • Subnet
    • NIC
    • Network Security Group and Rules
    • Public IP Address
  7. The VM public IP is replaced with a specific IP from a different resource group that is allowed to access Salesforce.
  8. The WinAutomation Database (with any new processes) is copied to the VM from an Azure Blob
  9. A delay of four minutes takes place to allow the VM’s On-premises Data Gateway to register as Online with Power Automate.
  10. The custom WinAutomation UI Flow (RPA) for Salesforce case creation runs. Screenshots are captured to the VM desktop.
  11. Screenshots are zipped as Screenshots.zip and uploaded to an Azure storage container.
  12. The blob variable (container and blob) for the Screenshots.zip file is initialized.
  13. The blob content of the Screenshots.zip file is retrieved.
  14. Parallel Branches
    1. The test resource group and all resources are deleted from Azure.
    2. An email is sent to the original flow requestor notifying them that there were no errors during the flow, with the Screenshots.zip file attached to the email.


Note: There are several conditional statements that provided errors by email if the overall flow or UI flow failed.


This flow proves out the use case that through Flows, UI Flows, and Automation Runbooks, Microsoft provides the platform to create and test user workflows in order to gain efficiency and confidence in the patch and software update process.


Additional Information and Links:
Initialize a Variable: https://www.youtube.com/watch?v=fBS3wyWZo6Q
Az PowerShell: https://docs.microsoft.com/en-us/powershell/azure/new-azureps-module-az?view=azps-4.6.1
Stop Azure V2 VMs: https://gallery.technet.microsoft.com/scriptcenter/Stop-Azure-ARM-VMs-1ba96d5b
Graphical Runbooks: https://docs.microsoft.com/en-us/azure/automation/automation-graphical-authoring-intro
Remove-AzResourceGroup: https://docs.microsoft.com/en-us/powershell/module/az.resources/remove-azresourcegroup?view=azps-4.6.1
Azure Blob Storage: https://us.flow.microsoft.com/en-us/connectors/shared_azureblob/azure-blob-storage/


Here's a review of related posts on this series:

Dan Kiraly
Senior Research Scientist | Optiv
Dan Kiraly is senior research scientist on Optiv’s R&D team. In this role he's responsible for use case development and the vetting of security products for Optiv.