Skip to main content

AML Dashboard Interactions

Knowledge Checkpoint

A grasp of these concepts will help you understand this documentation better:

The explicit_interactions list wires blocks together, most commonly a control block driving one or more visualization blocks:

  • Every active connection is listed explicitly.
  • FilterInteraction, DateDrillInteraction, and PopInteraction are the interaction types you can configure here; drill-through is configured separately, via FilterBlock's settings.drillthrough.
Dashboard my_dashboard {
// ... blocks ...

explicit_interactions: [
FilterInteraction { ... },
DateDrillInteraction { ... },
PopInteraction { ... }
]
}
caution
  • Older dashboards may still use this legacy interactions key.
  • Always write explicit_interactions: [] in your canvas dashboards, even with no interactions. Missing this key falls back to legacy interactions behavior.

FilterInteraction

FilterInteraction is a single AML keyword, but its runtime behavior depends on the types of the from and to blocks, not on the keyword itself:

from blockto blockRuntime behavior
FilterBlockVizBlockFilter block controls a visualization (the common case)
FilterBlockFilterBlockParent-child filter: one filter block limits the suggested values of another
VizBlockVizBlockCross-filtering: clicking a data point in one visualization filters another
ParameterDescription
fromName of the block that drives this interaction (a FilterBlock or VizBlock, depending on the behavior above).
toList of target block names (strings). Group targets sharing the same field, aggregation, and disabled; anything else needs its own FilterInteraction entry with the same from.
fieldReference to the affected field on the target block(s), using r(model.field) syntax. Optional in some cases (e.g. a cross-filter (VizBlockVizBlock) entry doesn't take one at all), but write it explicitly whenever it applies.
aggregationOptional aggregation override, for filtering on an aggregated value instead of the raw field. Applied only when targeting a VizBlock; ignored for parent-child and cross-filter targets.
disabledSet to true to turn off the connection. Needs only from, to, and disabled.
explicit_interactions: [
FilterInteraction {
from: 'f_users_role'
to: ['v2']
field: r(public_users.role)
},
FilterInteraction {
from: 'f_users_role'
to: ['v3', 'v5']
field: r(homestay_hosts.role)
},
FilterInteraction {
from: 'f_users_role'
to: ['v6']
field: r(admin_users.role)
},
FilterInteraction {
from: 'f_users_role'
to: ['v4']
field: r(support_agents.role)
},
FilterInteraction {
from: 'f1'
to: ['v1', 'v2', 'v3']
field: r(model.field)
aggregation: 'count'
}
]

DateDrillInteraction

DateDrillInteraction connects a DateDrillBlock to one or more visualization blocks, mapping a date field in each to the viewer-selected time granularity. A given VizBlock can be targeted by only one DateDrillInteraction per dashboard.

ParameterDescription
fromName of the DateDrillBlock that drives this interaction.
toList of target block names (strings) that share the same field. Targets needing a different field go in a separate DateDrillInteraction entry.
fieldReference to the affected date field, using r(model.field) syntax. Required (no default).
explicit_interactions: [
DateDrillInteraction {
from: 'd_date_drill'
to: ['v1', 'v2']
field: r(orders.created_at)
}
]

PopInteraction

PopInteraction connects a PopBlock to one or more visualization blocks, mapping a date field in each to the viewer-selected comparison period. A given VizBlock can be targeted by only one PopInteraction per dashboard.

ParameterDescription
fromName of the PopBlock that drives this interaction.
toList of target block names (strings) that share the same field. Targets needing a different field go in a separate PopInteraction entry.
fieldReference to the affected date field, using r(model.field) syntax. Required (no default).
explicit_interactions: [
PopInteraction {
from: 'p_period_comparison'
to: ['v1']
field: r(public_users.created_at)
}
]

Interactions (legacy)

A quick comparison between the current and legacy syntax:

explicit_interactions (current)interactions (legacy)
BehaviorNothing is connected unless listedSame-dataset filters and charts auto-link; this list only records exceptions, mainly disabled links
Target syntaxBlock name references in toCustomMapping objects in to

How Holistics resolves having both syntaxes present in the same dashboard:

explicit_interactionsinteractionsResult
PresentPresentexplicit_interactions wins; interactions is ignored
Present❌ Absentexplicit_interactions wins
❌ AbsentPresentinteractions wins
❌ Absent❌ Absentinteractions wins (pure auto-linking, no exceptions declared)

FilterInteraction

interactions: [
FilterInteraction {
from: 'f_users_role'
to: [
CustomMapping {
block: 'v2'
field: r(public_users.role)
},
CustomMapping {
block: [
'v3',
'v5'
]
field: r(homestay_hosts.role)
},
CustomMapping {
block: 'v6'
field: r(admin_users.role)
},
CustomMapping {
block: 'v4'
field: r(support_agents.role)
}
]
}
]

DateDrillInteraction

Dashboard sales {
block d_date_drill: DateDrillBlock {
label: 'Drill by'
default: 'month'
}

block v1: VizBlock {
label: 'Revenue Over Time'
viz: LineChart { dataset: ecommerce }
}

block v2: VizBlock {
label: 'Orders Over Time'
viz: BarChart { dataset: ecommerce }
}

interactions: [
DateDrillInteraction {
from: 'd_date_drill'
to: [
CustomMapping {
block: ['v1', 'v2']
field: r(orders.created_at)
}
]
}
]
}

PopInteraction

interactions: [
PopInteraction {
from: 'p_period_comparison'
to: [
CustomMapping {
block: 'v1'
field: r(public_users.created_at)
}
]
}
]

CustomMapping

CustomMapping wraps a target block for FilterInteraction, DateDrillInteraction, or PopInteraction under the legacy interactions key.

ParameterDescription
blockName of the target block (as a string), or a list of block names to apply the same mapping to multiple blocks at once.
fieldReference to the affected field, using r(model.field) syntax.

Open Markdown
Let us know what you think about this document :)