Epicor BPM Directive Types Reference (Method and Data Directives)
Choosing the wrong directive type is the root of many Epicor BPM bugs: validation that fires too late, emails sent for rolled back saves, or rules bypassed by integrations. This table explains what each type does and when to use it.
| Directive type | When it runs | Can stop the transaction | Typical use | Caution |
|---|---|---|---|---|
Method directive: Pre-Processing | Before the business object method runs | Yes | Validate input, set defaults, block bad requests | Data is not yet saved, so keep work light |
Method directive: Base Processing | In place of the standard method logic | Yes | Replace standard behavior (rare) | Can bypass standard logic; hard to upgrade |
Method directive: Post-Processing | After the method completes | Yes (exception rolls back if in transaction) | Notifications, follow-up updates, integrations | Exceptions here can confuse users |
Data directive: In-Transaction | Inside the database transaction when a record changes | Yes (rolls back the change) | Rules that must be all-or-nothing with the save | Long-running code holds locks |
Data directive: Standard | After the change is committed | No | Alerts, emails, logging, async follow-up | Cannot undo the change |
Function directive | When a library function executes | Depends on code | Hook into reusable function calls | Check availability in your version |
Custom code block | As a step within a directive | Yes if it throws | Complex logic widgets cannot express | Use RowMod filters and Company scoping |
Condition widget | Inside a directive flow | No | Branch logic on field values or changes | Keep conditions simple and ordered |
Raise exception action | At that step in the flow | Yes | Show a user-facing error and stop | Write clear, actionable text |
Show message action | At that step in the flow | No | Warn without blocking | Message may not show for API callers |
Directive options and wording can differ between Epicor 10 and Kinetic releases. Confirm in the BPM Designer for your version. Prefer data directives for rules that must apply no matter how a record is changed, and method directives for rules tied to one screen or action.
BPM inventory and risk review
Optional: a review of your BPM list before an upgrade.
Optional. The tool and every export work without this. No spam.
How to use this table
Search by directive name or use, then compare when it runs and whether it can stop the transaction. If your rule must always apply, even for DMT loads and API calls, lean toward data directives. If it only matters for a specific method such as SalesOrder.Update, a method directive is simpler and easier to test. Export the table to Excel to share as a team standard.
Method versus data directives
Method directives attach to a business object method and see the arguments and temp tables. Data directives attach to a table and fire when a record is added, updated or deleted, regardless of the route. In-Transaction directives run inside the database transaction and can roll it back, which is powerful but dangerous when slow. Standard data directives run after commit, which is ideal for notifications.
Common mistakes
Sending an email from a pre-processing directive before the save succeeds, writing heavy code inside In-Transaction directives, creating infinite loops by updating the same table from its own directive, and leaving many unused directives enabled all slow the system. Document each directive, name it clearly, and review them before every upgrade.
Frequently Asked Questions
Which directive should I use for validation?
Use a pre-processing method directive for screen or method-specific validation, or an in-transaction data directive if the rule must apply to every route that changes the record, including integrations.
Why did my email send even though the save failed?
The email likely ran in pre-processing or in-transaction logic before a later error rolled back. Move notifications to a standard data directive or post-processing so they fire only after success.
Do directives apply to REST and DMT calls?
Method and data directives generally run when the underlying business object or table is hit, so API and DMT loads can trigger them. Data directives are the most consistent. Test your specific path.
How many directives is too many?
There is no fixed number, but each one adds overhead and upgrade risk. Combine related rules, retire unused ones and keep an inventory so you know what fires on each key method.
Netray can analyze your BPM estate and flag risky or redundant directives ahead of an Epicor upgrade.
Related Tools
Epicor BPM Custom Code Block Generator
Generates a C# custom code block for an Epicor method directive that validates a field on a temp table and raises an error or message.
EpicorEpicor Business Object Service Reference
Lookup table of common Erp.BO services with their main table, primary key and standard method names.
EpicorEpicor Kinetic Upgrade Readiness Assessment
Ten questions scoring how ready your customizations, BPMs, reports and integrations are for an Epicor upgrade.
EpicorEpicor DMT Data Load Checklist
Checklist for planning and running Epicor DMT loads: prerequisites, load order, BPM impact, validation and rollback.
More Epicor tools
See all- Epicor Kinetic Customization Change Request Form Template
- Epicor Kinetic Go-Live Cutover Plan Template
- Epicor Kinetic User Access Request Form Template
- Epicor Kinetic BPM Directive Inventory Worksheet
- Epicor Kinetic Scheduled Task Register Worksheet
- Epicor Kinetic Custom Report Inventory Worksheet
- Epicor Kinetic Data Migration Mapping Worksheet
- Epicor Kinetic Data Load Effort Calculator
- Epicor Business Object Services Reference