Salesforce Row-Level Formula Examples for Reports

Salesforce row-level formulas calculate a value separately for each record in a report; useful examples include discount percentage, profit margin, days open, target variance, and overdue status. For instance, a discount formula can be IF(List_Price__c = 0, 0, (List_Price__c - Sale_Price__c) / List_Price__c), returning a decimal that you format as a percentage.

What a Salesforce row-level formula does

A row-level formula adds a calculated column to a Salesforce report. Salesforce evaluates the expression for each report row using fields available from that report’s type, then displays the result alongside the record data. It is useful when you want to compare or transform fields for analysis without adding a permanent formula field to an object.

For example, a sales report can show the difference between an opportunity’s amount and a cost field on the same opportunity. A service report can calculate how many days a case has been open. The calculation is per record: it does not add up every row, compare one row with another, or calculate a group total. Use a summary formula or another reporting feature when the question depends on grouped totals or aggregates.

Row-level formulas are report-level calculations, not saved Salesforce fields. They do not write values back to records, and other records or automations cannot use the calculated result as if it were an object field.

How to add one in Lightning Experience

Open the report in Lightning Experience, choose Edit, and use the report builder. In the Outline pane, under Columns, choose Add Row-Level Formula. Enter a column name and, if useful, a description; select the result format; build the expression using fields available in the report; and check it in the formula editor before saving and running the report. The precise labels or placement can vary with Salesforce interface updates and permissions.

Start with a report type that includes every field needed for the calculation. Add those source fields to the report if the editor does not offer them.
Give the new column a meaningful label, such as “Discount %” or “Days Open.”
Choose the output data type and decimal places that fit the result.
Insert fields from the editor’s field list where possible, rather than guessing their names. Custom fields commonly end in __c, but use the actual field available in your org.
Validate the formula, save the report, and inspect several rows with known values before relying on the column.

These examples use illustrative field names. Replace them with fields available on your report type; a custom field such as Sale_Price__c will not exist in every Salesforce org.

Practical row-level formula examples

Discount amount: Subtract the sale price from the list price. With list price 200 and sale price 160, the result is 40. Set the output to Currency if the values are monetary amounts.

List_Price__c - Sale_Price__c

Discount percentage: Divide the discount by the list price. With the same prices, the result is 0.2, displayed as 20% when the output is formatted as Percent. The zero check prevents a divide-by-zero error; returning zero is a chosen reporting convention, not a claim that a zero-priced item had no discount.

IF(List_Price__c = 0, 0, (List_Price__c - Sale_Price__c) / List_Price__c)

Gross margin percentage: Compare revenue with cost on each record. If Amount is 500 and Cost__c is 320, the result is 0.36, or 36% with percent formatting. This is a row’s margin, not a weighted margin for the whole report; a report-wide margin generally needs total revenue and total cost considered together.

IF(Amount = 0, 0, (Amount - Cost__c) / Amount)

Actual-versus-target variance: A positive value means actual performance exceeded the target, while a negative value means it fell short. If Actual__c is 125 and Target__c is 100, the result is 25. Use a currency or number output type depending on what the fields represent.

Actual__c - Target__c

Days to close or days open: This example calculates elapsed calendar days from record creation to closing, or from creation to today if the record remains open. If CreatedDate is October 1, 2026, and the report is run on November 3, 2026, the open-record result is 33. Choose Number as the output type. The example converts the Date/Time creation value to a date so it can be compared with date values.

IF(ISBLANK(ClosedDate), TODAY() - DATEVALUE(CreatedDate), ClosedDate - DATEVALUE(CreatedDate))

Overdue status: This returns a text label for a record with a due date in the past that is not complete. Records without a due date are not labelled overdue. A task with a past Due_Date__c and Status__c of “In Progress” returns “Overdue”; a completed task returns “On track.” Adapt the completion value and labels to your process.

IF(AND(NOT(ISBLANK(Due_Date__c)), Due_Date__c < TODAY(), Status__c <> "Complete"), "Overdue", "On track")

Choose the right result type and format

The formula’s output type determines how Salesforce displays and interprets its result. A correct calculation can still be confusing if the type is wrong: a ratio shown as a plain decimal may look like 0.2 instead of 20%, and a currency result should not be presented as an unlabelled number.

Use Percent for ratios such as discount rate or margin rate. The formula should return a fraction such as 0.2, not 20, if the display is intended to show 20%.
Use Currency for monetary differences when the source fields represent money, and Number for counts, elapsed days, or unit differences.
Use Text for labels such as “Overdue” and “On track.”
Choose decimal precision deliberately. Extra decimal places can make a report harder to scan; too few can hide meaningful differences.

Check how blanks should behave before choosing a fallback. Returning zero, an empty value, or a label changes what readers infer. For example, a missing cost is not necessarily the same as a cost of zero.

Limits and what row-level formulas cannot replace

Salesforce supports up to five row-level formulas in a report, so reserve them for calculations that add real analytical value. They are intended for row-by-row logic within the report, not calculations across records. A row-level formula cannot answer questions such as “What percentage of all opportunities did this one opportunity contribute?” unless the required aggregate comparison is handled separately.

Availability and behavior can depend on the report format, report type, Salesforce release, and org configuration. Joined reports and specialized report features may not support every formula capability, so confirm the editor offers the option for the report you are editing. A formula can only use appropriate fields exposed to that report; it cannot pull in an unrelated object field merely because that field exists elsewhere in Salesforce.

Because a report formula is not a stored field, it is not a substitute when the calculated value must be reused in list views, integrations, record-triggered automation, or multiple reports. In those cases, consider a custom formula field or another data-model solution. Formula changes also affect only that report’s calculation; they do not modify existing records.

Row-level formula versus summary formula or formula field

Choose based on the level at which the result must exist. A row-level formula is for a calculation on each record in one report. A summary formula is for calculations involving report aggregates or grouped totals, such as comparing subtotals. A custom formula field is part of the Salesforce object’s schema and can be reused in multiple places where that field is available.

For example, use a row-level formula to show each opportunity’s amount minus its estimated cost. Use a summary-level calculation when you need to evaluate total amount against total cost for a group. Use a custom formula field if the same per-opportunity calculation needs to appear consistently in multiple reports or other Salesforce features. The best choice is not always the shortest formula; it is the one that puts the calculation at the level where users need it.

Common errors and ways to troubleshoot

If Salesforce rejects a formula, first confirm that every field is available in the report and that its name matches the field selected in the editor. A field’s displayed label can differ from its API name, and custom fields often require their exact org-specific names. Use the editor’s insert-field control to avoid spelling mistakes.

Wrong result type: Check whether the output is set to Percent, Currency, Number, or Text as intended. A percent formula usually returns a fraction.
Division by zero: Guard a denominator with an IF condition, as in the discount and margin examples. Decide what a zero denominator should mean in the report.
Blank data: Test records with missing dates or amounts. Functions and comparisons can behave differently with blank values than readers expect.
Date and Date/Time mismatch: Salesforce distinguishes dates from date/time values. Convert a Date/Time value when the expression requires a date-only comparison, and check time-zone implications for time-sensitive reporting.
Unexpected percentages: If a result displays as 2,000%, the formula may be multiplying by 100 even though the Percent display already handles the presentation.

Test ordinary, boundary, and incomplete records. For a margin formula, test a normal sale, a zero-amount row, and a row with missing cost. This catches misleading output that a formula editor’s syntax check alone may not reveal.

Good practices for readable reports

Name each formula column for what it means, not how it is calculated. “Discount %” is clearer to a report reader than “List Price Less Sale Price Divided by List Price.” Add a short description when the business definition needs explanation, particularly for metrics such as margin that may have multiple accepted definitions.

Keep expressions focused, use safeguards for blank or zero values, and compare results with records whose answers can be calculated manually. If the logic becomes difficult to maintain, or if several teams need the same calculation, move it into a reusable field or other appropriate Salesforce design rather than building slightly different versions in many reports.

Frequently Asked Questions

Can a Salesforce row-level formula update a record?
No. It calculates a displayed report value only. To save or automate a value, use an appropriate field and automation or data-model approach.

Can I use a row-level formula to calculate a report total?
Not by itself. It evaluates each record independently. Use report summaries and a summary formula, or another aggregate-capable reporting approach, for totals and group-level comparisons.

How many row-level formulas can a report have?
Salesforce allows up to five row-level formulas in a report. If you reach that limit, review whether a repeated calculation belongs in a reusable formula field or whether some columns can be removed.

Why is my percentage 100 times too large?
A Percent output type displays a decimal fraction as a percentage. Return 0.2 for 20%; do not multiply by 100 as well unless you intentionally want a different numeric result type.

Can other reports use my row-level formula?
Not as a shared object field. The formula belongs to the report where it was created. Recreate it in another report or define a reusable field if the same calculation needs to be available across reports.

Try it: the Formula Explainer: paste any formula and see each function and reference in plain English.

More in Formulas & functions

Sources: Function behaviour and menu paths: Microsoft Support documentation for Excel. Method & sources

Spotted an error in this guide? Let us know.