The trailhead here Configure your apps with custom metadata types proposes the following scenario:
- A custom medata type named
Support Tierwith default discount and
minimum spending(Create and Manage Custom Metadata Types)
- An Account object with a Total Spending, rolling up Amount on opportunities and formulas to determine with a set of if statements what is the right support tier (Use Custom Metadata Types in Formulas, Default Values, and Validation Rules
- A flow to update a Picklist on the account when the Total Spending reaches the next Minimum Spending (Use Custom Metadata Types in Flows)
Later, in the Programmatic Development with Custom Metadata Types and in particular in Use Metadata Relationship fields, the approach suggested in the previous module is questioned because using a picklist and assuming its allowed values matches the instances of the custom metadata is brittle and probably also the formula Amount Until Next Tier would exceed the maximum formula length if the number of tiers grows.
Therefore a more complicated scenario is introduced: an org with multiple "Support product": Email Support, Online Chat and Dedicate Phone Live. Such supports products are modelled through an SObject with a Picklist named "Support Level" with values "Free", "Premium" and "VIP":
- Email Support : Free
- Online Chat : Premium
- Dedicated Phone Live : VIP
It then suggests that the right pattern to handle this more complex situation would be to introduce one additional custom metadata "Support Mapping" which has:
- one entity definition relationship
- one field definition relationship
- one metadata relationship towards the Support Tier
Then the trailhead suggests to create an instance of this new metadata type like so:
- The Entity Definition Relationship is set to Support Product
- The Field Definition Relationship is set to Support Level
- The Support Tier Relationship towards the Support Tier instances named Bronze (Discount 0%, Minimum Spending 0)]
- The Support Tier Name is set to 'Free'
It then concludes with:
Now the relationships can be used within your Apex code to provide an even more enhanced user experience for Acme Services.
The following questions arise after completing this trailhead:
- Is there anything smart and clever that is mapping "Support Tier Name" against the instances of the picklist "Support Level"? Or is just "text fields having the same name" and you would have to perform SOQL query in Apex and interpret those?
- Why would you want to use an Entity Definition Relationship and a Field Definition Relationship if you are always setting them towards the same SObject and the same field?
- If the 1 first question is NO, what are real use cases for Entity Definitition Relationships / Field Definition Relationships besides the one that Andrew Fawcett shows in Declarative Lookup Rollup Summary?