3

Which is the best possible way to check if a custom object or custom settings is used anywhere in the project?

We are doing a cleanup task of deleting custom objects/custom settings.

8

What you're looking for is this feature (dependency API), but it's not available publicly yet. For now, the only sane way to do a check is to use a metadata deployment with a "check-only" option to avoid doing an actual delete.

To do this easily, I'd recommend using sfdx, but you could also choose to use the workbench if you wanted to avoid installing anything.

Here's my SFDX version.

Step 1: Create a folder somewhere.

Step 2: Place a new file in there called package.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <version>43.0</version>
</Package>

Step 3: Place a new file in there called destructiveChanges.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>CustomObject__c</members>
        <name>CustomObject</name>
    </types>
    <version>43.0</version>
</Package>

Step 4: Deploy the changes with the "check-only" flag:

sfdx force:mdapi:deploy -c -d src -u sfdcfox -w -1

Where:

  • -c: Check only. Does not commit changes.
  • -d src: The folder that has the files we created.
  • -u sfdcfox: The username or alias to deploy to.
  • -w -1: Wait indefinitely for a result.

If it's safe to delete, you'll get a message like this:

=== Result
Status:  Succeeded
jobid:  ------------------
Completed:  -------------------------
Component errors:  0
Components checked:  1
Components total:  1
Tests errors:  0
Tests completed:  0
Tests total:  0
Check only: true

If it fails, you'll get a message like this:

=== Result
Status:  Failed
jobid:  ---------------------
Completed:  --------------------------
Component errors:  1
Components checked:  0
Components total:  1
Tests errors:  0
Tests completed:  0
Tests total:  0
Check only: true

=== Component Failures [1]
TYPE   FILE                                NAME              PROBLEM
─────  ──────────────────────────────────  ────────────────  ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Error  src/objects/CustomObject__c.object  CustomObject__c   Your attempt to delete Blog Entry could not be completed because it is associated with the following relationships with other objects.: ------

ERROR:  The metadata deploy operation failed.

Custom Objects, Custom Metadata, and Custom Settings all use the CustomObject metadata type. You can list as many as you like in the file, and each can independently succeed/fail.

1

If you have a sandbox, a practical approach would be deleting an object and if it is used anywhere, the system would not allow the deletion listing all the references where it is used. You can do this even in a Production org. When you click Delete, Salesforce performs a soft delete which means it is not deleted yet so you can easily restore the deleted object. Be aware of some implications though, like some links might be lost, I recommend reading this article for more detail Delete Custom Objects.

As another approach, my guess would be to make use of Metadata API to programatically retrieve that info.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.