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. "firstname.lastname@example.org" won't ever match to "email@example.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).
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.