The PAD Flow
In part one, I explained the cloud flow to extract the PDF from an automatically generated email and save it to local storage. In the explanation though it showed the step containing the PAD flow; part two hopes to make some more sense of that. And in true kylbnkn style, you should have the PAD flow created to be able to reference it in the PA Flow… anyway…
Caveat: I have to stress that this particular use case scenario requires the flow to run unattended – essentially this is on a Windows server virtual machine that runs night or day, regardless of whether I am at my desk. You would be able to get this to work on a logged in machine on normal 365 licensing, however if you are planning to run it unattended you NEED unattended licensing. I am not a licensing man, I have not checked it for a while, but I know it’s a constantly moving beast – the most up-to-date PAD licensing information is available here.
I’m not going to detail how to set up the server or the PAD instance, perhaps that’s a post for another day. Anyway on with the show…
The Solution
This flow is split in the main flow and the error subflow – we’ll get on to that in a sec, but for now, the main flow.
In this, please note the Input / Output variables. At the end of part one I explained how you can use variables from both the cloud flow and PAD to leverage various functions – in this case, I have created the Input variable ‘FileName’ which basically translates to the the attachment name of ‘filename.pdf’ so PAD knows which file to work on, and similarly, I have created the Output variable ‘TeamsNotification’ which sends us confirmation of if the flow has or hasn’t worked.
For a home/small business user, this could ultimately be achieved with a few steps but as a I work for a larger organisation with potentially multiple people needing to work out what may have gone wrong, I have included various steps to capture events within the process.
In this, the log file collects when the flow has started, when the document has printed, it also records a short pause we’ve inserted (10 seconds, but could probably be less – I like it for piece of mind) which allows the system to stop using the file and then finally a step when we delete the file. I was in two minds whether or not to archive the files in to a ‘Complete’ folder, but ultimately we are retaining the file inside of our mailbox so seems a bit pointless – your mileage may vary.
This process is surrounded by the ‘On Block Error’ Flow Control option – we’ve called this variable AnyError with the following parameters:
This is a catch-all for any problem, but essentially takes us to the subflow ‘OnError’ should anything go wrong.
An important part of the subflow is the ‘Stop Flow’ action – inside I have set the parameter to End Flow: Successfully’ – the reason for this is if anything goes wrong, the flow will stop cleanly, so if the next job in the queue were to start, it should continue correctly.
You’ll notice that in the Main flow and OnError flow there is a Set Variable step assigned to the output variable TeamsNotification. Depending on which branch of the flow is running, ultimately depends on what the message is. The message is then referenced in the Power Automate cloud flow, where formatting is applied to the text on whether the outcome is positive or negative.
The extra steps of writing text to file gives us a log file we can reference cleanly – one mistake I have made here which I will correct in the future is that the file is stored in the C:\ drive of the local machine – realistically, it would have made more sense to store that in a shared network folder so we could pick it up easier, but in some respect logging is covered largely by our Teams messaging.
And that’s it.
In Summary
The cloud flow in part one has specifically extracted a PDF document from an email and via on-premise gateway, saved the file to local storage and triggered off the PAD flow. In part two, the PAD flow has sent the file to a network printer, deleted the file and written to a log file, whilst creating an ouput variable to be passed back to the cloud flow. The cloud flow has then sent us a logging message via Teams telling us whether the flow has or hasn’t worked. Finally, the cloud flow has moved the email to an archiving folder in the mailbox.
There’s a bit going on, but the realistic run time for this flow in its entirety currently clocks in at around 45 seconds, which for our use case works fine. If you are looking for something a bit more instantaneous in respect to unattended printing, I would recommend some dedicated printing software, however this could come with all sorts of costs and requirements. As our need isn’t quite as time sensitive, the flow serves its purpose well.
If this has been of any use to you, I’d love to hear from you in the comments.
