What Is an Epicor Function (EFx)? Beginner's Guide

Short answer

An Epicor Function (often written EFx) is a reusable piece of server-side logic that you build once inside an Epicor Function Library and call from many places. Functions can be called from BPM directives, Application Studio events, scheduled background tasks, other functions, and external systems via the Epicor REST API v2. They are the standard way to avoid duplicating business logic across multiple BPM directives or screens.

Key facts

EFx is the common abbreviation for Epicor Functions.
Functions are grouped into libraries in Epicor Functions Maintenance.
A function has a signature (the scalar inputs/outputs and tablesets it accepts and returns) and a body (Widget Function or Code Function logic).
Each library explicitly declares its References (which Epicor Business Objects/Services, database tables, and assemblies it is allowed to use).
Libraries must be promoted from Staging to Production in Epicor Functions Maintenance before callers can execute them in normal operation.
Functions run on the server and execute only when invoked by a caller or schedule.

How a Function is organized

Library A named container in Epicor Functions Maintenance that groups related functions (for example, one library for order rules and another for integration helpers), manages company/security access, and controls Promotion to Production.

References The explicit list of database tables, Epicor Business Objects (Services), and assemblies the library is permitted to access. A function cannot query a table or call a Business Object until that reference is added to its library.

Function One named unit of logic inside a library (built as either a visual Widget Function or a C# Code Function, depending on your permissions and cloud policy).

Signature The list of request parameters (inputs) and response parameters (outputs). Parameters can be simple data types (such as string, int, decimal, or bool) or full Epicor Tablesets.

Body The server-side workflow itself, built with BPM-style designer widgets and, where enabled, C# custom code blocks.

Function vs. BPM Directive

	BPM Directive	Epicor Function (EFx)
What starts it	An event: a BO method call or a database table write	An explicit call from a BPM, Application Studio event, scheduled task, or REST v2
Main purpose	"React when a specific ERP event happens"	"Run this reusable server-side work and return outputs"
Reusable	Tied to one method or table	Yes, callable across Epicor
Typical relationship	Detects the event and invokes the Epicor Function	Holds the shared business logic

Where a Function can be called from

BPM Method and Data Directives, using the Invoke Epicor Function widget.
Application Studio events in the Kinetic browser UX (using the kinetic-function / erp-function widget).
Scheduled background tasks via the Schedule Epicor Function process (run by the Epicor Task Agent on a recurring schedule or on demand).
Other Epicor Functions (within the same library or across referenced libraries).
External integrations and Epicor Automation Studio via the Epicor REST API v2 (/api/v2/efx/{Company}/{Library}/{Function}), which requires a valid REST v2 API Key with the function library included in its Access Scope.

Common uses

A validation or multi-step Business Object update shared by several BPM directives.
A calculation or custom action triggered from a button in Application Studio without exposing complex business logic in the browser.
A nightly or hourly background job run via Schedule Epicor Function.
A clean, single-call custom REST API v2 endpoint for an external integration or webhook so the caller does not have to orchestrate multiple standard Business Object methods.

When a Function is not needed

A simple one-line check used in only one directive can stay inside that directive.
A change that only affects how a screen looks belongs in Application Studio.
A read-only query or list of data for users belongs in a BAQ.

Do not create a function just because you can. Create one when logic is shared, scheduled, called from a Kinetic UI button, or exposed as a simplified integration endpoint.

Good habits

Name libraries and functions clearly with a company prefix so custom libraries stand out.
Keep each function small and focused on one job.
Add only the Table and Business Object references the library actually needs.
Define the inputs and outputs carefully, and validate inputs before using them.
Return clear error messages or response flags that tell the user or calling integration what went wrong.
Do not hard-code values that change, such as site IDs, URLs, or credentials.
Never write directly to Epicor database tables with raw SQL. Always invoke supported Epicor Business Objects (via the Invoke BO Method widget or service contract) to modify ERP data.
Restrict which companies and security groups can run each library, and scope REST v2 API Keys in Access Scope Maintenance so external integrations can only call the specific libraries they need.
Export and back up libraries (as .efxb packages in Epicor Functions Maintenance or inside Solution Workbench) before making changes, and remember to Promote to Production after testing.

Common problems

Forgetting to Promote to Production. Edits made to a library stay in staging until you promote the library to production in Epicor Functions Maintenance.

Missing Library References or Access Scope. If a function cannot see a table or Business Object inside the designer, add it on the Library References tab. If a REST v2 call returns 403/404, verify that the library is promoted, enabled for the company, and included in the API Key's Access Scope.

Changing a function signature that many callers depend on. Because a function is shared, changing its input or output parameters breaks existing BPM directives, Application Studio events, or REST callers until they are updated. List every caller before changing a signature.

Slow synchronous functions in the save path. A function called synchronously from a Pre-Processing Method Directive or In-Transaction Data Directive makes the user wait. Keep synchronous functions fast, or offload heavy background work.

FAQ

What does EFx stand for in Epicor?

EFx is the standard shorthand for Epicor Functions.

What is an Epicor Function used for?

It encapsulates reusable server-side logic that can be invoked from BPM directives, Application Studio events, scheduled background tasks (Schedule Epicor Function), other functions, and external systems via REST API v2.

Can I call an Epicor Function using REST API v1?

No. Calling Epicor Functions over REST requires REST API v2 (/api/v2/efx/{Company}/{Library}/{Function}) along with an API Key whose Access Scope includes that function library.

What language are Epicor Functions written in?

Functions can be built visually using BPM-style workflow widgets (Widget Functions) or written in C# (Code Functions), depending on user permissions and deployment security settings.

Can an Epicor Function run on a recurring schedule?

Yes. Use the Schedule Epicor Function process inside Epicor to run any function on a recurring System Agent schedule or on demand via the Task Agent.

Should I write directly to the database from an Epicor Function?

No. Always call Epicor Business Objects to create or update ERP records so standard validations, GL logic, and audit trails are preserved.

References

Cross-check against official Epicor documentation matching your release and hosting model:

Epicor Kinetic help: Epicor Functions Maintenance and Designer
Epicor Kinetic help: Schedule Epicor Function
Epicor Kinetic help: REST API v2 Guide and Access Scope Maintenance