Creating a formula field is mostly a question of writing the formula expression correctly and choosing the right return type up front. The wizard walks you through each choice, but the gotchas show up when the formula compiles too large, the relationship traversal hits a null, or the formula needs to filter on a report and the index does not exist. Build in a sandbox and test against edge cases before pushing.
- Confirm the value should never be stored
Ask whether the value needs to reflect the current state of the record at all times, or whether it should be stamped at a moment in time. If it changes with other fields, a formula fits. If it should preserve a historical value (like the price at order creation), use a stored field updated by automation instead.
- Pick the return type carefully
Object Manager, target object, Fields and Relationships, New, Formula. Choose the return type: Number, Currency, Percent, Date, Date/Time, Checkbox, Text, or Picklist. The return type is permanent, and changing it later forces you to recreate the field. Picklist formulas are limited to the picklist values defined on a related field.
- Write the formula using the editor
Use the Advanced Formula tab for anything beyond a simple field reference. Use Insert Field to navigate relationships safely, and Insert Operator/Function for the right syntax. Wrap relationship references through lookups in BLANKVALUE or NULLVALUE to handle missing records.
- Check syntax and formula size
Click Check Syntax to validate the expression compiles. Click Show Formula Size to see how close you are to the 5,000-byte compiled limit. If you are above 3,500 bytes, plan to refactor before it stops compiling.
- Set blank-field handling and decimal places
For numeric formulas, choose whether blank fields are treated as zero or as blanks. Treating as blanks is safer for division operations because it returns blank instead of producing a division-by-zero error. Set decimal places to match the business expectation, especially for currency.
- Configure field-level security and page layout
Set FLS per profile or permission set. Add the field to the page layout in a section that matches the user journey. Formulas display in reports and list views as read-only, so confirm that the position works for the report and dashboard consumers too.
- Test edge cases across the data
Spot-check records where the input fields are blank, where the related record is missing, where dates are very old or in the future, and where text fields contain special characters. Formulas often misbehave at the edges, and catching those in sandbox saves a production incident.
Label shows in the UI. API Name is permanent and used by Apex, formulas in other fields, and integrations.
Number, Currency, Percent, Date, Date/Time, Checkbox, Text, or Picklist. Cannot be changed after creation.
The expression itself. Must be valid syntax, compile under 5,000 bytes, and use functions allowed for the return type.
- Formula compiled size cannot exceed 5,000 bytes, and the limit counts referenced formulas too. Nested formulas can hit the ceiling fast, so refactor with helper fields before it blocks deployment.
- Text formula fields above 254 characters cannot be filtered in SOQL or report criteria. Plan around this when the formula output is going to drive segmentation logic downstream.
- Filtering reports on a formula field across millions of records forces a full table scan because formulas are not indexed. Use a stored field with automation instead for that use case.
- Cross-object formulas through lookup relationships return blank when the related record is missing. Wrap with BLANKVALUE or NULLVALUE to give the formula a safe default and avoid downstream nulls.
- Return type and many other field attributes are permanent. Plan the field design carefully because changing later means recreating the field and updating every reference manually.