Guest Post:  Phil is a Senior Business Analyst at EDL Consulting, a Salesforce.com Professional Services partner. He is a frequent contributor to Salesforce Developers and author of the forthcoming book Practical Salesforce.com Development Without Code (Apress Media).

Based on my personal experience, I would say that the Field Update action is undoubtedly the most commonly utilized Workflow Action type within the world of Salesforce.com Workflow Rules. From a development perspective, there is a significant amount to gain by learning as much as possible about this type of action. A Field Update allows you to automatically modify a newly created record or an existing record based on the state of the record data and the criteria that you’ve configured within your Workflow Rule criteria.

Workflow Rule Field Updates

Figure 1. The Workflow & Approvals Setup menu section

Here’s an example of a basic Workflow Rule and corresponding Field Update:

Figure 2. The Lead Status field is updated automatically via a Field Update within a Workflow Rule.

Here’s an example with a different result:

Workflow Rule behavior

Figure 3. In this example, the criteria was partially met upon creation (Status = “New”), but failed to trigger the Workflow Action because the formula excludes new records: NOT(ISNEW()).

Selection of Object

You may notice above that Object selection is shown as part of the Field Update details and may wonder why that is present, since we have created this Workflow Rule for the Lead object. That is because the object used for the invocation of the Workflow Rule may differ from the object used for the corresponding action.  When building a Workflow Rule for the Lead object, you must select the Lead object for the corresponding; however, for other objects, you may have a choice here. For example, take a look at what is possible when you create a Workflow Rule for the Case Comment object:

 Figure 4. Depending on the object you are using and the relationship fields that exist on it, you may be able to update multiple records within one Workflow Rule.

Not only can you have multiple Workflow Actions occur based on the same update, you can actually update two different objects: Case Comment and Case. As you would expect, this is only available on objects that have eligible relationships with other objects. Specifically, the “base” object must have a specific relationship with the object that corresponds to the action. If a standard object is your base object, you may be able to use certain other Standard objects for the action  (see below). If a custom object is your base object, only objects to which your base object is related via a Master-Detail relationship are available. This functionality is referred to as “Cross-Object Workflow” and can be extremely powerful in automating your business. Cross-object workflows are available for the following object relationships:

  • Case Comment –> Case
  • Opportunity Product –> Opportunity
  • Opportunity –> Account
  • Custom Object –> Any Master Object (via Master-Detail Relationship)

Since you cannot create a Master-Detail relationship on a standard object, you will not be able to use a Workflow Rule on a standard object to update a field that resides on a Custom object.

Selection of Field

Once you have selected the Action Object in your Field Update, you will select the field that you want to modify. There are a few limitations that should be considered. First, you can only update fields that are editable; you would not be able to update a Formula Field, for example. Second, a Workflow Rule trumps object and field-level security settings. In other words, a Workflow Rule configured to update Field B based on a change to Field A will not be prevented if the acting user does not have the ability to directly edit Field B. Likewise, a Read-Only setting on a page layout for a particular field will not prevent a Workflow Rule from updating that field if that page layout is invoked.

Configuration of Field Value

This is where things get very interesting. In the examples above, I used simple scenarios to show how a Field Update could be used to change the Status field on the Lead object from “New” to “Disqualified” or “Working”. In those Cases, I would set one of the picklist values as the value for the Field Update and be done. As you previously learned, there are numerous field types in Salesforce.com; each of these has its own particular behavior when it comes to Field Updates.

Table 1. Field update options differ by Field Type; this table shows the options for each Field Type.

Re-evaluate Workflow Rules

Selecting the “Re-evaluate Workflow Rules after Field Change” will cause Salesforce.com to re-evaluate your Workflow Rules. You will want to check this if one of your Workflow Rules is dependent on a Workflow Action from another Workflow Rule. In that scenario, leaving this field unchecked will prevent the dependent Workflow Rule from meeting the configured criteria.

Figure 5. Although it may seem like creating an endless loop is very simple with Workflow Rules, Salesforce.com has built-in protection against it. Workflow Rules can be re-evaluated only one additional time based on the original event or action.

Additional Thoughts on Field Updates

As you take in the plethora of information related to Workflow Rules, it may be a challenge to see how powerful the above options really are. The fact that you can use a formula to set a number of the above field types gives you extreme flexibility in your business process automation and you don’t need a line of code to make it happen. Think about this – you can determine if an automated action occurs based on the state of your record and then you can configure a dynamic update based on a formula. You may have already seen what formulas can do; you can pull from other fields or even other objects and you can return a value based on a defined condition. Put this all together and you can do quite a bit in your Field Update.

About the Author

Phil lives in the Greater Atlanta Area and is a Senior Business Analyst at EDL Consulting, a Salesforce.com Professional Services partner. Phil is the author of the forthcoming book Practical Salesforce.com Development Without Code (Apress Media). Follow Phil on LinkedIn or Twitter.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS