There are some discrepancies in the UX and/or the underlying mechanisms of how field mappings are applied in different use cases. Those can be grouped as follows.
- When a Referral is created manually or bulk-created. The settings from the Field Mapping tab are applied via coded logic. This is uncustomizable and you can’t do anything on top of it, except change the field values after the defaults have been applied.
- When a Referral is auto-created using Flow. In the seeded template (if you choose to activate it at all), the settings from the Field Mapping tab are also applied in this case using the same code. But since it happens in the Flow, you are free to customize pretty much everything and thus:
- Ignore the package’s coded logic by removing the 'Populate Referral from Mappings' Apex Action element from the Flow.
- Override the package’s coded logic by setting some field values after the 'Populate Referral from Mappings' Apex Action element in the Flow.
- Add more logic and functionality, e.g. concatenate some field values into another field, or build conditional logic where the default value depends on some other field value, etc.
- When a Referral is linked to an existing Opportunity. The settings from the Field Mapping tab are applied via code, although a set of hardcoded fields are skipped. This is uncustomizable and the customers can’t do anything on top of it.
The field mappings also used to be applied when an Opportunity is created from a Referral. However, starting with the settings from the Field Mapping tab will be ignored, and OOTB everything will be happening in the Flow, where you are free to customize pretty much everything, adding more logic and functionality (same as p.2).