Share and Enjoy !

Background

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 Microsoft 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.

Did you run into the same gotchas?  Any new ones you would add?  Leave a comment below…

Share and Enjoy !

Related Content: