Cross Object Workflow in Salesforce.com

For the last few years one of the most popular ideas on the Salesforce.com Ideas Exchange has been cross object workflow. In Spring ‘12 the idea was finally marked as “Delivered in Spring ‘12”. In its simplest form cross object workflow can be described as when a field or event happens on one object, allow me to change something on a related object. Prior to cross object workflow being available, admins and developers would have two choices when tasked with coming up with a solution for this problem. They could either write a trigger to handle the cross object rule or they could train their users to change data in two places. For the typical admin neither of these scenarios were all that enticing.

Simple Use Case

One of the best and simplest examples of where cross object workflow can be used effectively is the relationship between an Account and their Opportunities. In the Arkus Salesforce org we have a trigger that executes when an Opportunity goes into a Closed-Won stage. When this event happens the related Account Type changes from Prospect (or whatever type it was previously) to Client. We did this trigger because there was no other way to solve for this problem prior to Spring ‘12 and we are very diligent about data cleanliness. We often times found that once an Opportunity went to Closed-Won the Account would still say Prospect which through off some of our reporting, therefore we wrote a trigger. This same use case can now be solved with a declarative workflow rule. Let’s walk through the steps to reproduce this scenario.

The Workflow Rule

• Create a new workflow rule that fires on the Opportunity object.
• In the Evaluation Criteria select “When a record is created, or when a record is edited and did not previously meet the rule criteria”.
• In the Rule Criteria select Opportunity: Won equals True.
  

It’s that simple - just evaluate every time an Opportunity is saved whether or not the Opportunity is Won.

The Field Update

• Create a new Field Update workflow action.
• Select a field to update - in this case we are updating the Account object’s Type field to be set to “Customer”.

Again, this is really simple. All you have to do is make sure you are selecting the correct Object to update and select the specific value that you want to update that field to.

The Results

As seen in the following screenshots of the Arkus Account in this org the Type field is updated from Prospect to Customer once the “Big Opportunity” moves from “Prospecting” to “Closed Won”. 

The Before: 

The After:

This is a really simple yet powerful example of what cross object workflows can do in the hands of a capable administrator. This type of powerful cross object data manipulation was once handled by developers with the skills to write triggers, now admins can point and click to save their end-users time and alleviate data quality issues before they arise. 

If you would like to discuss cross object workflow rules in more detail feel free to ping me on Twitter at www.twitter.com/justedelstein.