Self Service Maintenance Windows for Logic Apps

We had a fun problem today. We have a scenario with a big integration platform with hundreds of interfaces. Within all the interfaces we have groups of interfaces which support different application and business process integration requirements. Sometimes we have a scenario where a given application will need to have a maintenance window and we will need to pause certain logic apps related to that application for the duration of the maintenance window.

The problem is that some applications have a recurring monthly maintenance window and we wanted to allow the application specialists the opportunity to pause and resume their interfaces themselves when there is a maintenance window rather than needing to chase someone on the integration team outside of normal hours to do this menial task for them. We wanted to look at using Azure DevOps and Power Automate to provide a way to let the application team do some self service in this space.

The process we wanted to follow is:

  • Maintenance window starts
  • Application support users will pause their interfaces
  • Application maintenance happens
  • Maintenance window ends
  • Application support user resumes their interfaces

We wanted to retain control over what happens so we will script the pause and resume steps in Powershell and run them in a DevOps pipeline so that it follows all of our release and change management processes. We will then allow the application support team to trigger the devops pipeline in an easy to consume way so they can stop and start selected interfaces to suit their maintenance windows.

Lets have a look over how we can do this.

DevOps Release

In Azure DevOps I created a classic release pipeline which uses a simple powershell task based on the article below I created a while back in the integration playbook where you can disable or enable a set of logic apps.

In the Pipeline I wanted a stage for the disable and enable for my environments.

Next I wanted to create a Power Automate Flow which I can share with users outside of the integration team so that they can trigger the pipeline to enable and disable interfaces when their is a maintenance window.

Flow Overview

The flow is triggered with the trigger which will allow users to have a flow button. This will let then trigger it from a mobile device.

The flow will then create a release in Azure DevOps and then find the environment we want to run and make the pipeline run the scripts for that environment.

Flow Button Trigger

In the trigger I ask for 2 inputs, the first is a drop down with the names of the environments in my release pipeline. This will let the user indicate which environment they want to enable or disable.

The 2nd parameter is an RFC number which our change control process will require to be captured. When I create the release in Azure DevOps I will add the RFC number and the user who triggers the flow to the devops comments.

Create a new Release

In the Pipeline I can use the Azure DevOps connector to make it easy to perform operations against Azure DevOps. There is an out of the box connector for creating a release. I will choose the project and release pipeline and add my comments.

Parse the body from the creation of the release

When the release is created the connector provides a big json response for the release. Inside this it will contain the id for the environments that were created. I will parse the body response from the create release with the below schema so I can check for the environment id I need.

    "type": "object",
    "properties": {
        "Environments": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "Id": {
                        "type": "integer"
                    "Name": {
                        "type": "string"
                "required": [
        "Id": {
            "type": "integer"

Loop to Get the environment ID matching the release environment name

I just do a loop over the environments and check for the name to match the state name chosen by the user, then I have the environment id.

Trigger the release environment stage to Run

To trigger the running of the environment stage in the release I need to use the Send HTTP request to DevOps task because there is no explicit action for this. Below is the configuration to run the stage in the pipeline.

Next I just sit back and wait for the pipeline to complete. Note that I could extend the flow if I choose to monitor for the completion of the pipeline stage and send a notification but we can keep that for another day.

The post Self Service Maintenance Windows for Logic Apps appeared first on Microsoft Integration & Cloud Architect.

Self Service Maintenance Windows for Logic Apps was first posted on April 20, 2022 at 7:12 pm.

©2019 ”
Microsoft Integration & Cloud Architect“. Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at [email protected]

Self Service Maintenance Windows for Logic Apps

Leave a Reply