# Epicor BPM Directive Design Template > Source: https://netray.co/tools/epicor-bpm-directive-design-template > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A fill-in design document for BPM method and data directives covering trigger, conditions, actions, testing and rollback. ## Category epicor ## Erp Epicor Kinetic ## Industry Discrete Manufacturing ## Audience - Epicor administrator - Epicor developer - IT manager ## Tool **Kind:** template **Output:** document **Fields:** #### Company **Key:** company **Type:** text **Default:** Acme Precision Ltd #### Directive name **Key:** directive_name **Type:** text **Default:** JobEntry_ReleaseCheck #### Author **Key:** author **Type:** text **Default:** A. Developer #### Date **Key:** date **Type:** date **Default:** 2026-10-20 #### Directive type **Key:** dtype **Type:** select **Options:** - Method directive: Pre-Processing - Method directive: Post-Processing - Method directive: Base Processing - Data directive: In-Transaction - Data directive: Standard **Default:** Method directive: Pre-Processing #### Business object and method **Key:** service **Type:** text **Default:** Erp.JobEntry / Update #### Business reason **Key:** purpose **Type:** textarea **Default:** Prevent release of a job when any material requirement has no approved supplier or the method has not been engineered. #### Conditions **Key:** condition **Type:** textarea **Default:** JobHead.JobReleased changes from false to true and the job part is a controlled part class. #### Action **Key:** action **Type:** textarea **Default:** Raise a blocking exception that lists the offending material lines. Do not change data. #### Rollback plan **Key:** rollback **Type:** textarea **Default:** Disable the directive in the BPM Directive Maintenance screen. No data changes are made so no data fix is needed. **Blocks:** #### BPM Directive Design: {{directive_name}} **Body:** Company: {{company}} Author: {{author}} Date: {{date}} Directive type: {{dtype}} Target: {{service}} #### Business reason **Body:** {{purpose}} #### Conditions (when it fires) **Body:** {{condition}} #### Actions **Body:** {{action}} #### Risk and performance review **Table:** **Columns:** - Question - Answer - Owner **Rows:** **0:** Does it run on every call of a high-volume method? **0:** Does it write data, or only validate? **0:** Does it call external services or the REST API? **0:** Could it block a transaction on the shop floor? **0:** Is the error message clear to the end user? #### Test plan **Table:** **Columns:** - Test case - Expected result - Result - Tester **Rows:** **0:** Condition true, normal user **0:** Condition false **0:** Bulk or batch call of the method **0:** User with limited security #### Rollback plan **Body:** {{rollback}} #### Approvals **Signatures:** - Developer - Business owner - IT manager **Notes:** Document the directive in your change log and test it in a non-production environment first. Keep directives small and focused so they are easy to disable. ## Content **Intro:** BPM directives are powerful and easy to forget. One undocumented pre-processing directive can block a transaction months later and nobody remembers why. This template forces the key decisions onto one page before you build. **Sections:** #### How to use this template **Body:** Fill in the fields, export to PDF or Word, and attach the file to your change request. Name the directive after the business object and purpose, state the trigger, and write the conditions in plain English before opening the BPM designer. Reviewing the page with the business owner catches ambiguous rules before they become code. **Bullets:** - Use one directive per purpose rather than one big directive - State whether it validates or writes data - Define the exact message users will see - Record who can approve disabling it #### Choosing the directive type **Body:** Pre-processing runs before the method and is the right place to validate or stop a transaction. Post-processing runs after the method and suits notifications or follow-on updates. Base processing wraps the standard logic and is rarely needed. Data directives fire on table changes and can catch updates from any path, including integrations. Choose the narrowest one that does the job. #### Performance and safety **Body:** Directives on frequently called methods such as labor or inventory transactions run constantly, so keep conditions cheap and avoid external calls. Blocking exceptions on the shop floor stop real work, so test them with realistic users. Prefer validating over silently changing data, and always keep a documented way to disable the directive quickly. #### Common mistakes **Body:** Building in production, skipping the rollback plan, and writing conditions that depend on a user-defined field that is empty in some paths. Another frequent issue is a directive that works for the UI but fails when the method is called by an integration, because the context differs. Test both. **Cta:** We can review your existing directive inventory and help document or retire the ones nobody can explain. **Faq:** #### What is the difference between a method directive and a data directive? **Answer:** A method directive fires when a business object method is called, such as Update on JobEntry. A data directive fires when a table row is added, changed or deleted, regardless of which method or process caused it. Data directives catch changes from integrations as well as the UI. #### Should a BPM directive change data? **Answer:** It can, but validation is safer than silent changes. If you must change data, document exactly which fields change and why, test with bulk calls, and avoid logic that could re-trigger the same directive in a loop. #### How do I test a directive safely? **Answer:** Use a test or pilot environment copied from production, test the true and false cases, use a restricted user, and run any bulk process that calls the method. Only then move the directive to production through your normal change control. #### Can I disable a directive without deleting it? **Answer:** Yes. Directives can be deactivated in the BPM Directive Maintenance screen, which is the recommended rollback because it keeps the design for later. Record who may do so in the template. ## Search terms epicor bpm design document, epicor bpm directive template, epicor method directive pre-processing, epicor data directive, epicor bpm best practices, epicor customization documentation, epicor bpm workflow design, epicor kinetic bpm --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json