Automated actions

When a workflow rule’s criteria is matched, the related actions (called automated actions) are executed: they can be built and reused whenever necessary, meaning that more than one workflow can trigger the same actions.

Workflows can use the following actions:

• Field update
• Task creation
• Email alert
• Outbound message

All these actions can be used on the approval and entitlement processes as well. Only email alerts can be used in flows and the Lightning Process Builder.

We’ll see them in the following sections.

Field updates

Field update action is self-explanatory: it can be used to update a field of the target object of the workflow (and even other related objects, as we’ll see shortly).

Let’s say that our company mostly sell to Italian customers with an high annual revenue, so if a lead comes from Italy and the web source and the annual revenue is up to $100,000, it should automatically be promoted to a Hot rating. This is a valid configuration for the example field update:

Field update configuration

Besides the usual name and unique name system fields, the object type is already filled in (Lead) and the Field to Update box has to be filled in with the chosen field, Rating in our example.

Being a picklist value, you can select listed values only (you cannot set unlisted values with a field update action); you can even tell the action to choose the previous value or the next value in the picklist, given the current value.

This means that if the lead is created with a Warm rating value, the system can autonomously choose the previous/above value (Hot) or the next/below value (Cold); this is valid for picklist fields only.

The Re-evaluate Workflow Rules after Field Change option allows another workflow rule evaluation (meaning any lead workflow and not only the current one) if this field update actually changes the source lead field (no workflow is further evaluated if the lead is created with the Hot rating, in this example)—this is needed if we have a special behavior related to the rating field (there may be other workflows on the rating field, after all).

If the target field is not a picklist (for example, a text field), you can select to put a blank value or use a formula field to calculate a value; in the following example, we’ll be using the Description field to concatenate some critical fields in a readable format:

Field update with formula

In this example, we don’t want the workflow to be re-evaluated (it’s just a description field); the formula is used to create a description such as “This is a lead with an annual revenue of 100,000 and a rating set to Warm.”

Once the following field updates have been created and associated with the workflow, activate it by using the Activate button:

Activated workflow rule with two field update actions

Let’s now create a new lead with the following values:

• Lead Source: Web
• Annual Revenue: 1,000,000
• Lead Status: Open – Not Contacted
• Rating: Hot
• Country: Italy

The following picture shows the new lead:

Workflow rule applied to a new lead

The rating field has been updated to Hot, and the description is filled in with a readable description with a concatenation of the most important key fields.

With field updates, it is also possible to select a new record owner by selecting the owner field, a user, or a queue (if a queue is available for the target object) and even notify the new owner (via email) of the new ownership, as shown in this screenshot:

Owner field update

This can be an alternative way to assign records (remember that the lead object has its own assignment rules, along with the case object).

Remember the following peculiarities of field updates:

• Field updates are executed before email alerts, tasks, and outbound messages, but after case/lead assignment and auto-response rules.
• Field-level security is not enforced (they can update any field, even if current users don’t have access).
• Field updates are shown on debug logs.
• If field history tracking is enabled and field update actions are executed on tracked fields, they’ll be displayed on the history related list.
• Validation rules are executed before workflow execution, so it is possible to update a field, making its object inconsistent with its validation rules.
• A field that can be set to blank (null) by a field update cannot be set as required.