Function
A Function in the Salesforce context is a named, reusable unit of logic that takes inputs, performs an operation, and returns a result.
Definition
A Function in the Salesforce context is a named, reusable unit of logic that takes inputs, performs an operation, and returns a result. The term covers several distinct surfaces of the platform: formula functions like IF, VLOOKUP, and DATE that admins use inside formula fields and validation rules; Apex methods that developers write to encapsulate business logic; SOQL aggregate functions like COUNT, SUM, and AVG that summarize query results; and Salesforce Functions, the now-retired serverless compute product that ran custom code on Salesforce-hosted infrastructure.
Each surface uses functions to keep logic concise and reusable, but the runtime, the syntax, and the limits differ. Formula functions execute inline on every record-render and respect the formula compile size; Apex methods follow the standard governor limits; SOQL aggregates evaluate at the database layer and ignore the row limit when grouped; Salesforce Functions ran on Elastic Compute infrastructure and counted against an addressable-storage quota. Knowing which function surface you are in is the first step to using it correctly.
The four function surfaces on the Salesforce platform
Formula functions for admins
The largest function library on the platform sits inside the formula editor. Setup, Object Manager, any field of type Formula opens the function picker with categories for Logical (IF, AND, OR), Math (ROUND, MOD, ABS), Text (LEFT, MID, SUBSTITUTE), Date (TODAY, DATE, ADDMONTHS), Advanced (VLOOKUP, ISCHANGED, PRIORVALUE), and Image. Functions chain freely; the only limits are the 5000-character formula size and the 4000-byte compiled size per field.
Apex methods as functions
Apex methods are the closest analog to functions in other languages. Public static methods on a utility class are the typical pattern: AccountService.recalculateBalance(Id accountId) becomes the named operation. Apex supports overloading by argument count and type; runtime polymorphism for inherited classes; and packaging methods into managed packages with @AuraEnabled annotations exposing them to Lightning Components and Flows. Standard governor limits (100 SOQL, 150 DML, 10s CPU) apply per transaction, not per function.
SOQL aggregate functions
SOQL supports COUNT, COUNT_DISTINCT, SUM, AVG, MIN, MAX, GROUPING, and HOUR_IN_DAY. These compile to database-side aggregations and return AggregateResult objects rather than full sObject lists. Aggregates can be combined with GROUP BY, ROLLUP, and CUBE for cross-tab summaries. The 50,000-row Apex limit does not apply to aggregate queries (each group returns one row), which makes aggregates the right tool for any cross-record totaling that would otherwise need a Map keyed by group.
Salesforce Functions, the retired serverless platform
Salesforce Functions was launched as a serverless compute product letting developers run Node.js, Java, or TypeScript code outside Apex governor limits. The Function ran on Salesforce-managed Heroku Compute, was invoked from Apex with sfFunctions.Function, and returned results to the calling transaction. Salesforce announced the retirement of Salesforce Functions in 2024; customers migrated to Apex, Heroku, or external integrations. The term still appears in older documentation but no longer points to an active product.
Flow formula functions
Flow Builder formula resources use the same function library as field formulas, with a few differences. Some formula functions (VLOOKUP, REGEX) are not available inside Flow; others (BLANKVALUE, ISBLANK) work identically. Flow formulas evaluate at runtime and have their own compile limits, separate from field-level formula limits. Cross-object references (Account.Industry) work, but only against fields the running user has read access to.
Functions in JavaScript and LWC
Lightning Web Components are JavaScript classes, and JavaScript functions inside the component back the property accessors, lifecycle hooks, and event handlers. The Salesforce Lightning Design System (SLDS) and Lightning Locker do not add their own function semantics; they restrict the global JavaScript surface that those functions can call. Standard JavaScript Math.round, Array.prototype.map, and arrow functions all work inside LWC.
When to factor logic into a function
The rule of thumb across all surfaces: if the same expression appears three times, it belongs in a named function. For formulas, that means a custom formula field that other formulas reference. For Apex, a public static utility method. For Flow, a subflow. For SOQL, a view-style query stored in a custom metadata record or a custom report type. The platform makes reuse cheap; the cost is usually paid in copy-paste maintenance years later.
Pick the right function surface for your task
Function choice is rarely binary. Most non-trivial logic uses a mix of formula functions for inline computation, Apex methods for orchestration, and SOQL aggregates for summarization. Walk the decision tree.
- Identify the trigger
Is the logic running on record load (formula), on save (validation rule, flow, Apex trigger), inside a query (SOQL function), or on demand from a UI (Apex controller, LWC method)?
- Pick the surface
Inline read-only math: formula function. DML side effects: flow or Apex. Cross-record summary: SOQL aggregate or rollup-summary field. External call: Apex with a Named Credential or a flow with an HTTP Callout action.
- Write the smallest version first
Build the minimum function that produces the right output for one record. Skip premature abstraction.
- Test with edge cases
Null inputs, max-length text, currency conversion, multi-currency rounding. Each surface has its own failure modes; cover the ones that fit.
- Refactor once duplication appears
Wait for the third copy before factoring out. Two copies is coincidence; three is a pattern.
- Formula functions look harmless but they re-execute on every record view. Heavy VLOOKUP usage on a frequently-viewed object can quietly degrade list-view performance.
- Apex method signatures are part of the org's API surface once a managed package ships them. Renaming or removing a public method breaks every dependent consumer.
- SOQL aggregate queries return AggregateResult, not the source sObject. The Apex code calling the aggregate must handle the typeless map keys (get('expr0')) or use FIELDS() with proper aliases.
- Salesforce Functions is retired. Any documentation, blog post, or training course referencing the product is out of date. Migrate to Apex or Heroku.
Trust & references
Cross-checked against the following references.
- Formula Operators and FunctionsSalesforce Help
- SOQL Aggregate FunctionsSalesforce Developers
Straight from the source - Salesforce's reference material on Function.
- Apex MethodsSalesforce Developers
- Salesforce Functions RetirementSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What was Salesforce Functions?
Q2. Is Salesforce Functions still available?
Q3. What are migration paths for compute-heavy work?
Discussion
Loading discussion…