ABSI - far beyond system integration

On 18 March 2015     By Joris Vanbelle      Cloud , Salesforce , Data-Integration , Boomi

The problem

Have you ever encountered a situation where you needed to mass update records in production to correct something, but your data load fails on some records because of validation rules. You resort to disabling the validation rules for the entire org leaving the system open for invalid input.

Have you ever had to integrate an external system or product but encountered integration problems when the system tried to update a record and failed on an unrelated validation rule or a trigger failure.

Every administrator or developer has had these situations when he wanted to temporarily disable the logic that runs behind the scenes. Generally you want to do this to prevent validation errors and increase speed when loading data to Salesforce.

The thing is, it’s not that easy to disable triggers in production or to mass-deactivate validation rules on objects and even if it were, you don’t really want to do that because that logic does need to run for all the other users.

Personalize Automation in Salesforce

There’s a solution for all of this. You can make this as simple or as extensive as you want to.

The solution

You start with creating a hierarchy custom settings object.

Salesforce Custom Setting

I will keep it simple for demonstration purposes. I have 3 check boxes that indicate respectively whether triggers; validation rules or workflow rules should run.

The hierarchy custom setting, unlike the list custom setting, allows you to personalize settings for specific profiles or users. The hierarchy logic checks the organization, profile and user settings for the current user and returns the most specific value. It’s this kind of personalization that we need for this to work.

When you press manage you can first add a default record that will be the setting for everyone and then you can add exceptions below for a specific profile or for a specific user.

Salesforce Default Organization

Here we have our check boxes enabled for all users; my user doesn’t need any record validation and the dedicated user for the Dell Boomi integration platform should be optimized for fast data loads.

This doesn’t work yet. We still need to add these checks to every trigger and every rule that we want to personalize.

Workflow rules

Salesforce Workflow Rule

Validation rules

Salesforce Validation Rule

Triggers


The not (yet) possible

There’s no way to exclude required lookup filters from executing. My advice is that you change to an optional lookup filter and make it required with a validation rule.

There’s also no way to exclude required fields. My advice is to not make them required by field level settings but with a validation rule.

The Spring ‘15 release introduced duplicate prevention rules which allow you to block input when a match is detected. These matching rules are limited to a field-operator-value condition and are thereby limited in the way no custom settings can be referenced. I’ve raised the idea to Salesforce that formula based conditions should also be allowed.

The Spring ‘15 release also introduced the Lightning Process Builder which is a new workflow tool that provides a more easy and a more visual way to automate your business processes.

Unfortunately it’s still lacking some features at the time of writing, but I’m sure it will resolve itself in the future. Until then you’ll not be able to use this solution. I wanted to raise an idea for this but someone beat me to the punch.

Conclusion

I kept the example simple but you can make this as extensive as you want. You can currently use it for workflow rules, validation rules, assignment rules, auto-response rules, visual flows and triggers. There’s no doubt in my mind that in the future it will also be possible to use this for the new process builder and data.com duplicate rules.

You’ll need to add check boxes for types that you want to control seperately.

You could go further and add a distinct check box for the different types of workflow rules, such as email alert, outbound message and field update.

You could go even further and add a distinct custom settings object for each object that you want to control separately. You then add both the main ‘run logic’ and the object ‘run logic’ to your triggers and rules so you can control them with the main custom settings and with the object custom setting.

The possibilities are endless … but they all share the same idea. You create an hierarchical custom settings object so you can set a default organizational configuration and a per user configuration for when triggers or rules should be run.

Personalize your automation!

Joris Vanbelle
Salesforce Developer
Actian DataConnect Developer
Dell Boomi Developer