Accessing Active Schedule ID at Runtime in Microsoft Fabric Pipeline

[Yazdan]

Hi all,

I’m trying to access the unique Schedule ID of a pipeline run in Microsoft Fabric. Each time a pipeline is scheduled, it gets a unique Schedule ID. I want to use this ID at runtime to identify which schedule triggered the current run and make decisions in pipeline steps based on it.

I tried using:

@pipeline().TriggerId

…but it doesn’t work.

Is there a way to access the active schedule that triggered the current pipeline run during runtime? Any guidance or examples would be appreciated.

Thanks!

[v-dineshya]

Hi @Yazdan ,

Thank you for reaching out to the Microsoft Community Forum.

The Schedule ID is not exposed at runtime via system variables like @pipeline().TriggerId, only 20 schedules can be created and maintained per item, including those created via API.

Please try below alternative workarounds.

1. When creating a schedule, pass a unique parameter like scheduleName: "DailyRun_12AM" to the pipeline. You can then access this parameter at runtime using "JSON@pipeline().parameters.scheduleNameShow" . you don’t need to rely on the Schedule ID itself, but you still know which schedule triggered the run.

2. Create a metadata table in Lakehouse or SQL DB that maps schedule names to logic. At runtime, query this table using the passed parameter.

3. You can manually pass a parameter like TriggerSource: "DailyRun" when configuring the schedule. Then access it inside the pipeline.

Currently this feature is currently on the roadmap for future updates. Already an idea has raised in idea forum. Please refer below link.

Pass Parameters in Pipeline Schedule/Trigger - Microsoft Fabric Community

Please refer below links.

Solved: Re: Pass Parameters in Pipeline Schedule/Trigger - Microsoft Fabric Community

Solved: Re: Set parameter for scheduled run - Microsoft Fabric Community

I hope this information helps. Please do let us know if you have any further queries.

Regards,

Dinesh

[Yazdan]

Hi, thanks for your reply. 😊

Yea I already tried this way as below:

• Create a dictionary table in the Lakehouse or SQL DB and map each schedule run with the relevant parameter values.

• In the pipeline, use a Lookup activity to query this table.

• After the Lookup activity, add a Filter activity to filter the results by the current run time (can be caught with @pipeline().TriggerTime) and get the relevant parameter values.

• Define Set Variable activities in the pipeline and assign these values to variables (ideally with the same names as the parameters for clarity).

• Use these variables instead of parameters everywhere in the pipeline.

For separate behavior when the pipeline is run manually instead of by schedule:

• Add an If Condition activity before the above steps to check if the pipeline is running manually (using @pipeline().TriggerType).

• If it’s manual, skip the dictionary lookup and directly set variables with manual values.

• Then use these variables in the pipeline logic.

---

But it has some problems:

• The only way to find and select the schedule in the dictionary table is by querying with the pipeline schedule time for each run. But this time is not always exact—it has a tolerance of a few seconds—so a time range has to be defined in the dictionary table instead of an exact match.

• I also want to have separate behavior when the pipeline is run manually and skip these steps. I used @pipeline().TriggerType to detect if the pipeline is running manually and make a different decision, but this expression always returns “Manual”. I have already reported this issue here:
  Unable to Detect Scheduled Trigger Inside Pipeline

[v-dineshya]

Hi @Yazdan ,

Thank you for the update. As you mentioned in your previous response, you already reported this issue by creating another thread in this community. And thank you for taking the time to submit the idea, in the ideas forum.

Expose actual pipeline trigger type (Manual vs Sch... - Microsoft Fabric Community

Your input plays an important role in shaping future improvements to the Microsoft Fabric experience.

It helps other community members with similar needs find answers more easily but also makes your idea easier to discover and upvote increasing the chances for the Microsoft product team to review and potentially implement it in future updates.

Thank you again for contributing to the community.

Regards,

Dinesh

[nielsvdc]

The schedule ID is currently not available from the system variables.

An alternative way would be to create parent pipelines that execute the pipeline that you want to run. Then schedule each parent pipeline with a different schedule. You can then detect which parent pipeline has executed the child pipeline or use pipeline parameters pass a value you want to use for filtering.

But, ofcourse, this would create to much unnecessary overhead of items.

Hope this helps. If so, please give a Kudos 👍 and mark as Accepted Solution ✔️.

[Yazdan]

Hi,

Thanks for the suggestion!

Yes, this alternative would work, but I have more than 12 schedules, and using this method would create a lot of overhead due to defining so many parent pipelines.

I really appreciate your workaround and guidance though. 🙂

Thanks again!

Yazdan

[nielsvdc]

When you have more than 12 schedules, you might want to rethink your schedules and simplify them. You could also add an if-else or switch activity to your pipeline, to filter out certain hours you might not want the pipeline to execute stuff.

I have added an idea that you can vote on: Make "Triggered by schedule ID" available through ... - Microsoft Fabric Community

Hope this helps. If so, please give a Kudos 👍 and mark as Accepted Solution ✔️.

[Vaibhavi_Patel]

Hi @Yazdan 

You should not ask for the UUID odf schedule run. Reason: Microsoft Fabric is a SaaS ( Software as a Service ). This is not currently possible.

[Yazdan]

Hi @Vaibhavi_Patel 

Thanks for your reply. I understand that Fabric does not expose a UUID for scheduled runs.

Is there an alternative way to achieve this? My requirement is to recognize which scheduled pipeline triggered the run at runtime, so that I can take different actions or choose the correct next steps based on the schedule that triggered the pipeline.

For example, I need to distinguish between multiple scheduled runs and apply logic accordingly. Any recommended approach or best practice for this scenario would be appreciated.

Thanks,
Yazdan