How to create and call an Epicor Function

Build a reusable Epicor Function

1. 1Open Function Studio: Customization > Function Studio (or the wrench icon inside a BPM Custom Code widget's Call Context).
2. 2Create a new Library (a logical grouping, e.g. "CustomerHold") if one does not exist, then a new Function inside it (e.g. "GetCreditHoldReason").
3. 3Define Inputs on the Inputs tab: name, data type (string, int, DateTime, decimal, custom BO type). Mark required inputs.
4. 4Define Outputs the same way on the Outputs tab; a function can return multiple named outputs.
5. 5Switch to the Data Definitions / Widgets designer if you need to query the database (Invoke DB / Query widget) before dropping into code, or go straight to the C# Method widget for pure logic.
6. 6In the C# widget, write logic against the inputs; use Db (the Epicor DbContext-style accessor) for reads, and set output variables at the end.
7. 7Click Test at the top of Function Studio, supply sample input values, and run - the trace pane shows each widget's execution and any exception with line number.
8. 8Save and compile. The function is now selectable from any BPM directive's "Invoke Epicor Function" widget, from another function, or from a dashboard's custom code.
9. 9For reuse across companies, keep server-side logic in the function rather than client customizations so it applies uniformly to UI, BPM, and REST calls.

Common function patterns

// Inside the C# widget of a function
var cust = Db.Customer.FirstOrDefault(c => c.Company == callContextClient.CurrentCompany && c.CustNum == custNum);
if (cust == null) { outputMessage = "Customer not found"; outputIsValid = false; }
else { outputIsValid = cust.CreditHold != true; outputMessage = cust.CreditHold == true ? "Customer on credit hold" : "OK"; }

Common pitfalls

• !Forgetting to mark an input as required leaves it nullable in code, causing NullReferenceException if a caller omits it - always null-check even required inputs defensively.
• !Running heavy queries inside a function called from a Pre-Processing directive on a high-volume transaction (e.g. every part master save) can slow the whole screen - profile with the trace before deploying broadly.
• !Functions compiled against one company's customization layer may not exist for other companies until published/deployed there - check Multi-Company deployment after creating a function in a multi-company environment.
• !Db context inside a function is scoped to the current session; do not assume you can read data outside the caller's company without an explicit company filter.
• !Overwriting an existing function's signature (adding a required input) breaks every existing caller - add new inputs as optional with defaults, or version the function under a new name.
• !Testing only in Function Studio's test harness and never through the actual BPM path can miss context differences (e.g. ttOrderHed row state) that only appear in the real transaction.