This solution automatically creates and populates a Word document using PowerApps and Power Automate with Flowr actions. It will then also create a PDF rendition. For demo purposes, we are using personas to present a real-life scenario. This solution was presented at the South Coast Summit in October 2023 by Sophie Charlwood and Ben Haynes. So if you’re looking to automate document creation with PowerApps and Power Automate, you’ve found the right blog!
The blog has been broken down into these smaller sections:
This scenario is a health and safety PowerApp which delivers an incident form completed should an injury occur. This is just an example scenario for the solution; many similar use cases can benefit from this type of solution. The persons involved are the injured ‘Builder’, the ‘Site Injury Advisor’ and the ‘Site Manager’:
After the ‘Builder’ has contacted the ‘Site Injury Advisor’ about their new incident, the ‘Site Injury Advisor’ needs to select the relevant form and complete the details considering the information provided by the ‘Builder’.
The ‘Builders’ doctor’s information has been previously saved in Dataverse. That means it is automatically surfaced in the form, but these details won’t be editable in this scenario.
When the complete button is pressed, a ‘Document Creation’ Power Automate flow is initiated. This creates a PDF rendition of the completed form by using our Populate Word Document and Convert Word actions. It then asks for approval from the ‘Builder’ to confirm the details recorded by the ‘Site Injury Advisor’ are correct.
When the ‘Site Manager’ accesses the app, they are presented with a gallery containing all the reported incidents.
The following logic has been applied to allow a ‘Site Manager’ to sign off an incident:
Incident Signed Off – Not Signed Off Icon – Visible Property
If(ThisItem.'Incident Signed?' = true,false,true)
Incident Signed Off – Not Signed Off Icon – Visible Property
If(ThisItem.'Incident Signed?' = true,true,false)
In the Dataverse Incidents table, there is a column called ‘Incident Signed?’ which defaults to ‘No’. When an incident is ‘Signed off’, a Power Automate flow updates this value to ‘Yes’. This switches the icon in the Power App’s ‘Incident Signed Off’ column.
Document Icon – Visible Property
If(IncidentNotSignedIcon.Visible = true,false,true)
The document icon is only visible when an incident has been ‘Signed off’, and the summary document has been created. That means it is visible when the not signed off icon in the Incident Signed Off column is not visible.
The modal pop-ups are managed with containers and altering the visible property to either show or hide the container and, therefore, the pop-up. There is one pop-up container with two containers inside, one for incident information and one for incident sign-off. Each container has different elements, changing what is shown.
Information Icon – OnSelect Property
Select(Parent); // selects the gallery item Set(VarOpenPopUp,true); // sets variable VarOpenPopUp to true which opens the pop up Set(VarIncInfo,true); // sets variable VarIncInfo to true which sets the incident information container to visible
Incident Signed Off – Not Signed Off Icon – OnSelect Property
Select(Parent); // selects the gallery item Set(VarOpenPopUp,true); // sets variable VarOpenPopUp to true which opens the pop up Set(VarSignOff,true); // sets variable VarSignOff to true which sets the sign off container to visible
Next, the variable IncidentSigned needs to be initialised. The reasoning for this will be explained further down the blog. The first action we have in the flow is an email approval to the builder, and the approval uses dynamic content from the Power Apps trigger.
The flow is compiled considering data provided by the ‘Builders’ response, using a condition that checks whether an approval was approved or rejected. If the details are approved by the ‘Builder’, an email is then sent to the ‘Site Manager’ alerting them and requesting a review. Further actions have been added to manage the incident ‘Sign off’ process, including an email which contains a link taking a ‘Site Manager’ straight to the Power App.
There are multiple ways this solution could have been created; for this example, we are only using one Power Automate; however, you could also separate the actions into two separate Power Automate flows. If you decide to split the solution up, the first Power Automate should be initiated in the same way ending with the step that sends an email to the Site Manager (the step above). The second Power Automate would be a cloud flow, triggered by the Dataverse ‘When a row is added, modified, or deleted’ action, which should be configured to evaluate the ‘Incident Signed?’ column, only executing when the column value is changed to ‘Yes’.
To manage this in one flow, you can create a Do Until loop, which checks the IncidentSigned variable declared at the beginning of the flow to see if it is equal to ‘Yes’. The Do Until loop can’t cycle continuously, so a delay needs to be added. For example, you configure the flow check once or twice a day. Post ‘sign-off’ and use the Dataverse action ‘Get Row by ID’ to look up the Incidents table. The Row ID is the GUID provided to the Power Automate flow from the Power App by using the last submit formula to get the GUID of the incident form submitted via the app:
Lastly, the Incident Signed variable needs to be set by the current Dataverse value in the ‘Incident Signed?’ column, which will either be ‘Yes’ or ‘No’ because the column is a choice. An expression is needed to retrieve the text value:
The Do Until loop will then be re-entered; however, if the incident has been ‘Signed off’, the condition has now been met, and therefore, the flow will break out of the loop.
When using a Do Until loop, the timeout settings need to be adjusted. The Timeout setting is a parameter that limits the maximum amount of time the loop will wait for its condition to be met. The loop stops with a timeout error if the condition isn’t met within the set time. The setting can easily be changed by changing the limits within the action.
Once the incident has been approved, the document can be created. The Word document template needs to be saved in an accessible location for Power Automate to obtain the file (the file content). For this example, the Word template has been stored within OneDrive. The flow also gets the ‘Builders’ doctor’s information from Dataverse rather than the Power App. This is achieved by using the ‘Get Items’ action and filtering for the specific injured builder.
Flowr’s Populate Word Document action uses JSON inputs. A JSON payload can be created from all the dynamic content available within the Power Automate flow. The JSON keys must match exactly the token names added to the word template so that the action knows where to place the data in the document. The action works with text, dates and images, meaning all the data we need to put in the template can be done with one action. Images in Dataverse are already stored in Base64 format. This means we need to add Base64 after the key name in the template tag.
This produces a new file where the tokens have been replaced with the dynamic data values provided. To finish the flow, the Word document is converted to PDF (using Flowr’s Convert Word action) and emailed back to the ‘Builder’ so that they can see the ‘Site Manager’ has identified mitigating actions to stop similar incidents occurring in future.
The final PDF document will look like this:
We hope you have found this blog about how to automate document creation with PowerApps and Power Automate useful! But we always welcome feedback, so please reach out via our chat or email us at firstname.lastname@example.org to chat!