How I Solved This: Protecting Fields Used in Integrations from Deletion

Watch Gorav walk through his innovative solution in the new, “How I Solved This” video series and read all the details in the post below.

Key business problem

Being an Awesome Admin is sometimes about the things you don’t do, like not breaking integrations. Not breaking integrations becomes much easier if you have a process to document the fields that are used by integrations, as well as some tooling that not only makes it easy to track this but also prevents the deletion of fields that are marked as integrated.

Background

Integrations can be critical to effective Salesforce implementations, and Salesforce provides a range of low-code and high-code tools that can be tailored to your needs. Regardless of the approach you use to build an integration, tracking which fields are used in order to protect them from deletion or modification is critical for long-term stability and reliability. Deleting a field, or sometimes even just modifying it, can cause a wide range of issues — and this is doubly true when dealing with integrations. Luke Cushanick recently shared some thoughts on looking for approaches to better protect orgs from this.

There are some great apps out there that help with impact assessment and tracking, and others that are very powerful for managing documentation. But, to my knowledge, none of these actually prevent you from deleting a field.

After some discussion, we settled on the approach of using a custom metadata type to ‘mark’ fields as ‘integrated.’ It’s quite easy to set up and even easier to use! It does not require any code, has dependent picklists that automagically include (almost) every object and field in your instance, and will block deleting of any field that is ‘marked.’ This info also will be refreshed with sandboxes and scratch orgs, which is important because, as all admins know, you don’t want to develop in production.

How I solved it

I created a new Custom Metadata Type named “Integration Field.”

Then, I added fields to the metadata type to track where and how this field was used. This will cover the internal documentation.

Integration name: text
Description: text area

Next, I added two new metadata relationship fields — this is the magic that will give you a dependent picklist with (almost) all objects and fields in your instance.

Field 1
Field type: metadata relationship

Related to: relationship to entity definition

Field label: “Object Name”

Field 1 completed screenshot:

Field 2

Field type: metadata relationship

Related to: field definition

Field Label: “Field Name”
Controlling Field: “Object Name”

Note: The Controlling Field option will only appear after you create the first relationship field to entity definition.

Next, I set the Controlling Field to the “Object Name” field I just created in the previous step.

When all done, the fields on the custom metadata type should look like this:

Now we are ready to add some ‘records’ to the metadata type, which will track each field that is used.

Click the Manage Integration Fields button at the top of the page, and then click New to add a new record to the metadata type.

Presto! You can see that the magic of the metadata relationship fields gives you a dependent picklist with all object names and all field names in your instance at your disposal.

Add the background info, then select an object in “Object Name” and select a field on that object in “Field Name.” I suggest using a custom field for the demo, since you can then try deleting it and watch this stop you. Then, click Save.

Note: Earlier, I said you can reference almost every object — you cannot reference Activity (task/event) and User fields with metadata relationship fields.

Test it out

Now, go to Setup, then Object Manager, and then to your custom object.

Try to delete the custom field you just mapped. And you shall be blocked!

Notes:

Custom metadata relationship fields cannot reference Activity (tasks or events) or User fields (thanks to Ch. Szandor Knapp for finding this out). Find more Custom Metadata Type Relationship documentation here.

There is a limit of 10 million characters of custom metadata in your org. So write the novella about your integration architecture elsewhere, and link to it from here.

You may want to use the Label of the MDT record to record the integration that the field is used in (instead of a separate integration name field), as the Label is what is displayed in the error message on delete.

Unfortunately, this tooling will not prevent admins from modifying the field in ways that can break your integration, nor will it alert you if the field is modified. However, you will have one place where you can view all your fields used in various integrations. This is a nice, declarative way to protect fields from deletion, and do a little documentation to boot.

To ‘flag’ standard compound fields (like address), I believe you would need to add a metadata relationship to entity particle instead of (or in addition to) field definition, but almost all fields should show up as field definition from what I understand.

If the field is referenced in validation rules, workflow rules, flows, etc., then those issues will be displayed on delete and the MDT will not surface. You may have noticed that the ‘blocked’ example screenshot was a different field from the one I initially flagged. Turns out that Web_Profile__c.Twitter__c is used in validation rules and a flow; therefore, the metadata type reference was not surfaced. Screenshot below.

Business results

I’ve used this approach to protect critical fields used in integrations from accidental deletion. It also includes descriptive information that serves as a reference for tracking how the fields are used.

Relevant Trailhead badges

• Custom Metadata Type Basics
• Apex Integration Services
• External Services