Resolve "Data Owner" User metadata from difference comparisons (always exclude or compare, then exclude)
Salesforce has begun adding User metadata to fields. One good example right now is the "Data Owner" field that appears on all custom fields now (in XML this field is labelled as "BusinessOwnerUser"). The field does not link via a Salesforce ID; it instead displays the Salesforce Username of the user.
Naturally, this field in 99.9% of Salesforce environment comparisons is going to be different. "user@domain.com.sandbox" won't ever match to "user@domain.com" in production-- and it definitely won't ever match to any other Sandbox, either.
This leads to a nightmare scenario where if this field has been populated on any field, that field will always (ALWAYS) show up under "Differences" in any environment comparison. Moreover, if it's included in a deployment by accident, that deployment will fail since the assigned user won't exist on the target environment.
This means that organizations who use fields like this are blocked from executing comparisons based on Custom Fields-- which is a core benefit of Gearset. Yes-- it's technically possible to laboriously review each and every custom field in the differences comparison every time, assessing if there's an 'actual' change or not-- but this is not realistic.
To resolve this, I recommend one or more solutions:
Exclude "User" metadata like this --always-- from all comparisons (or make this an option we can opt in/out of)
Compare the "User" metadata between source & target, and if the prefix to the final suffix is identical, ignore differences. This ensures that as long as you don't edit the User data outside of production environments, you can at the very least keep your User metadata preserved throughout the stack.
Until this is resolved, the only workaround is to 100% ignore using fields such as "Data Owner", because Gearset cannot currently support the type of comparisons with this field effectively. This may not be the best course of action for many businesses (ours included).
We have added a problem analyzer to detect and fix the issue with ‘businessOwnerUser’, as follows.
Problem: custom fields referencing a specific user will fail if that user doesn’t exist in the target.
Solution: this will replace the source ‘businessOwnerUser’ reference with the value from the target’s custom field.
-
Ben Patterson commented
The problem analyzer does work, but even better would be if the difference was ignored all together. :)
-
Troy Hoshor commented
While the problem analyzer recommendation is helpful, it doesn't really resolve the comparison problem. Fields with Data Owners still always shows up in comparisons as changed fields, even if the field or its metadata haven't been modified. This is because the environments continue to have different data values. It pollutes the comparison results.
There should be a way to consider Environment A's value of the field as equal to Environment B's value of the field if, for example, the only difference is the SF sandbox postpended extension.
-
Ryan commented
Been running into this one a lot while copying an old org to a fresh one, it's causing a lot of downloading the package, manually manipulating the metadata then redoing the compare with the package as a source. It's a pain.