Friday Fact: You can deploy your Logic App Standard Workflows locally in a disabled state

  • João Ferreira
  • May 8, 2026
  • 3 min read

Have you ever deployed a workflow only to find it suddenly running live when you weren’t ready? Yeah… that one stings.

You carefully build your workflow locally.
You test everything.
You deploy it…

…and boom, it’s already enabled and executing in production, especially if they are recurring or polling workflows!

So what’s going on?

📝 One-Minute Brief

Stop Logic Apps Standard workflows from running too soon. Set Workflows..FlowState to Disabled (local + CI/CD app settings) so recurring and polling triggers don’t start executing right after deployment.

What’s Happening?

By default, Azure Logic Apps Standard workflows don’t always respect your “not ready yet” intention during deployment. We have a previous Friday fact on how to make this happen for Logic App Consumption, and recently Sandro Pereira created a blog post on Logic Apps Best Practices, Tips, and Tricks about this topic as well. But I would like to align it as a Friday fact.

But in this article, we are gonna tell you that your local environment can control this as well!

The Fix

For Logic App Standard workflows, and in this case, inside your VS Code workspace, you can explicitly set the workflow state in your local.settings.json before deploying:

{
  "Values": {
    "Workflows.Stateful1.FlowState": "Disabled"
  }
}

Just replace Stateful1 with your workflow name.

When you deploy with this setting:

  • The workflow is created in a disabled state.
  • It won’t trigger or run automatically.
  • You stay in full control of when it goes live.

Through CI/CD, you have to create App Settings inside Environment variables for each workflow with the following setting pattern:

  • "Workflows.<WorkflowName>.FlowState": "Disabled"

The Catch

If you don’t configure this, your workflow may:

  • Deploy in an enabled state by default.
  • Start triggering immediately.
  • Execute with incomplete configs, test endpoints, or placeholder data.

And now you’re debugging live runs you never meant to start.

Why This Matters

  • Prevents accidental production runs.
  • Avoids triggering incomplete integrations.
  • Gives you control over rollout timing.
  • Saves you from “why is this already running?!” panic.

To lazy to read? We’ve got you covered! Check out our video version of this content!

Hope you find this helpful! If you enjoyed the content or found it useful and wish to support our efforts to create more, you can contribute towards purchasing a Sauron’s Action Figure for Sandro’s son, yep, not for me! 

Buy me a coffee
Author: João Ferreira

João Ferreira is a Enterprise Integration Consultant at DevScope

Leave a Reply

Your email address will not be published. Required fields are marked *

The Ultimate Cloud
Management Platform for Azure

Supercharge your Azure Cost Saving

Learn More
Turbo360 Widget

Back to Top