Managing personal office communication with MS Flow

It’s 10:00 am of a Wednesday and I am in my childhood home, having a chat with my dad and spending some time relaxing. As it is raining today, beach is not an option, and cinema is scheduled for later today.

So what better to pass the time until later than write a light post? So, instead of focusing on AIS or some “enterprise like” technology, I decided to talk about something I made to make my life simpler, using Microsoft Flow, Teams and Outlook – my ultimate out of office communication.

The requirements

For a bit of background, at Theta we had a long time tradition to indicate people whereabouts on email using a tag like OUT (out in a client), WFH (working from home), etc. That came from the time where the team was quite small and email was the main method of communication. With the team growing, earlier this year we made a request for people to move that kind of notification to Teams, on Theta’s General channel. But then I thought – why do I have to connect to teams to do that every time? There should be a better way…

In the end, the better way for me was a Flow button that allowed me to decide exactly what I wanted to do – I designed the flow to do the following:

  • Choose the type of notification I wanted to send:
    • Out of Office (OUT)
    • Working from Home (WFH)
    • Sick Leave (SICK)
    • Late to Work (LATE)
  • Have an optional text explaining the reason for the notification
  • Send an email to my manager indicating my whereabouts.
    • Optionally, send a copy of the email I send to my manager to a list of people I chose.
  • Optionally, turn on automatic replies and adjust the text and the duration of the automatic replies.
Continue reading “Managing personal office communication with MS Flow”

Resetting the State of a Logic App Trigger

This week we’ve been preparing for a Go Live in a project that integrates Dynamics 365 Field Services with an on-premises system . Part of this process was to run a series of migration script to get data from the on-prem system into D365.

Since D365 pushes the information into logic apps, I thought that the safest way to run that migration would be to simply disable the logic apps that would triggered by the process and the event would be “lost”. But to my surprise logic apps triggers are more powerful than that and remember the last event being processed. So when I turned on my logic apps after the migration, I was “rewarded” with thousands of triggers being fired… 

To be honest this is quite powerful, because in cases where you had to take the logic app offline because of downstream system issues or updates, upstream systems can continue to work as expected. But how to avoid that in cases like mine – where bulk uploads (initial load or bulk updates) are not expected to flow downstream?

Continue reading “Resetting the State of a Logic App Trigger”