# How to Debug Epicor Functions (Logging, Testing, Maintenance) > Source: https://netray.co/erp-help/how-to-debug-epicor-functions-logging-maintenance > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Debug an Epicor Function by testing it in isolation with known input, writing explicit log entries from a code block, and reading the server trace log for the failing step. Keep libraries maintainable by naming functions clearly, documenting parameters, and managing security and versions in Epicor Functions Maintenance. ## Kind how-to ## System epicor ## Erp Epicor Kinetic ## Module Epicor Functions / Debugging ## Query how to debug epicor functions ## Alternate Queries - epicor function logging - epicor functions maintenance - epicor function maintenance ## Applies To Epicor Kinetic 2021 and later with Epicor Functions; behaviour of the test tool and tracing options varies slightly by release ## Steps ### How to debug an Epicor Function **Items:** - Open Epicor Functions Maintenance, find the library and function, and confirm the function is saved and set to a state you can call. - Reproduce the failure with a small known input: use the function's test capability if your release has it, or call it through REST with a fixed payload. - Add log lines at key steps from a code block, for example before and after each widget that touches data, with the variable values. - Turn on Tracing Options in the Kinetic client, run the scenario once, and open the server trace log to read the function and BPM entries. - Narrow down which widget fails by disabling downstream widgets or returning early with a fixed value. - Check the input and output parameter types, because a mismatch in type or nullability is a common cause of runtime failures. - Fix, save, and retest with the same input; then test an edge input (empty, null, large) before releasing. - Remove or reduce verbose logging once fixed, so the trace log is not flooded in production. ## Sections ### Writing log entries **Body:** The simplest debugging aid is a log line you wrote yourself. In a Custom Code block you can write an entry to the Epicor diagnostic log, which appears in the server trace output when tracing is enabled. Include the function name and the value you care about so entries are searchable. Log decisions, not noise: which branch ran, how many rows a query returned, and the key identifiers. Never log passwords, tokens or personal data, because trace logs are often copied to forums and tickets. **Code:** // In a Custom Code block Ice.Diagnostics.Log.WriteEntry("MyLib.CalcFreight start, order=" + orderNum); Ice.Diagnostics.Log.WriteEntry("MyLib.CalcFreight rows=" + rows.Count); ### Testing in isolation **Body:** A function is easiest to debug when it is called alone. Calling it through its REST endpoint with a fixed JSON body removes the BPM, the form and the user session from the equation. If it works alone but fails when called from a directive, the problem is in what the directive passes in. Keep a small set of test payloads with the library documentation: a normal case, an empty case and a bad case. When you change a function months later, replaying those cases is cheaper than reasoning about what might break. ### Maintaining function libraries **Body:** Functions are grouped into libraries, and each library has its own security and its own set of functions. Treat a library like a small codebase: one clear purpose, consistent names, and descriptions on each function stating what it needs and returns. Use Epicor Functions Maintenance to review, enable and control who may call them. Before an upgrade, export your libraries and keep them in source control. After an upgrade, retest the functions that touch standard business objects, since those objects can change shape between releases. ## Pitfalls - Debugging only through the calling BPM so you cannot tell whose fault the failure is. - Leaving verbose logging on in production and filling the trace log. - Changing a function that many directives call without a test payload set. - Granting a library to everyone by default, including functions that update data. - Logging sensitive values to the trace log. ## Ai Angle An assistant grounded in your environment can list which functions exist, which directives call them, and what the recent trace entries say, then propose a minimal fix for a developer to review. SyteRay-style agents do this for SyteLine, and the same pattern applies to Epicor through ERPray and a custom build. The changes remain human-approved. ## Faq ### Where do Epicor Function log entries go? **Answer:** Entries written with the Epicor diagnostic log appear in the server trace log when tracing is enabled through the Tracing Options. Enable tracing for the session you test with, reproduce the issue once, then read the trace output. ### Is there a debugger for Epicor Functions? **Answer:** There is no step-through debugger you can attach in the browser. Developers rely on isolated test calls, log lines and the trace log, and some use a separate development environment for code-heavy functions. ### What is Epicor Functions Maintenance used for? **Answer:** It is where you create and manage function libraries and their functions: definitions, widgets, parameters, state and security. It is the main screen for reviewing what is deployed and who may call it. ### How do I test an Epicor Function without a BPM? **Answer:** Call it through its REST endpoint with a fixed JSON body, or use a test option in the designer if your version provides one. Isolated calls separate function bugs from directive or form bugs. ## Search terms how to debug epicor functions, epicor function logging, epicor functions maintenance, epicor function maintenance, epicor efx debug, epicor kinetic trace log, epicor function library, epicor function test --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json