Enabling/disabling relationship on Dashboard level

Feature Suggestions
1

We would like to have an ability to control/toggle relationship status (active/inactive) on a dashboard level, instead of resolving it by different metrics.

2

Hi @Datatech_Owner,
Thank you for reaching out! We’re glad to hear back from you since your last post.

To give you some quick context on why the platform is set up this way:

  • Defined at the metric level: This ensures strong data governance. Admins and analysts who deeply understand the data schema maintain control over how the data connects.
  • Served at the dashboard level: The dashboard is designed to be a seamless, self-serve environment for business users to interact with pre-curated data, rather than modifying the underlying logic on the fly.

Regarding your request, we’d love to learn more about the specific workflow or challenge your team is running into here. Could you share a bit about the use case you’re trying to solve for so that we can discuss how this can be supported?

3

Hi Hien!

I totally understand the reasons why the platform is set this way - there are still cases when additional flexibility can heavily benefit.

We have a kinda complex semantic layers setup where attribution data is connected to deals which are connected to orders. And within that setup there are multiple anchor date dimensions (e.g. cohort date/order date/deal date). Order can be also connected to attribution without a deal (e.g. self-serve order). So we have to basically duplicate metrics per every connection setup.
If we had the control over which relationships are enabled → we would have been able to make a simple trigger (e.g. cohort relationship ON, order date relationship ON) and reutilize existing metric set.
Thanks, Misha

4

Hi @Datatech_Owner,
Thanks a lot for sharing the detailed context. This is very helpful.

It sounds like your primary goal is to maintain a single, consistent set of metrics, while allowing analysts to flexibly choose the appropriate relationship path depending on the analysis context, instead of duplicating metrics for each setup. Is that correct?

Also, just to clarify, is this flexibility mainly intended for your analyst team (who understand the data model) rather than for general business users on dashboards?

Would love to confirm so we can think through the cleanest approach within the current modeling framework.

5

To clarify - if we relate to single charts where we can select any core dimension → everything works. 1 chart for sales based on purchase date → all good.

But if we utilize metric sheet approach, calendar date concept and if we want to output multiple metrics → then all metrics have to be duplicated per relationship setup (e.g. sales order date based, sales cohort date based, sales book_a_call date based) and so on.

6

Hi Misha,

Let us confirm we understand your use case correctly.

Single charts are already fine. The friction shows up with the metric sheet. In a single widget, you want to display multiple metrics over a shared calendar, each resolved by a different date path (e.g. sales by order date vs. cohort date vs. book-a-call date). Today, this requires duplicating metrics for each relationship setup at the dataset level.

Your goals are:

  • Keep the dataset clean with a small set of base metrics
  • Allow each widget to freely choose the date path without adding new dataset metrics

Good news is, this can be handled without duplicating metrics. The approach is to keep a minimal set of base metrics in the dataset, and define additional variations as ad-hoc metrics at the widget level.

For example, define a base metric in the dataset, such as: total_sales = sum(orders.amount)
Then declare all relevant date relationships there (with one active by default, others inactive).

Then in the widget, define ad-hoc metrics that reuse the base metric but apply different relationship paths:

calculation sales_by_cohort {
  label: 'Sales by Cohort Date'
  formula: @aql total_sales
    | with_relationships(attribution.cohort_date > calendar.date) ;;
  calc_type: 'measure'
  data_type: 'number'
}

This way, we still get one metric per combination, but they are defined at the widget level instead of the dataset. It keeps the dataset maintainable while giving widgets full flexibility.

References:

Please let us know if this approach fully covers your current use case, or if you’d like more details or have any additional goals beyond this.
BR,

7

The duplication still happens - not in dataset, but rather on widget level. This is actually our current way of solving the issue, but still a lot of ctrl c + ctrl v.

8

Thanks for clarifying. So the goal is to avoid rebuilding the metrics at any level, not just keeping the dataset clean. Let us dig into your case a bit more, and we’ll follow up as soon as we have a proper approach for this

9

Hi Misha,

Thanks for your patience. Let us reframe the problem to make sure we’re aligned.

A dashboard-level relationship toggle would let you switch a metric to a different join path, but that only works when you’re viewing one metric at a time. In your case, you want all the metrics to appear in the metric sheet at the same time, each on its own join path. That means each metric needs its join path defined independently, so a single dashboard-level toggle wouldn’t actually fit this use case (please correct us if we’re misreading it).

So the way we see it, this isn’t really about changing join paths at runtime, it’s about reducing the manual effort of defining a separate metric per path (the ctrl-C / ctrl-V you mentioned). A couple of notes on that:

  • If a path-specific metric is only used in one widget, defining it there with with_relationships() is fairly light.
  • If the same metric is reused across many widgets, it’s better to define it once in the dataset and reference it, rather than re-authoring it each time.

To make sure we suggest the cleanest setup for your workflow, would you be able to share a short screen recording of how you’re building these metric sheets today? It would help us pinpoint where the repetitive effort is and how best to reduce it. If you’re sharing a video or any sample data, feel free to send it over via email ([email protected]) so we can review it properly.

Please also let us know if we’ve understood the goal correctly.

Best,

10

now i tend to think that for clean reusable approach it is better to just have that on dataset level. ctrl c + ctrl v but consistent and reused. we can close this ticket