Formula fields

A formula field is like a real-time calculation that is calculated when it is loaded or requested. It's like a formula in an Excel spreadsheet. We refer to it as loaded or requested, because it's not a calculation that appears while viewing a record in the user interface. When you request the record data, it is calculated (or recalculated) using the following methods:

• By viewing it in the UI or in a report
• By exporting the data through a data loader
• By reading the data through an API call
• By querying the data in a SOQL query

A formula field is always read-only. This means that it's not a field in which you can type or change it's value manually – it is always calculated. As a result of this, the calculation does not perform an update on the record and this can never trigger any automations. What I mean here is that you can't have something like a WFR that updates a field when that field changes without performing a manual update or other automation update of the record. You can, however, use the value of a formula field in your automation processes as a criterion or to use as a value.

I know this is somewhat confusing, so let's try to explain it using an example. Let's say that we create a formula field returning a date that is calculated, based on the creation date of a record plus 30 days, and we would like to create a task for the owner when we reach that date automatically. You could be tempted to create a Process Builder that evaluates whether TODAY() equals the date field. If it does, then create the task and, as long as that date is not equal, it's still either in the future or already past.

Now, if the record does not get updated by someone manually, or by some other automation, then nobody will touch this record and this Process Builder won't fire—this is because all automations only fire on the creation or updating of records.

Additionally, a formula field is calculated in real time when it gets requested and does not perform an update of the record. You can use your own logic in order to build the calculation that it needs to perform, and Salesforce offers a lot of functions for you to use within your formulas.

For instance, I really like the Formula Cheatsheet Salesforce that contains the most used functions. You can find it at https://resources.docs.salesforce.com/rel1/doc/en-us/static/pdf/SF_Formulas_Developer_cheatsheet_web.pdf.

A formula field can return the following things:

• Checkbox
• Currency
• Date
• Datetime 
• Time
• Number
• Percent
• Text

Formulas usually perform calculations with other values in the record that it resides on, but it can also use the values of parent records, or grandparent records, up to 10 levels up. However, it cannot use the values of child records. So, a common use case for a formula field is to display data from its parent. For example, let's say that we have a custom Picklist field, Region__c, on the account page and we would like to show this value on our opportunities page. Because an opportunity is directly linked to an account, we could create a formula field that renders the text using the formula TEXT (Account.Region__c).

Because a formula is always calculated in real time, this value will always represent the actual value from the Region__c field of the account on our opportunity, without manually updating all opportunities of this account whenever the Region__c field changes on the account.

A formula field that uses data from its parent, or higher up the hierarchy, is called a cross-object formula. Formulas do have some limitations that you need to be aware of; for example, you will get an error message if your formula does not comply with the following limits:

• The maximum number of characters is 3,900.
• The maximum formula size on saved is 4,000 bytes.

When your formula exceeds either of the aforementioned characters or byte limits, then you will receive an error message mentioning this.