Dimension Patterns

Dimension Pattern 1

When building dimensions, there is one pattern that exists more than any other.

You want to build a Dimension for a business context where there is tagging in place to drive the elements.
Because tagging represents user generated content, you need to do some cleanup of the values
You’d like to improve the dimension coverage for the non-tagged resources

From a practical perspective, this involves building your dimension in 3 sections. Because CostFormation represents sequential, conditional logic, the order is important:

  My_Dimension:
    Name: My Dimension
    Rules:
      #--------------------------------------------
      # Section 1 - Override / Cleanup Logic
      # Will usually use Group or Metadata type rules
      #--------------------------------------------
      - CostFormation Here
      
      #--------------------------------------------
      # Section 2 - Default Logic
      # Will usually use GroupBy sourcing from customers tags
      #--------------------------------------------
      - CostFormation Here
      
      #--------------------------------------------
      # Section 3 - Manual Logic
      # Will usually use Group or Metadata type rules
      #--------------------------------------------
      - CostFormation Here

Dimension Pattern 2 - Here is a related, slightly more complex, pattern:

You want to build a Dimension for a business context where there is tagging in place to drive the elements.
There are a handful of accounts that that belong to the different elements regardless of the tag value(s).
Because tagging represents user generated content, you need to do some cleanup of the values
You’d like to improve the dimension coverage for the non-tagged resources

  My_Dimension:
    Name: My Dimension
    Rules:
      #--------------------------------------------
      # Section 1 - Account Mapping Logic
      # Must come first if we want this logic to override any tagging
      #--------------------------------------------
      - Type: Group
        Name: Element A
        Conditions:
          - Source: Account
            Equals: 123456789012
      - Type: Group
        Name: Element B
        Conditions:
          - Source: Account
            Equals: 210987654321          
      
      #--------------------------------------------
      # Section 2 - Override / Cleanup Logic
      # Will usually use Group or Metadata type rules
      #--------------------------------------------
      - CostFormation Here
      
      #--------------------------------------------
      # Section 3 - Default Logic
      # Will usually use GroupBy sourcing from customer's tags
      #--------------------------------------------
      - CostFormation Here
      
      #--------------------------------------------
      # Section 4 - Manual Logic
      # Will usually use Group or Metadata type rules
      #--------------------------------------------
      - CostFormation Here

This pattern is identical to the first pattern except that there are certain accounts that should get entirely mapped to a specific element. This logic must come first since we want everything in that account to go to the element.