Friday Fact: You can test Logic Apps actions with Static Result

This will be our second Friday double facts, since we forgot to publish a Friday Fact a few weeks ago. So this will be a compensation blog post.

In most integrations, the workflow logic is not the real problem. The real problem is everything around it: external APIs, email systems, ERPs, databases, throttling rules, security constraints, approvals to hit production-like endpoints, and so on. All of that makes testing slow, politically expensive, and painful. Sometimes the API’s are not yet available either.

Static results, in many scenarios, try to solve or minimize this by letting you “fake” the output of any action in your Logic App. Instead of actually calling the downstream system, the runtime injects a response that you define (status code, headers, and body). The workflow then continues as if that action had really returned those values. In other words, you can test the behavior of your Logic App without touching real systems.

Why it matters & what it’s for

Static result is not just a convenience feature; it’s a control feature:

• Predictable runs: Every run returns the same predefined output. That means you can validate branches, conditions, and error handling without “maybe this time the API will behave differently”.
• Safe demos and training: You can present and record a demo with live executions, without sending emails, creating tickets, or burning API calls.
• Fast feedback, low cost: You don’t need test data, you don’t need a sandbox backend, and you don’t pay for unnecessary connector usage while iterating.
• Contract-first thinking: You’re forced to model the contract between actions:
  • Which status code do I expect?
  • Which headers are required?
  • Which JSON shape does the downstream logic consume?

How it works

Here’s what actually happens when you enable Static result on an action:

• Static result is per action. You enable it on a specific action (for example, an HTTP action). Only that action is mocked.
• When Static result is enabled, the action does not execute for real. No HTTP call, no SQL call, no email sent. Instead, the Logic Apps runtime injects the output you configured.
• Under the hood, the workflow definition contains a staticResults section that holds your fake outputs, and the action references that static result with runtimeConfiguration.staticResult.name.
  That means this is not just a designer trick; it’s part of the workflow definition and can move with your code.
• Triggers are not mocked with this feature. Static result applies to actions.
• Normal engine rules still apply: run-after behavior, conditions, scopes, and termination logic all work on top of this injected output.

Example

Let’s look at a minimal pattern where our Logic App will have the following logic:

• Receives a request by using the When an HTTP request is received trigger
• Then it will call an API by using the HTTP action
• After that, we will evaluate the response status of the call by using a Condition that checks the HTTP action’s status code:
  • @equals(outputs(‘HTTP’).statusCode, 200)
• If the result is 200, we follow the “Success” branch.
• Otherwise, we follow the “Failure” branch.

To implement a Static result on our call to the API – HTTP action, we need to:

• In the HTTP action, open the Testing tab and enable Static result.
  • Set the Status property to Succeeded. At this point, you are telling the runtime: “Even if this action would normally call an API, don’t. Just behave as if the call worked.”

In this view, the Static result is turned on for the HTTP action. The action is marked as Succeeded. From now on, the Logic App will inject our fake response instead of making a real HTTP request.

• Next, still in the same Testing tab, we define the exact output we want that action to return:
  • Status code = 200
  • Header Content-Type = application/json
  • Body {“message”: “Hello Friday Fact”}
• This output is what the rest of the workflow will see in outputs(‘HTTP’). The Condition will read statusCode = 200 and follow the “Sucesso” branch.

Here we specify the output of the HTTP action: a 200 status code, a JSON body, and headers. During execution, the run history will show these values as if they were returned by a real API. This lets you exercise and record the happy path without touching any external system.

Now, if we want to do the opposite—implement the Failure status. In the same HTTP action’s Testing tab, instead of Succeeded, we set:

• Status = Failed
• Error code = InternalServerError
• Error message = Falha simulada
• Output status code = 500

This is a fully controlled failure. You are injecting a predictable HTTP 500 without needing a backend that actually fails.

The HTTP action is now configured to fail on purpose. We define both the error metadata (code/message) and the HTTP status code we want to simulate. This lets us drive the “Falha” branch of the workflow on demand.

When you run the Logic App in this mode, the run history will show that the HTTP action “failed”. You’ll see your own error message and code, the ones you configured, even though no live call was made.

Friday Fact Takeaway

Static result gives you something we rarely get in integration: determinism on demand.

You can say “pretend success”, “pretend failure”, and instantly prove how the workflow behaves, including branching, compensation logic, and error messaging, with zero dependency on external systems.

That means:

• Safer demos
• Faster iteration
• Cheaper testing
• Clearer ownership of contracts

Turn it on while you design and teach. Turn it off when it’s time to integrate with the real world.

The choice isn’t about which service is “better,” but which is right for the job. The next time you need to connect two systems, stop and ask yourself the correct questions to decide what to use.

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!