Hello ,
Any best practices around how do we manage objects which are not required anymore ?
Specially when those objects have been previously deployed to production.
Is it a best practice to delete such objects ? If this could be an option , then such objects could be easily deleted in the development environment but then how do we promote the deletion to high environments ?
Or someone will have to manually delete them in the high environments ?
Thank you.
Discussion posts and replies are publicly visible
Echoing the others slightly, my procedure (personally) is something like:
1) mark as "deprecated" in the description, including the rule/interface name that designers should use instead (if any)2) procedurally remove the deprecated object from in-use objects, either slowly or quickly depending on the urgency3) only after it's been removed from all dependents, rename with "DEP_" or "DEPRECATED_" prefix (per your preference), and MOVE TO A FOLDER dedicated to deprecated objects note: i usually use the prefix "zDEP_" or similar, so the deprecated objects don't show up on the auto-complete picker higher than the actual objects i'm searcing for.4) deploy any newly-deprecated objects to higher environments5) optionally, you can delete fully-deprecated objects - I almost always take a BACKUP EXPORT first (perhaps from a separate app named "deleted objects backup export" or thereabouts), for the 'archives'. I would do this for one object at a time (or a small handfull if they're related somehow and have all been fully deprecated). Then they can be individually deleted (directly from the individual environments), making sure to match them object-per-object. For safety reasons it might be good to deploy the current contents of the "deleted items" app package to the target environments first, so that it would populate the exact items to delete, to avoid accidental deletions of similar-named objects etc.
Note: I often don't bother proceeding to step 5 - there's very little risk in allowing deprecated objects to sit around.