From Excel to package.xml
Cleaning up an org that has gone through several generations of ownership and objectives is fun. Some tooling helps
A computing principle, very much the anathema to Google and Facebook, is Data Frugality, storing only what you actually need. It is the data equivalent to coders' YAGNI principle. Latest since GDPR it got center stage attention.
Your cleanup plan
So your cleanup exercise has a few steps:
- Find fields that don't have any data. You can use tools like Field Trip to achieve that
- Verify that these fields are not "about to be used", but "really obsolete"
- Add all the fields that did have some data left over, but unused now
- Add fields that contain data legal told you to get rid off
The absolute standard approach, of any consultant I have encountered, is to fire up an Excel sheet and track all fields in a list, capture insights in the
remarks column and have another column that indicates
can be deleted Status. Something like
Yes,No,Investigating or "Call Paul to clarify". I would be surprised if there's a different approach in the wild (in theory there are).
Excel as source?
In a current project the consultant neatly created one sheet (that's the page, not the file) per object, labeled with the object name, containing rows for all custom fields. Then the team went off to investigate. In result they identified more than one thousand fields to be deleted.
Now to actually get rid of the fields, you could outsource some manual labor to either go into you org or use Copy-Paste to create a
destructivechanges.xml package file for use with the Salesforce ANT tool.
In any case: the probability that there will be errors in transferring is approximately 100%. The business owner will point to: I signed off that spreadsheet and not that XML file! Finger pointing commencing.
There must be a better way
Posted by Stephan H Wissel on 23 February 2019 | Comments (0) | categories: Salesforce XML