Today, I’ll talk about a simple flow that we use internally to automate productivity. I run a recurring meeting every day of the week – in this meeting we review the active service incidents and alerts. The attendes of the meeting change every week. Every week we assign a differing set of engineers (on-call) to monitor the service health and deal with incidents – and the currently assigned engineers are required to attend this meeting.

Previously I’d do this manually – at the start of the week – look up who the engineers are that are on-call and then update the meeting invite for the week – As you can imagine there were numerous gaps when I missed, and the meeting invitees were messy. Sometimes I even forgot to remove the previous engineers from the meeting invite.

Now, I have a flow that does this every Monday @ 11am as shown below, the first set of steps up to the Exctract Flow on Calls are not relevant, they extract the ids of the current engineers on call by calling a custom connector written on top of azure Functions.

To highlight the important pieces – I use the advanced recurrence settings to run the flow @ 11 am on Monday of every week, I use a ODATA filter query in the GetEvents action (Subject eq ‘Flows Daily Live Site Meeting’) to only return the meeting I’m interested in – this not only reduces the number of calendar events the flows has to process, it also works around some limitations of the GetEvents action – it only returns a max of 250 events currently and I easily exceed it.

I also use the properities of the same calendar event to update the new event as shown below – I use the same Id, Subject, Start and End times as well as the Body and Location. The Email fields are the current on call engineers

I hope this was useful for you.

A simple flow that takes out a very manual and error prone process out of my work life.

What kind of schedule automations will you build? Tell us below in the comments, in the community or on Twitter!

The post Advanced | Flow of the Week: Automated recurring meeting update weekly with differing meeting invitees appeared first on Microsoft Power Platform Blog.

Internally at Microsoft, we use a system call Incident Call Manager (ICM) to handle live site servicing rotation and service outage notifications. Mulitple Microsoft Teams use ICM for the devOps/Live site rotations with different engineers on call for differing periods. As part of handling service outages and investigations, frequently we need to look up the engineers on call for a different service to get help. The Flows team (as is true for mulitple teams) needs to interact with mutliple partner teams while investigating incidents. Its pretty common for us to lookup who the onCall engineer is for a particular service – the flow I describe makes saves time for our OnCall engineers by updating an OneNote with the onCall lists for multiple teams each week.

The flow I describe users a Custom API that’s published internally within the Microsoft tenant to talk to the ICM service, builds up a HTML table of all partner teams we typically interact with and updates a section in One Note weekly so we have a handy place to look up the onCall engineers for the team we interact with.

The flow is shown below

The flow calls the ICM connector mutliple times, gets the onCalls for a particular service  – you can see in the picture above that calls are made for the Flow Service followed by PowerApps RP, and then API Hubs service and so on.

Note that there’s a compose action that processes the results of the JSON object returned by the connector for each ICM service – as shown below – I do that becuase I needed to transform the JSON object returned by the service to add an addiontal field. Take the flow team snip below

The JSON object returned by the ICM connector looks like this – Notice that I’m pulling “TeamName”, “Email” and “Name” fields from mutliple JSON objects in the original payload and converting it to a new JSON object that only has these fields that I’m interested in as shown below. – Lets call these JSON objects the full ICM Objects. At the end of the flow, I have a bunch of these JSON objects for different services and I need to process them to create a HTML table.

I use the handy union function as describe here(https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-definition-language) in the compose card at the end to create an single array of these JSON objects to parse to the create HTML table

Then I use the CreateHtML to create a html table of the JSON objects and write to a One Note section. Noe that OneNote requires a html snipped to properly create and name the title of the page – Like so

At the end – In One note you see these cool entries every week!

I hope this was useful, important topics covered here:

How to extend a JSON object in building the full onCall JSON object. 

Combining JSON objects using the union function and how to create sections in OneNote.

As always, if you have comments, please leave them in the comments below, in our community or tweet us on twitter!

The post Advanced | Flow of the Week: Post the on-call engineer list to a OneNote Page on a weekly basis appeared first on Microsoft Power Platform Blog.

For today, I’ll talk about a flow that we use that we use to notify our team to test the new Microsoft Flow portal build (https://flow.microsoft.com) that is going to be rolled out to all our regions. Previously, this was a manual process – internally the development leads would need to remember that a build was in the pre-production slot and remind the team to validate the bits to catch any last minute regressions. Naturally, there were lots of misses due to the human intervention this requires.

We ended up creating a flow that does this quite trivially. The logic can be summed up as:

• Every hour
• Query the build that is in pre-production
• Compare the build version with the version that was previously in pre-production
• If they are different, then send an email to test and update state to mark deployed build as current for next check.

A couple of interesting things to note:

1. The previous build state is stored as a JSON file in a SharePoint site
2. The Parse JSON method is used to extensively parse and extract JSON tokens

Querying the bits in pre-production is accomplished using the HTTP GET action against our endpoint (https://flow.microsoft.com/healthcheck – you can execute the same action against our endpoint, it is un-authenticated). The response is standard JSON and it contains the build version in the “x-ms-request-id” value. The results from an executed flow run (with highlighted the build version) are here:

I use the ParseJSON action to parse the headers. The Use sample payload to generate schema is pretty handy if you don’t want to deal with schema definition (this is the easiest way I found to generate a JSON schema).

I use a file stored on a SharePoint site as a “state” to store the last deployed build. The file is a simple JSON with the value of the last build number as shown below. I had to create the file manually the first run to be ready.

I hope this was useful for you. As always you can ask questions here or on the flow discussion forums.

The post Flow of the Week: Automated notification when a new build is deployed to Production appeared first on Microsoft Power Platform Blog.