Forum Discussion

Yazdan's avatar
Yazdan
Icon for Advocate II rankAdvocate II
1 year ago

Unable to Detect Scheduled Trigger Inside Pipeline — @pipeline().TriggerType Always Returns "Manual"

Hi all,

 

I ran into an issue while trying to detect whether my pipeline is triggered manually or by a schedule in Microsoft Fabric.

 

Scenario:

Main pipeline triggered by a Schedule trigger.

I used the built-in expression:

@pipeline().TriggerType


Expected behavior:

For a scheduled run, @pipeline().TriggerType should return "Schedule".

For a manual run, it should return "Manual".

 

Actual behavior:

Even when the pipeline runs via the schedule trigger, @pipeline().TriggerType still returns "Manual".

The outputs of the pipeline run also show:

"TriggerType": "Manual",
"TriggerName": "Manual"


Observation:

In the Monitor view, the “Run kind” column correctly shows Scheduled.

However, there is no system property inside the pipeline that exposes this trigger type reliably.

 

Request:
It would be great if Microsoft Fabric could expose the actual trigger type for the current pipeline run as a system property (similar to how Monitor shows “Run kind”), so pipelines can detect it without requiring a parameter workaround.

 

Thanks!

data pipeline

6 Replies

  • Anonymous's avatar
    Anonymous
    Not applicable
    1 year ago

    Hi Yazdan ,

    You're absolutely right to flag this, and thanks for the clear breakdown.

    Yes this is confirmed Behavior

    • @pipeline().TriggerType always returns "Manual", even when the pipeline is triggered by a Schedule.
    • The Monitor view correctly shows "Run kind: Scheduled", but this info isn't exposed inside the pipeline.

    You can do bellow workaround

    Use a custom parameter in your Schedule trigger: "TriggerSource": "Schedule"  
    Then check it inside the pipeline: @pipeline().parameters.TriggerSource
    This lets you reliably detect the trigger type.

    Ideas for Improvement

    You’re spot-on with your request. Here are a few enhancements Microsoft could consider:

    • Expose TriggerType accurately as a system property, matching Monitor’s “Run kind”.
    • Add TriggerName and TriggerTime as accessible expressions inside the pipeline.
    • Enable conditional branching based on trigger type without needing manual parameters.

    These would make pipeline logic more robust and reduce friction for automation scenarios. Definitely worth submitting to Microsoft Fabric Ideas this would benefit a lot of users.

    Thanks,
    Akhil.

    • Yazdan's avatar
      Yazdan
      Icon for Advocate II rankAdvocate II
      1 year ago

      Hi Akhil,

       

      Thanks for your suggestion, but this approach doesn’t meet our requirement.

       

      Using a static parameter in the schedule trigger is not suitable for my scenario because I need to detect the pipeline run type dynamically at runtime. The goal is to make different decisions in the pipeline depending on whether it’s a manual or scheduled run.

       

      Simply assigning a static “TriggerSource” parameter will not work, as it does not reflect the actual runtime trigger. I need a way for the pipeline itself to detect on each run whether it was triggered manually or via schedule, and then execute the relevant path or decision step accordingly.

       

      The workaround you suggested is just a manual assignment and doesn’t solve the problem of dynamic detection.

       

      Thanks,
      Yazdan

  • Anonymous's avatar
    Anonymous
    Not applicable
    1 year ago

    Hi Yazdan ,

    Thanks for the clarification now that makes perfect sense.

    You're absolutely right: using a static parameter in the schedule trigger is a workaround, not a dynamic solution. Unfortunately, as of now, Microsoft Fabric does not expose the actual trigger type (Schedule, Manual, etc.) as a runtime system property inside the pipeline, even though the Monitor view clearly shows it.

    Current Limitation

    • @pipeline().TriggerType always returns "Manual", regardless of how the pipeline was triggered.
    • There's no built-in dynamic way to detect the trigger source during execution.

    Since dynamic detection isn't supported yet, the best next step is to submit or upvote a feature request on Microsoft Fabric Ideas. Here's a suggested summary you could use.

    Thanks,
    Akhil.

  • Anonymous's avatar
    Anonymous
    Not applicable
    1 year ago

    Hi Yazdan ,

    Thanks for sharing and voting, that’s great. Both ideas seem very relevant, and the more traction they get, the higher the chances the product team will prioritize them. Let’s hope we see this capability exposed soon in Fabric pipelines it would really simplify these scenarios.

    Thanks,
    Akhil.