# Epicor BPM Directive Overhead Calculator > Source: https://netray.co/tools/epicor-bpm-directive-overhead-calculator > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer See how many milliseconds and server hours your BPM directives add per transaction and per day. ## Category epicor ## Erp Epicor Kinetic ## Audience - Epicor developer - Epicor administrator - Solution architect ## Tool **Kind:** calculator **Inputs:** #### Transactions per day on the method **Key:** txn_per_day **Type:** number **Default:** 8000 **Min:** 0 **Step:** 500 **Unit:** calls **Help:** For example SalesOrder.Update or LaborDtl.Update calls per day. #### Directives firing per call **Key:** directives **Type:** slider **Default:** 4 **Min:** 0 **Max:** 20 **Step:** 1 **Unit:** directives #### Average time per directive **Key:** ms_dir **Type:** number **Default:** 120 **Min:** 0 **Step:** 10 **Unit:** ms **Help:** Includes any queries or calls the directive makes. #### Share running synchronously **Key:** sync_pct **Type:** slider **Default:** 80 **Min:** 0 **Max:** 100 **Step:** 5 **Unit:** % **Help:** Pre-processing and in-transaction directives block the user. Data directives and scheduled work do not. #### Base method time without directives **Key:** base_ms **Type:** number **Default:** 400 **Min:** 1 **Step:** 50 **Unit:** ms #### Users doing this work **Key:** users **Type:** number **Default:** 25 **Min:** 1 **Step:** 1 **Unit:** users **Outputs:** #### Added wait per call **Key:** added_ms **Expr:** directives * ms_dir * sync_pct / 100 **Format:** number **Primary:** true **Description:** Milliseconds a user waits because of directives. #### Share of total response time **Key:** overhead_pct **Expr:** added_ms / (base_ms + added_ms) * 100 **Format:** percent #### Server time per day **Key:** server_hours **Expr:** txn_per_day * directives * ms_dir / 3600000 **Format:** hours #### Total user waiting per day **Key:** user_wait_min **Expr:** txn_per_day * added_ms / 60000 **Format:** minutes #### Waiting per user per day **Key:** wait_per_user **Expr:** user_wait_min / users **Format:** minutes **Primary:** true **Chart:** #### Added wait per call vs directives **Type:** line **X:** directives **From:** 0 **To:** 20 **Steps:** 20 **Series:** - added_ms **Disclaimer:** Planning model with averages. Measure real directive times with the Epicor server logs or tracing before and after changes. ## Content **Intro:** Every method directive adds work to a save, and users feel it as lag. This calculator converts per-directive timing into per-call latency, server time and the total minutes your team waits each day, so you can decide what to consolidate or move off the critical path. **Sections:** #### How to use it **Body:** Pick the method that worries you, such as a sales order or labor update. Enter calls per day, how many directives fire on each call and their average time. Set the share that runs synchronously, because only blocking directives make a user wait. Enter the base method time to see the percentage the directives add, then read the daily waiting per user. **Bullets:** - Count every directive that applies to the method, including disabled-but-deployed ones you forgot. - Pull timings from the server log or by running with directives temporarily off. - Compare scenarios by changing the sync share after moving logic to data directives. #### The formulas **Body:** Added wait per call is directives multiplied by milliseconds each, scaled by the synchronous share. Overhead percent compares that to base time plus the added wait. Server hours per day count all directives, sync or not, since they all use the application server. Total user waiting is added wait multiplied by daily calls, and per-user waiting divides that across the people doing the work. #### Interpreting results **Body:** A few hundred milliseconds across thousands of calls can add up to hours of collective waiting, even when no single save feels broken. If overhead exceeds a third of response time, review the directives for duplicate lookups, per-row database calls and logic that could run in a single combined directive. Moving work to a data directive or a scheduled process removes it from the user path. #### Common mistakes **Body:** Multiple directives often re-read the same record. Heavy work such as emails or external web calls placed in pre-processing makes the user wait for a network. Directives on high-volume methods like labor entry deserve the most scrutiny. Always test with realistic data volumes, and keep directive groups documented so cleanup is possible. **Cta:** Netray can audit your BPM and customisation estate for performance and upgrade risk. The calculator needs nothing from us. **Faq:** #### Do data directives slow users down? **Answer:** Data directives work on field values within the transaction scope and are usually lightweight, but any directive that runs queries or calls external services can add time. Measure rather than assume. #### How many directives per method is too many? **Answer:** There is no fixed number. Judge by measured time, not count. A dozen light directives may cost less than one that queries a large table, so profile the slow ones first. #### Why count asynchronous work in server hours? **Answer:** It still consumes application server and database capacity even if the user does not wait. Heavy asynchronous load can slow other users at peak, so it belongs in capacity planning. #### Can I move logic out of directives? **Answer:** Often yes: scheduled functions, post-processing background work or integration tools can take non-urgent logic off the save path. Keep validations that must block a transaction in the synchronous path. ## Search terms epicor bpm performance, epicor method directive slow, epicor bpm overhead, epicor pre-processing post-processing directive, epicor in-transaction directive, epicor bpm best practices, epicor slow save order --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json