Why an activity was not triggered on the Failure of previous Web activity in ADF

Hi Deirdre Clark,
it turned out that your “Set exit message” never fires after the very first “Get ChangeOrderRequest” because ADF never sees that first call as a hard failure in your pipeline graph—so its Upon Failure branch never kicks in—and so the ForEach just marches on and invokes your web activity two more times.

Here’s the breakdown:

1. By default a Web activity that returns any HTTP-status between 200 and 299 is considered Succeeded by ADF—even if your API payload says “Item not found.”
2. Your “Set exit message” is wired to the Upon Failure output of the Web activity (or possibly to the parent ForEach’s failure), so if ADF doesn’t mark that call as Failed, that branch never executes.
3. Because nothing actually “failed” from ADF’s viewpoint, the ForEach doesn’t stop and continues on to make the next two calls.

What to try next:

• Inspect your “Get ChangeOrderRequest” settings and see if the API is returning a 2xx status for “Item not found.” If so, ADF will treat it as success.

• If you want to trap a business-logic “not found” and set your exit message, either

– Adjust your API to return a non-2xx (for example 404), or

– Keep your API 200, but add an If Condition after the Web activity that checks

@equals(activity('Get ChangeOrderRequest').Status, 'Succeeded') AND  

@contains(activity('Get ChangeOrderRequest').Output, 'Item not found')  

and in the True branch do your Set exit message + skip the SP.  

• Make sure you’re not using continueOnError:true on the Web activity—this will suppress a real failure and keep everything “Succeeded” in the run.

Let me know if you need any help wiring that up!

Reference list

• Troubleshoot pipeline orchestration and triggers in Azure Data Factory

https://learn.microsoft.com/azure/data-factory/pipeline-trigger-troubleshoot-guide

• How to check and branch on activity-level success and failure in pipelines

https://learn.microsoft.com/azure/data-factory/tutorial-pipeline-failure-error-handling#conditional-execution

• Errors and Conditional execution in ADF

https://learn.microsoft.com/azure/data-factory/tutorial-pipeline-failure-error-handling

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.

Can you please send the image of your pipeline and activities within the foreach activity?
But based on the JSON shared, below seems to be the flow within the for activity :

within ForEach :

Get Access Token>on Success> Get Change Order Request >On Failure> Set Exit Message

In ADF, if any iteration of foreach activity fails, the pipeline doesnt end there. It still proceed to the next iteration and completes all iterations until you explicitly have a logic to exit/end pipeline

In Azure Data Factory, whether a “follow‑up” activity runs after a failure depends entirely on how the dependency paths are configured and which error‑handling pattern is in use.

From the behavior described:

• The first Get ChangeOrderRequest Web activity failed with “Item not found”.
• The Set exit message activity did not run after that first failure.
• The other two Get ChangeOrderRequest Web activities still ran.

This matches the documented behavior when:

1. The dependency from Get ChangeOrderRequest to Set exit message is not configured on the Upon Failure path, or
2. The Upon Completion path is used instead of Upon Failure, or
3. The pipeline is using a pattern where the failure path does not affect the overall flow (for example, a Try‑Catch or Do‑If‑Skip‑Else pattern), and the ForEach continues to process remaining items.

Key points from the error‑handling and conditional‑path rules:

1. Only one dependency path is activated per run of an activity
   For any activity, exactly one of these can fire for a given run:
   • Upon Success – when the activity succeeds
   • Upon Failure – when the activity fails
   • Upon Completion – when the activity completes (success or failure)
   • Upon Skip – when the activity is skipped Also, Upon Completion cannot coexist with Upon Success or Upon Failure for the same dependency. If Set exit message is connected via Upon Completion, then the Upon Failure path is not used.
2. Try‑Catch and Do‑If patterns change how failures propagate
   • In a Try‑Catch pattern, only the Upon Failure path is defined. The pipeline is considered successful if the failure‑handling activity succeeds, and subsequent activities can still run.
   • In a Do‑If‑Else pattern, both Upon Failure and Upon Success paths are defined. If the main activity fails, the pipeline is considered failed even if the failure‑handling path succeeds.
   • In a Do‑If‑Skip‑Else pattern, both Upon Failure and Upon Success paths are defined, with a dummy Upon Skip at the end; the pipeline still ends in success if the failure‑handling path succeeds.
3. ForEach does not automatically stop on a failed iteration
   A ForEach activity will, by design, continue to iterate over its items unless explicitly configured to stop or unless the failure is allowed to propagate and fail the whole pipeline. If the failure is “caught” by a Try‑Catch‑style pattern (or the failure is not wired to stop the loop), later iterations will still run.

Putting this together for the described behavior:

• The first Get ChangeOrderRequest failure did not trigger Set exit message because the dependency from Get ChangeOrderRequest to Set exit message is not correctly configured as an Upon Failure path (or is overridden by an Upon Completion path). As a result, when the Web activity failed, no failure‑specific branch was activated to run Set exit message.
• The other two Get ChangeOrderRequest activities ran because the ForEach loop is configured to continue processing items even when one iteration fails (for example, using a Try‑Catch‑style pattern where the failure is not allowed to fail the pipeline or stop the loop).

To get the intended behavior:

1. Open the pipeline in ADF Studio.
2. Select the Get ChangeOrderRequest activity inside the ForEach Prime Contract.
3. In the “Activities” pane, check the dependency lines from Get ChangeOrderRequest to Set exit message:
   • Ensure there is a dependency with Condition = Upon Failure.
   • Ensure there is no dependency with Condition = Upon Completion from the same activity to Set exit message, because that would block the Upon Failure path.
4. Confirm that any stored‑procedure activity is not connected via Upon Success from Get ChangeOrderRequest when the intent is to skip it on failure.

If the goal is “fail Web activity → set exit message → skip stored procedure but continue the rest of the pipeline”, configure a Try‑Catch pattern:

• Get ChangeOrderRequest → Upon Failure → Set exit message.
• Do not connect the stored procedure on Upon Success from a failed Web activity; instead, connect subsequent activities in a way that only runs them when the Web activity succeeds, or runs them independently of that iteration.

References:

• Errors and Conditional execution
• Web activity in Azure Data Factory and Azure Synapse Analytics