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

By

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

New Metadata Relationship

Related to: relationship to entity definition

integration field new relationship

Field label: “Object Name”

Field 1 completed screenshot:

field one completed screenshot

Field 2

Field type: metadata relationship

Related to: field definition

Field Definition screen

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.

Controlling Field

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:

Custom Metadata Type Definition

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.

Integration Field

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!

Deletion Error Message

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.

Where the Field Is Used

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

Introducing Invocable Composer Flows.

Introducing Invocable Composer Flows: Automate End-to-End Across All of Salesforce

What are Invocable Composer Flows? MuleSoft Composer is an integration tool designed for admins, business analysts, marketers, salespeople, and team leaders. Using Composer, you can quickly and easily build flows to integrate systems and data and automate integration tasks. It’s a no-code tool you can use to build automations with only clicks. To further supercharge […]

READ MORE
Max the mule standing next to text that says, "How to Configure Error Handling in MuleSoft Composer."

How to Configure Error Handling in MuleSoft Composer

MuleSoft Composer is the fastest and easiest way to connect apps and data for business teams, in partnership with IT. With the long-awaited error handling feature that Muleys are excited about, you can build more robust and resilient automation. You can further automate your flows, get real-time notifications on failures, mark failed records for reprocessing, […]

READ MORE
Cloudy standing near a cliff and text that says, "Easy Integrations with Flow HTTP Callouts."

Integrations Are Easier Than Ever with Flow HTTP Callouts

Are you tired of waiting for IT resources to build out an integration to your supplier? Are you frustrated that your payroll system lacks reliable application programming interface (API) documentation, leaving your IT team to weed through JSON and just hoping it’ll work? Then Flow HTTP Callout is for you! This feature does the hard […]

READ MORE