Rob Horton is a Senior Consultant and the Sustainment Practice Lead at ThreeWill. His experience includes over 20 years leading software architecture, design and development focusing on support tools, automation and e-commerce for large corporations and his own small businesses.
A little over a year ago, Microsoft released Flow for general availability. My experience with Flow has gone something along these lines (and speaking with other ThreeWill consultants, this story doesn’t seem unique):
I thought, “this is cool” and immediately created a Flow from the “Save Office 365 email attachments to OneDrive for Business” template. I can automatically save attachments from email to my OneDrive. It was totally cool, but not extraordinarily useful. I went back to doing real work. Several months later, after seeing update after update regarding additional Flow connectors being added, I had real-world business automation opportunity that could leverage Flow. After uttering a soft “Leeroy Jenkins” to myself, I dove in and began creating my first complex, production Flow. Frustration immediately followed. Below are three lessons I wished I’d known before getting started.
Lesson #1: Changing a Flow’s trigger is very difficult
It is very difficult to change your Flow’s trigger once you add anything to your process. My process was triggered when I received an email. I probably had 30+ Actions, Conditions and Connectors added when I realized 1) waiting 5 minutes between Flow email scans during testing was tedious and 2) there was a new requirement for the Flow to be triggered when a SharePoint file was modified. I could not easily replace the original email trigger in my Flow, nor could I copy my existing work to a new Flow with a file modified trigger.
Recommendations: Choose your trigger wisely. Consider how your Flow could possibly be used or leveraged and trigger it from the lowest common denominator. For example, create one Flow that is triggered when an email is received that saves a file from email to a SharePoint document library and have a second Flow that processes the file when a file is created or modified in a SharePoint document library.
Lesson #2: Flow Actions (Conditions, Switch Cases, etc.) are difficult to rename once they’re being used
Like lesson #1, Flow Actions (and other steps in your process) are hard to rename once you’ve used them in subsequent processing. In my haste, I created multiple Compose Actions and soon realized they were named “Compose”, “Compose 2”, “Compose 3” and so on. When I later went to use the Outputs of these Actions, it was confusing as to which one contained the value I was looking for. Changing the names after they have been used or referenced requires removing them from subsequent steps, renaming them and then adding the references back in.
Recommendations: Rename your Actions (and other steps in your process) immediately after adding them. Additionally, know that Flow stores spaces in names as underscores. If you named a Compose Action “My Total Time”, you would need to reference it as “outputs(‘My_Total_Time’)”. It’s confusing because it will display in your Flow with spaces. Consequently, if you use a name that has underscores in it, it will also be displayed with spaces.
Lesson #3: The Edit Flow interface can be flaky
There have been many times while working on a Flow when no Dynamic content is automatically listed, or not all Dynamic content that should be available is listed. Additionally, I’ve experienced Dynamic content not being referenced correctly while editing a Flow that previously worked. Also, if you change the characteristics of a Connector’s destination (like changing the columns on a SharePoint list your adding items to), your Connector may not behave as expected.
Recommendations: Exiting the Edit Flow interface and going back in can help. Additionally, removing Connectors (and other steps in your process) that aren’t behaving as expected and re-adding them can help. Finally, have patience.