Back to Blog
2025-12-05 11 min read

Custom Functions vs. Inline Calculations in FileMaker: When to Use Each

You're writing a calculation to format a phone number. You've done this before in three other places in your solution. Should you create a custom function called FormatPhoneNumber, or just write the calculation inline again?

A week later, you need a complex date calculation that you'll only use once. Should you create a custom function for clarity, or keep it inline where it's needed?

Knowing when to utilize a custom function is a solid skill to have in FileMaker develop as it promises reusability and clean code. On the other hand, inline calculations promise simplicity and transparency. I'm going to help break down the distinction and situations to look out for that will help lead you to pick one over the other.

Understanding the Trade-Off

Custom functions and inline calculations represent different philosophical approaches to organizing your code.

Inline calculations are transparent. When you look at a calculation field or script step, you see exactly what's happening. No need to hunt through your function library to understand the logic. The calculation is self-contained and explicit.

Custom functions are abstract. They hide implementation details behind a descriptive name. When used well, they make complex calculations readable. When used poorly, they obscure what's actually happening and require constant jumping between contexts to understand your solution.

The key insight: abstraction has a cost. Every custom function adds cognitive overhead. Developers need to remember it exists, understand what it does, and know when to use it. That overhead is only worth paying when you get sufficient benefit in return.

When Custom Functions Make Sense

Repeated Logic Across Multiple Contexts

If you're writing the same calculation in multiple places, a custom function eliminates duplication. When the logic needs to change, you update one function instead of hunting through your solution for every instance.

Example: Date formatting appears everywhere in your solution.

Without a custom function:

// In 15 different calculation fields:
MonthName ( YourDate ) & " " & Day ( YourDate ) & ", " & Year ( YourDate )

With a custom function:

// Custom Function: FormatDateShort ( theDate )
MonthName ( theDate ) & " " & Day ( theDate ) & ", " & Year ( theDate )

Now you can update your scripts to use the custom function:

// In calculation fields:
Set Field [ Invoice::Date ; FormatDateShort ( YourDate ) ]

When you decide to change the format, you update one function instead of 15 calculations.

Complex Logic That Benefits From Naming

Some calculations are complex enough that a descriptive name adds clarity even if you only use them once or twice.

Example: Calculating business days between two dates.

Inline calculation:

Let ( [
  startDate = Invoice::CreatedDate ;
  endDate = Invoice::DueDate ;
  totalDays = endDate - startDate ;
  weekendDays = Int ( totalDays / 7 ) * 2 +
  Case (
    DayOfWeek ( startDate ) = 1 ; 1 ;
    DayOfWeek ( startDate ) + Mod ( totalDays ; 7 ) > 7 ; 2 ;
    DayOfWeek ( startDate ) + Mod ( totalDays ; 7 ) = 7 ; 1 ;
    0
  )];
  totalDays - weekendDays
)

Anyone reading this needs to mentally parse the logic to understand what it calculates.

With custom function:

// Custom Function: BusinessDaysBetween ( startDate ; endDate )
Let ( [
  totalDays = endDate - startDate ;
  weekendDays = Int ( totalDays / 7 ) * 2 +
  Case (
    DayOfWeek ( startDate ) = 1 ; 1 ;
    DayOfWeek ( startDate ) + Mod ( totalDays ; 7 ) > 7 ; 2 ;
    DayOfWeek ( startDate ) + Mod ( totalDays ; 7 ) = 7 ; 1 ;
    0
  )];
  totalDays - weekendDays
)

// In calculation field:
BusinessDaysBetween ( Invoice::CreatedDate ; Invoice::DueDate )

The named function is self-documenting. You know immediately what it calculates without reading the implementation.

Calculations That Encapsulate Business Rules

When calculations represent business logic that might change, custom functions provide a single point of control.

Example: Determining if a customer qualifies for volume discounts.

// Custom Function: QualifiesForVolumeDiscount ( customerID )
Let ( [
  totalOrders = ExecuteSQL (
    "SELECT COUNT(*) FROM Orders WHERE CustomerID = ?" ;
    "" ; "" ; customerID
  );
  totalSpent = ExecuteSQL (
    "SELECT SUM(Total) FROM Orders WHERE CustomerID = ?" ;
    "" ; "" ; customerID
  )];
  totalOrders >= 10 and totalSpent >= 5000
)

Note SQL is used her to collect data, but you could also pass those totals as parameters rather than a customerID:

QualifiesForVolumeDiscount ( totalOrders ; totalSpent )

The qualification rules (10 orders and $5000 spent) are business decisions that might change. Centralizing them means updating the rules in one place affects all contexts.

Recursive or Self-Referencing Logic

Some calculations require recursion. Custom functions handle this elegantly where inline calculations can't.

// Custom Function: Factorial ( n )
Case (
  n <= 1 ; 1 ;
  n * Factorial ( n - 1 )
)

This recursive pattern can't be expressed inline because calculations can't call themselves.

When to Keep Calculations Inline

Single-Use Calculations

If you're only using a calculation once, abstracting it adds complexity without benefit.

// Inline in the report calculation:
Count ( Tasks::TaskID ; Tasks::Status = "Complete" ) / Count ( Tasks::TaskID ) \* 100

This is clear and specific. Creating a custom function adds overhead without the benefit of reuse.

Context-Specific Calculations

When calculations are tightly coupled to specific contexts or tables, abstracting them can make them less clear.

// Inline:
Case (
  Orders::CustomerType = "Wholesale" ; Orders::Subtotal _ 0.20 ;
  Orders::CustomerType = "Retail" and Orders::Subtotal > 1000 ; Orders::Subtotal _ 0.10 ;
  Orders::CustomerType = "Retail" ; Orders::Subtotal \* 0.05 ;
  0
)

This calculation is specific to the Orders context. A custom function would require passing all these values as parameters, making it more verbose than keeping it inline.

Simple Transformations

Basic calculations that are immediately understandable don't benefit from abstraction.

// Don't create custom functions for these:
Upper ( Customer::Name )
Year ( Invoice::Date )
Round ( Price \* Quantity ; 2 )

These are self-explanatory. A custom function adds indirection without improving clarity.

When to Use a Custom Function

Create a custom function if ANY of these are true:

  • You'll use this exact calculation in 3 or more places
  • The calculation is complex and a descriptive name adds clarity
  • This represents business logic that might change independently
  • The calculation requires recursion or self-reference
  • You need consistent behavior across multiple contexts

When to Keep It Inline

Keep the calculation inline if ALL of these are true:

  • You'll use it in only 1--2 places
  • The calculation is simple and self-explanatory
  • It's tightly coupled to a specific table or context
  • The logic is unlikely to change independently

Quick rule of thumb: If you're copy-pasting a calculation for the third time, it's time for a custom function.

Naming and Documentation

When you create custom functions, naming and documentation are critical.

Good names are descriptive and follow patterns:

// Good:
CalculateTaxAmount ( subtotal ; taxRate )
FormatPhoneNumber ( rawPhone )
IsWorkingDay ( dateToCheck )

// Bad:
CalcTax ( x ; y )
PhoneFormat ( p )
CheckDay ( d )

Use verbs for actions, Is/Has for boolean functions:

CalculateDiscount
IsValidEmail ( email )
HasPendingOrders ( customerID )

Document every function:

// Custom Function: CalculateShippingCost ( weight ; destination ; shippingMethod )
//
// Calculates shipping cost based on package weight, destination, and method
//
// Parameters:
// weight (number): Package weight in pounds
// destination (text): "Domestic" or "International"
// shippingMethod (text): "Standard", "Express", or "Overnight"
//
// Returns: Shipping cost in dollars (number)

Managing Your Function Library

Organize functions with naming conventions since FileMaker doesn't provide folders:

// Date functions:
Date_Format
Date_BusinessDays
Date_IsHoliday

// Text functions:
Text_Trim
Text_ProperCase

// Validation functions:
Validate_Email
Validate_Phone

When replacing functions, use deprecation:

// Custom Function: DEPRECATED_OldCalculation
// This function is deprecated. Use NewCalculation instead.

This prevents breaking existing calculations while signaling the function shouldn't be used in new development. Use a tool like BaseElements to check your codebase for lingering references to a deprecated function easily.

Refactoring: From Inline to Custom Function

You don't need to create custom functions preemptively. Start with inline calculations and extract functions when patterns emerge.

Refactoring trigger: You copy-paste a calculation for the third time.

Process:

  1. Identify all instances of the duplicated calculation
  2. Create the custom function with clear naming and documentation
  3. Replace each inline instance with the function call
  4. Test thoroughly
  5. Delete the inline calculations once verified

What to Avoid

Over-abstraction: Creating custom functions for everything makes your solution harder to understand. Reserve functions for genuinely reusable or complex calculations.

Under-parameterization: Functions that hardcode values instead of accepting parameters limit reusability.

// Bad:
CalculateDiscount // Hardcodes 10% discount

// Better:
CalculateDiscount ( amount ; discountPercent )

Missing documentation: Future you won't remember what a function does. Document as you create.

Creating functions for script readability: Custom functions improve calculation readability, not script readability. Use descriptive script names instead.

Real-World Example: Customer Score Function

Your solution needs to calculate a customer quality score. Initially, you write it inline in a report. Then you need it on a dashboard. Then in a script. Then another report.

By the third usage, you extract it:

// Custom Function: CalculateCustomerScore ( customerID )
//
// Calculates customer quality score based on order history and activity
// Score ranges from 0-100
//
// Parameters:
// customerID (number): The customer's ID
//
// Returns: Quality score (number)
Let ( [
  avgOrderValue = ExecuteSQL (
    "SELECT AVG(Total) FROM Orders WHERE CustomerID = ?" ;
    "" ; "" ; customerID
  ) ;
  orderCount = ExecuteSQL (
    "SELECT COUNT(*) FROM Orders WHERE CustomerID = ?" ;
    "" ; "" ; customerID
  ) ;
  lastOrderDate = ExecuteSQL (
    "SELECT MAX(OrderDate) FROM Orders WHERE CustomerID = ?" ;
    "" ; "" ; customerID
  ) ;
  daysSinceLastOrder = Get ( CurrentDate ) - lastOrderDate ;
  hasOpenInvoices = ExecuteSQL (
    "SELECT COUNT(*) FROM Invoices WHERE CustomerID = ? AND Status = 'Open'" ;
    "" ; "" ; customerID
  ) > 0
  ];
  Case (
    avgOrderValue > 1000 and orderCount > 10 ; 100 ;
    avgOrderValue > 500 and orderCount > 5 ; 75 ;
    avgOrderValue > 200 and orderCount > 2 ; 50 ;
    25
    ) -
  Case (
    hasOpenInvoices ; 10 ; 0
  ) -
  Case (
    daysSinceLastOrder > 180 ; 15 ;
    daysSinceLastOrder > 90 ; 5 ;
    0
  )
)

Now everywhere you need the customer score:

CalculateCustomerScore ( Customer::CustomerID )

The benefits: reusable across contexts, single place to update scoring logic, self-documenting, testable independently.

Conclusion

Custom functions are tools, not goals. The question isn't "should I always use custom functions" or "should I never use custom functions." It's "does a custom function make this specific calculation more maintainable, more reusable, or more clear?"

Start with inline calculations. Extract custom functions when you see repeated patterns or when naming adds clarity to complex logic. Don't abstract prematurely, but don't avoid abstraction when it provides clear benefit.

Your function library should be curated, not comprehensive. Every function should earn its place through reuse, clarity, or encapsulation of business rules.

Some Next Steps

Review the custom functions in your current FileMaker solution. For each one, ask: is this used in multiple places? Does it encapsulate complex logic? Does it represent changeable business rules? If the answer to all three is no, consider inlining it.

Then look at your calculation fields. Are there patterns of duplicated logic? Complex calculations that would benefit from descriptive names? Those are candidates for extraction.

The goal is balance where abstraction serves clear purposes and inline calculations handle simple, context-specific needs. Start making intentional decisions about when to abstract and when to keep things explicit.

Custom Functions vs. Inline Calculations in FileMaker: When to Use Each | Jeffrey Henry