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

How I Solved This: Protecting Fields Used in Integrations from Deletion
blow post content copied from  Salesforce Admins
click here to view original post

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.


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


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

I’ve pulled this metadata type into a package that can be installed.

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

The post How I Solved This: Protecting Fields Used in Integrations from Deletion appeared first on Salesforce Admins.

December 21, 2020 at 10:30PM
Click here for more details...

The original post is available in Salesforce Admins by
this post has been published as it is through automation. Automation script brings all the top bloggers post under a single umbrella.
The purpose of this blog, Follow the top Salesforce bloggers and collect all blogs in a single place through automation.