Today, we’ll cover a critical practice that every integration architect should understand: how to properly control the initial state of your Consumption Logic Apps at deployment time.
This is especially important in Production environments where you want to prevent unexpected workflow executions before all dependencies and configurations are validated. Let’s dive in!
📝 One-Minute Brief
To deploy Consumption Logic Apps disabled by default, use the state property in ARM templates and parameterize it in your CI/CD pipeline. This prevents unexpected executions and gives you time to validate connectors and dependencies before activating production workflows. Simply set state: “Disabled” in your ARM/Bicep template and enable the workflow only after validation is complete.
The Problem: Unintended Executions at Deployment
When you deploy a Consumption Logic App with triggers like Recurrence or event-based triggers, they often start running immediately after deployment. If something isn’t quite right, you’ll face:
- ❌ Failed workflow executions filling your run history with errors
- ❌ Unnecessary alerts and operational noise
- ❌ Potential downstream issues (incorrect data processed, failed API calls, etc.)
- ❌ Confusion about whether the deployment was successful
Solution: Deploy your Logic Apps disabled by default, validate everything works, then enable them.
Imagine deploying a new order processing Logic App in Production with a Recurrence trigger set to run every hour. If a dependent microservice is offline, your new workflow will immediately start failing, generating alerts and confusion. By deploying disabled, you can:
- ✅ Verify all connectors are properly authenticated
- ✅ Confirm all endpoints are reachable
- ✅ Validate dependencies are ready
- ✅ Test one execution manually
- ✅ Only then enable it for production traffic
How to make sure your Logic App is deployed disabled by default
For Consumption Logic Apps, the solution is straightforward. You simply need to add the state property to your ARM template or Bicep file and parameterize it for flexibility across environments.
Using ARM Template with Parameters
Here’s a complete example with a parameterized state property:
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"logicAppName": {
"type": "string",
"metadata": {
"description": "Name of the Logic App"
}
},
"logicAppState": {
"type": "string",
"defaultValue": "Disabled",
"allowedValues": ["Enabled", "Disabled"],
"metadata": {
"description": "Initial state of the Logic App"
}
}
},
"resources": [
{
"type": "Microsoft.Logic/workflows",
"apiVersion": "2019-05-01",
"name": "[parameters('logicAppName')]",
"location": "[resourceGroup().location]",
"properties": {
"state": "[parameters('logicAppState')]",
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"contentVersion": "1.0.0.0",
"triggers": {
"Recurrence": {
"type": "Recurrence",
"recurrence": {
"frequency": "Day",
"interval": 1
}
}
},
"actions": {
"Process_Order": {
"type": "Http",
"inputs": {
"method": "POST",
"uri": "https://api.contoso.com/orders",
"body": "@triggerBody()"
}
}
}
}
}
}
]
}
Using Bicep
Bicep provides cleaner syntax and is the recommended approach for new deployments:
param logicAppName string
param logicAppState string = 'Disabled'
param location string = resourceGroup().location
resource logicApp 'Microsoft.Logic/workflows@2019-05-01' = {
name: logicAppName
location: location
properties: {
state: logicAppState
definition: {
'$schema': 'https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#'
contentVersion: '1.0.0.0'
triggers: {
Recurrence: {
type: 'Recurrence'
recurrence: {
frequency: 'Day'
interval: 1
}
}
}
actions: {
Process_Order: {
type: 'Http'
inputs: {
method: 'POST'
uri: 'https://api.contoso.com/orders'
body: '@triggerBody()'
}
}
}
}
}
}
Enabling After Validation
Via Azure Portal
- Navigate to your Logic App resource in the Azure Portal.
- In the Overview panel, you’ll see the current state.
- Click the Enable button.
- Confirm the action.
Via Azure CLI
# Single command to enable
az logic workflow update \
--resource-group my-resource-group \
--name order-processor \
--set state=Enabled
# Verify it's enabled
az logic workflow show \
--resource-group my-resource-group \
--name order-processor \
--query 'state'
Via PowerShell
# Connect and authenticate
Connect-AzAccount
Select-AzSubscription -SubscriptionId "<subscription-id>"
# Enable the Logic App
Set-AzLogicApp -ResourceGroupName "my-resource-group" \
-Name "order-processor" \
-State "Enabled"
# Verify
Get-AzLogicApp -ResourceGroupName "my-resource-group" -Name "order-processor"
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
