After instance upgrade to Paris release templates that used to set certain values to fields on a form no longer work. When it's applied the value won't either be set or will revert back to the previous value already set on the record (or value is cleared out altogether).
When the template is applied it'd throw a conflict error such as:
<name of template> applied with 1 conflict
Unable to update field "State"
This is normally observed for dependency fields but can be seen with standalone/non-dependency field like 'state' as well.
An example of dependency fields being affected:
- Assume "iPad" is subcategory of the "Hardware" category
- If the template is setup where it'll auto-populate "iPad" as the subcategory but the category is set to "Software" instead this will not work. The subcategory value will be cleared out. This is because "iPad" is not a proper subcategory of "Software" category.
Likewise for non-dependency fields (i.e. state, type, etc.) if a field choice has been removed or made not available to the user through some methods (i.e. client script) but the template is applying that choice the same exact behavior would occur as well.
Both of these scenarios are considered improper mapping.
Prior to Paris this behavior was "allowed" but has now been "fixed" per PRB1341943. Therefore, this is now considered fixed or "corrected" starting in Paris.
1) On a Paris instance navigate to an incident form and check Category and Subcategory fields values.
2) Make sure that there are some Subcategory values (i.e. Mouse, Monitor) for "Hardware" Category.
3) Now create a template for incident table where Category is set to "Software" and Subcategory is set to "Mouse"
4) Back to the incident form apply this template
5) See now that the Subcategory fied will NOT apply and the following error can be seen on top of the form:
<name of template> Applied with 1 conflict
Unable to update field"Subcategory"
*This is because "Mouse" Subcategory is not a valid dependency value of "Software" Category.
This is considered working as expected. Please see the following known error article on the fix that triggers this behavior starting in Paris:
However, there are two options to consider moving forward to avoid running into this behavior:
1) Ensure that when a template has been setup to apply certain values for dependency fields that the choice mappings are proper.
And if it's for non-dependency fields that those same values are available to the users upon form/record load.
2) Revert this to a "less strict" behavior as seen in releases prior to Paris by updating the following system property to value false:
*For dependency fields the improper value would still not be set (it'd be left empty) but the template won't throw the error anymore.
*For non-dependency fields the improper value would get set and the template won't throw the error. However, users who don't have access to the choice/value set would still not see it on the form (backend value would be set correctly).