Hi all,
I am trying to create a view to showcase the evolution of financial figures based on a date picker. The picker determines the YTD(year to date) and the LYTD(last year to date).
The issue I am facing is that it seems impossible to have the bars side by side in Workshop, does anyone know how to do that without having to get YTD and LYTD as separate metrics?
These are the two ways I am able to showcase the evolution.
Thanks in advance!
Hi Alpi,
Here are some options that jump to mind :
Option 1: Reshape Your Data
| month_label | period | value |
|---|---|---|
| 01 - Jan | YTD | 130M |
| 01 - Jan | LYTD | 120M |
| 02 - Feb | YTD | 125M |
| 02 - Feb | LYTD | 115M |
| 03 - Mar | YTD | 78M |
| 03 - Mar | LYTD | 65M |
You can add a column with the year so that you can conditionally color your segments.
–> Bars appear side by side per month
–> Correct ordering because of the month label prefix (it’s a string type though …)
–> Single chart, single dataset
Option 2: Add an “N-1 Reference Period” Date Column
You could go for a variation of that kind (possibly also add YTD, LYTD tags):
| reference_month (date typed) | year | value |
|---|---|---|
| 2026-01-01 | 2026 | 130M |
| 2026-01-01 | 2025 | 120M |
| 2026-02-01 | 2026 | 125M |
| 2026-02-01 | 2025 | 115M |
–> Bars align side by side because both periods map to the same X-axis dates
–> Retains a proper date-typed X-axis (Workshop auto-formats and sorts correctly)
–> You keep the original date column for reference
Option 3: Function Backed Chart
Write a TypeScript that takes the date picker value as input and returns the reshaped data dynamically at runtime.
–> Fully reactive to the date picker
–> No need to pre-compute all periods
You could implement this easily with Claude or AI-FDE.
Some documentation here : https://www.palantir.com/docs/foundry/workshop/widgets-chart
Good luck !
Nico from Sibyl
Alpi,
Huge +1 to refactoring your data such that it is one object. The way I see it is that each OT you have is simply a different slice of the same real-world concept and should generally be joined (without knowing more about your workflow).
Separately, you may be able to add a string “Month” column to both such that you could make the x-axis is Jan, Feb, Mar, etc., a value which would exist on both object types, and then they may be able to coalesced because they share a common field. The labeling would take care of which year is being shown. I think this is the same principle as NicolasDaveau’s Option 2 but might be slightly simpler.
Let me know if anything works - good luck!
Hi both,
Thanks for replying to my post, appreciate it!
My setup is right now involved creating object in atomic granularity, meaning that each unique object gets its own ontology object dataset with the relative parameters.
Where there is a need to bridge due to N:N relationships, then I would create a bridging object with an encrypted primary key. This way, I am linking multiple object and creating transversals to be able to communicate between the objects and extract properties. I am not entirely sure if this is the right approach compared to creating one MEGA object, so please enlighten me if you would know better.
Going back to the initial topic, yes I am reporting KPIs for YTD and LYTD coming from the two different transversal objects, except as you mentioned @ozil496 , they are subsets of the original transversal object. With the current setup, as we have established it seems very difficult to show graphs as one would wish, but I find very inconvenient that I would need to either redo my setup towards a reporting_date datetype or build a mega object. I imagined the whole concept of ontology is linking data together, so dashboards can be built without having to do joins preemptively, etc.
