# Epicor BPM Directive Types Reference (Method and Data Directives) > Source: https://netray.co/tools/epicor-bpm-directive-types-reference > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Lookup table of Epicor BPM directive types, when each runs, whether it can stop a save, and typical use. ## Category epicor ## Erp Epicor Kinetic ## Audience - Epicor developer - Epicor BPM author - Epicor consultant ## Tool **Kind:** worksheet **Mode:** reference **Columns:** #### Directive type **Key:** type **Type:** text #### When it runs **Key:** fires **Type:** text #### Can stop the transaction **Key:** block **Type:** text #### Typical use **Key:** use **Type:** text #### Caution **Key:** caution **Type:** text **Rows:** **Type:** Method directive: Pre-Processing **Fires:** Before the business object method runs **Block:** Yes **Use:** Validate input, set defaults, block bad requests **Caution:** Data is not yet saved, so keep work light **Type:** Method directive: Base Processing **Fires:** In place of the standard method logic **Block:** Yes **Use:** Replace standard behavior (rare) **Caution:** Can bypass standard logic; hard to upgrade **Type:** Method directive: Post-Processing **Fires:** After the method completes **Block:** Yes (exception rolls back if in transaction) **Use:** Notifications, follow-up updates, integrations **Caution:** Exceptions here can confuse users **Type:** Data directive: In-Transaction **Fires:** Inside the database transaction when a record changes **Block:** Yes (rolls back the change) **Use:** Rules that must be all-or-nothing with the save **Caution:** Long-running code holds locks **Type:** Data directive: Standard **Fires:** After the change is committed **Block:** No **Use:** Alerts, emails, logging, async follow-up **Caution:** Cannot undo the change **Type:** Function directive **Fires:** When a library function executes **Block:** Depends on code **Use:** Hook into reusable function calls **Caution:** Check availability in your version **Type:** Custom code block **Fires:** As a step within a directive **Block:** Yes if it throws **Use:** Complex logic widgets cannot express **Caution:** Use RowMod filters and Company scoping **Type:** Condition widget **Fires:** Inside a directive flow **Block:** No **Use:** Branch logic on field values or changes **Caution:** Keep conditions simple and ordered **Type:** Raise exception action **Fires:** At that step in the flow **Block:** Yes **Use:** Show a user-facing error and stop **Caution:** Write clear, actionable text **Type:** Show message action **Fires:** At that step in the flow **Block:** No **Use:** Warn without blocking **Caution:** Message may not show for API callers **Notes:** 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. ## Content **Intro:** 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. **Sections:** #### How to use this table **Body:** 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 **Body:** 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 **Body:** 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. **Cta:** Netray can analyze your BPM estate and flag risky or redundant directives ahead of an Epicor upgrade. **Faq:** #### Which directive should I use for validation? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms epicor bpm directive types, epicor pre-processing vs post-processing, epicor in-transaction data directive, epicor standard data directive, epicor base processing directive, epicor bpm method directive, epicor bpm best practices, epicor bpm when to use --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json