Epicor BPM Directive Design Template
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.
Fill in
Epicor BPM Directive Design Template
BPM Directive Design: JobEntry_ReleaseCheck
Company: Acme Precision Ltd Author: A. Developer Date: 2026-10-20 Directive type: Method directive: Pre-Processing Target: Erp.JobEntry / Update
Business reason
Prevent release of a job when any material requirement has no approved supplier or the method has not been engineered.
Conditions (when it fires)
JobHead.JobReleased changes from false to true and the job part is a controlled part class.
Actions
Raise a blocking exception that lists the offending material lines. Do not change data.
Risk and performance review
| Question | Answer | Owner |
|---|---|---|
| Does it run on every call of a high-volume method? | ||
| Does it write data, or only validate? | ||
| Does it call external services or the REST API? | ||
| Could it block a transaction on the shop floor? | ||
| Is the error message clear to the end user? |
Test plan
| Test case | Expected result | Result | Tester |
|---|---|---|---|
| Condition true, normal user | |||
| Condition false | |||
| Bulk or batch call of the method | |||
| User with limited security |
Rollback plan
Disable the directive in the BPM Directive Maintenance screen. No data changes are made so no data fix is needed.
Approvals
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.
Customization inventory
Want help inventorying your BPM directives and customizations before an upgrade? Ask for an optional review.
Optional. The tool and every export work without this. No spam.
How to use this template
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.
- 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
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
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
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.
Frequently Asked Questions
What is the difference between a method directive and a data directive?
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?
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?
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?
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.
We can review your existing directive inventory and help document or retire the ones nobody can explain.
Related Tools
Epicor BAQ Query Template Generator
Fill in company, days back and status filters to get a starter SQL for an open jobs BAQ, plus a design checklist for the Query Builder.
EpicorEpicor Kinetic Upgrade Checklist
A phase-by-phase upgrade checklist covering inventory, testing, integrations, cutover and rollback for Epicor Kinetic.
EpicorEpicor Security Group Design Worksheet
An editable worksheet to plan security groups by role and score each for exposure, so over-broad access is visible before audit.
EpicorEpicor Kinetic Job Status Reference
A searchable lookup of the job lifecycle flags and related fields in Epicor Kinetic job entry, so you can build BAQs and dashboards with the right filter.
More Epicor tools
See all- Epicor DMT Import Template Worksheet (Part and BOM)
- Epicor MRP Run Checklist
- Epicor REST API v2 URL Builder
- Epicor Safety Stock and Reorder Point Calculator
- Epicor EOQ and Lot Sizing Calculator
- Epicor Resource Group Burden Rate Calculator
- Epicor Shop Floor OEE Calculator
- Epicor Job Cost Variance Worksheet
- Epicor Shop Floor Labor Reporting SOP Template