Skip to main content
For example, you can use this parameter to:
  • Create aliases for joins between tables in the topic. When aliasing a join for a specific topic, often topic-specific relationships are the best way to model, field names may also be adjusted or renamed or relabeled (see above).
  • Define topic-specific drilling
  • Define topic-specific aggregate awareness

​
Syntax

views:
  <view_name>:
    <property>: <value>

​
Properties

​
views
object
A map of view configurations, where each key is a view name and the value is an object containing topic-specific customizations for that view. Common properties include display_order, extends, dimensions, and measures.

​
Examples

Defines the order in which views in the topic display
views:
  order_items:
    display_order: 1
  users:
    display_order: 2
  products:
    display_order: 3
The following example customizes the opp_line_item_daily_facts view to analyze metrics at different points in a contract’s lifecycle (start, now, end). Custom, context-specific names are applied to the drr_sum and arr_sum measures to analyze the metric at each point in the life cycle. For example, Starting ARR and Current ARR. Then, topic-specific joins are used to apply different dates - such as a contract start or end date - and create views specific to each point of the contract lifecycle. 
views:
  # First extension; focuses on contract start
  opp_line_item_start_facts:
    extends: [ opp_line_item_daily_facts ]
    dimensions:
      drr_sum:
        label: Starting DRR      # Topic-specific name for the drr_sum base metric
      arr_sum:
        label: Starting ARR      # Topic-specific name for the arr_sum base metric
    measures:                    # Creates a Starting ARR Sum measure
      arr_sum_sum:
        sql: ${opp_line_item_start_facts.arr_sum}
        label: Starting ARR Sum
        aggregate_type: sum

  # Second extension; focuses on current contract state
  opp_line_item_current_facts:
    extends: [ opp_line_item_daily_facts ]
    dimensions:
      drr_sum:
        label: Current DRR
      arr_sum:
        label: Current ARR
    measures:
      arr_sum_sum:
        sql: ${opp_line_item_current_facts.arr_sum}
        label: Current ARR Sum
        aggregate_type: sum

# Third extension; focuses on contract end
  opp_line_item_end_facts:
    extends: [ opp_line_item_daily_facts ]
    dimensions:
      drr_sum:
        label: Ending DRR
      arr_sum:
        label: Ending ARR
    measures:
      arr_sum_sum:
        sql: ${opp_line_item_end_facts.arr_sum}
        label: Ending ARR Sum
        format: USDCURRENCY_0
        aggregate_type: sum

### Topic-specific joins of the same fact table but with different dates
### to understand ARR at different points of the contract lifecycle (start, now, end)
relationships:
  - join_from_view: opp_line_item_facts
    join_to_view: opp_line_item_start_facts
    join_type: always_left
    on_sql: ${salesforce__opportunity.id} = ${opp_line_item_start_facts.opp_id} AND
      ${opp_line_item_start_facts.date} =
      ${opp_line_item_facts.oli_first_date}
    relationship_type: one_to_one
  - join_from_view: opp_line_item_facts
    join_to_view: opp_line_item_end_facts
    join_type: always_left
    on_sql: ${salesforce__opportunity.id} = ${opp_line_item_end_facts.opp_id} AND
      DATEADD(day, 1, ${opp_line_item_end_facts.date}) =
      ${opp_line_item_facts.oli_last_date}
    relationship_type: one_to_one
  - join_from_view: opp_line_item_facts
    join_to_view: opp_line_item_current_facts
    join_type: always_left
    on_sql: ${salesforce__opportunity.id} = ${opp_line_item_current_facts.opp_id}
      AND ${opp_line_item_current_facts.date[date]} = CURRENT_DATE()
    relationship_type: one_to_one