What are the real usage of entity definition relationships and field definition relationships in custom metadata types?

Question

The trailhead here Configure your apps with custom metadata types proposes the following scenario:

• A custom medata type named Support Tier with 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:

1. 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?
2. 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?
3. 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?

Answer 1

A real world use case: I am currently working on a package that allows us to declaratively configure a RESTful architecture parallel to the salesforce standard REST API via Apex REST. This gives us much more control than the Standard REST API over ...

• Setting up resources (defining the path/sub-directory, configure allowed expansions of sub-resources and parent resources and configuring filters)
• Setting up representations (defining the exposed fields of this representations, using different naming conventions for fields (i_like_snake_case) that are independent of the salesforce scheme, exposing only particular relationships (parent/child), and so on)
• Configuring individual representations for each HTTP-Verb (GET,POST,PATCH,etc) per Request/Response (say, you expect only 3 mandatory fields for a POST Request, but you always want to render all 15 mapped fields in a Response to this POST and use a completely different representation in a Response to a GET)

All of this functionality is fully generic, and I implemented this by making extensive use of Custom Metadata Types. To summarize:

• The key Metadata Objects are Resources, Representations and Representation Properties
• A representation maps to a certain SObject, so there is a custom field on the metadata type "SObject__c" of the type Entity Definition where you define a particular SObject (that will be used to dynamically generate the SOQL-Query string)
• Representation has a related list of Properties, where we configure all the properties (meaning "keys" of the rendered json): In a Property, I essentially define a field mappings: The external name (i.e email) and with a Field Definition field, the salesforce field (ArbitraryBusiness_Email__c) that will be used to retrieve/store the data.

All SOQL queries to retrieve the records (during GET calls) and DML to perform more complex operations (especially PATCH and POST) is generated dynamically, fully generic during runtime based on the meta data records.

Answer 2

In terms of your questions at the end:

1. No, there's nothing clever here, unfortunately. Relationships to picklist values was something that we planned to support, but we don't have it and it isn't on the immediate roadmap.
2. There are a number of reasons why we make you specify an Entity definition before you can specify a Field definition, but the simplest one is that populating a single dropdown list with every field in an organization would be impractical, given that standard fields and entities are included (it's not hard for an organization to have well over a million field definitions across all entities). And it would be even worse unless we used "Entity.Field" format, because, e.g., thousands of entities could all have a field called "Name".
3. I'll let other customers and partners answer this one, as J. Lietzau has already done.