Forum Discussion
Hierarchy Slicer Metadata for Auto Date/Time Hierarchies in Power BI Embedded
Hi Shubhangi18 ,
Thank you for your follow up.
To clarify, when referring to a dedicated Date table and custom hierarchies, you would retain your existing columns Column A, Column B, and Column C as they are, without removing or migrating any data. There is no risk of data loss.
The main issue is that Auto Date Time generates hidden date tables and hierarchies, which are exposed in the Embedded API only as Date Hierarchy, without linking back to the original columns. Since these LocalDateTables are not accessible via the API, it is not currently possible to determine whether a selection originated from Column A, Column B, or Column C.
The recommended approach is to modify the report's model by creating custom hierarchies with distinct names and using those in the slicer. For example, you could define separate hierarchies for Order Date, Ship Date, and Invoice Date. These custom hierarchies are identifiable through the API, enabling you to pinpoint the source context.If your report currently uses Auto Date Time hierarchies, there is no supported API method to map a hierarchy slicer back to its underlying date column. In this case, updating the report to use custom date hierarchies is the only reliable solution to avoid ambiguity.
In summary, the recommendation is to keep your existing date columns and replace the Auto Date Time hierarchy objects with custom hierarchies that can be uniquely identified through the API.
Thank you.
Hi Tejaswi,
Thankyou for the confirmation and documentation link. Quite helpful!
Can you please elaborate more on the "To address this, if you need to distinguish between multiple date hierarchies in your embedded solution, it is recommended to use a dedicated date table and create custom hierarchies." part ?
Lets say if users already have a table called Table A with 3 date columns Column A,B,C. These are separate date hierarchies.
Now what is the suggested workaround without existing data loss?
Hi Shubhangi18 ,
Thank you for your follow up.
To clarify, when referring to a dedicated Date table and custom hierarchies, you would retain your existing columns Column A, Column B, and Column C as they are, without removing or migrating any data. There is no risk of data loss.
The main issue is that Auto Date Time generates hidden date tables and hierarchies, which are exposed in the Embedded API only as Date Hierarchy, without linking back to the original columns. Since these LocalDateTables are not accessible via the API, it is not currently possible to determine whether a selection originated from Column A, Column B, or Column C.
The recommended approach is to modify the report's model by creating custom hierarchies with distinct names and using those in the slicer. For example, you could define separate hierarchies for Order Date, Ship Date, and Invoice Date. These custom hierarchies are identifiable through the API, enabling you to pinpoint the source context.
If your report currently uses Auto Date Time hierarchies, there is no supported API method to map a hierarchy slicer back to its underlying date column. In this case, updating the report to use custom date hierarchies is the only reliable solution to avoid ambiguity.
In summary, the recommendation is to keep your existing date columns and replace the Auto Date Time hierarchy objects with custom hierarchies that can be uniquely identified through the API.
Thank you.
Hi Shubhangi18 ,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Thank you.Hi Shubhangi18 ,
I wanted to follow up and see if you had a chance to review the information shared. If you have any further questions or need additional assistance, feel free to reach out.
Thank you.