A Fabric item can now have up to 20 schedules attached to it.
These schedules can have different purposes, let's say one is for nightly runs and another one is for runs during working hours.
If we want to update a schedule via API, we need the schedule ID.
To get the ID, we can list the schedules. But, there's no easy way to pick the relevant schedule from the returned list or schedules - because there's no name or description associated with a schedule object.
Please add the option to create a name or description for an item schedule.
This could also show up in the run log of an item (run was triggered by schedule [Name]) which would provide useful context for the run.
It could also be cool if an item could pick up the schedule name as a "TriggeredBy" property and potentially execute conditional logic depending on which schedule triggered the run.
5 Comments
zhayaMicrosoft Employee
Status changed:NewtoUnder Review- ToddChitt
Super User
And PLEASE expose this under dynamic content so that we can pick up WHICH SCHEDULE was used to trigger a pipeline! Similar to this ides: https://community.fabric.microsoft.com/t5/Fabric-Ideas/Make-quot-Triggered-by-schedule-ID-quot-available-through-system/idc-p/4874795#M164999 
derrick777Advocate I
This idea is key! We also need this to be able to use that name to filter which tables in a dynamic configuration environment have to be refreshed! Currently, I use an extra layer of data pipelines per schedule just to be able to achieve this, which is ugly and unnecssesarily expensive!
frithjof_vCommunity Champion
The name and description would be useful context for my colleagues, and AI, to understand why a schedule exists and why it is configured to run exactly at the time it is configured to run.
Without a description, this involves a lot of guesswork or unnecessary questions to colleagues who may or may not be available at the moment.
- ToddChitt
Extremely useful also would be to expose that Schedule NAME property to Data Factory Pipelines and Dynamic Content like is available in classic Azure Data Factory. This would go a long way in helping configuration driven pipelines where everything is stored in a configuration table. Right now, the dynamic expression of @pipeline().TriggerId is the run ID (GUID) of the schedule, and it changes on every time the schedule it met. It is good only for logging purposes.
And while we're at it, let's talk about terminology: In classic ADF, you had "Triggers" you could manage. In Fabric Data Factory, they are "Schedules" and the "Trigger" is the instance of a schedule's timing/conditions being satisfied.
Consistency across products, please!
