Method Directive vs. Data Directive in Epicor Kinetic BPM: which one do you need?

Key facts

• BPM is Epicor's server-side rules engine. BPM logic runs on the server, not in the user's browser.
• Method Directives are attached to a business object method (for example, Erp.BO.SalesOrder.MasterUpdate).
• Data Directives are attached to a database table and its write events (add, update, delete).
• Both are managed in the BPM directive screens (Method Directives Maintenance and Data Directives Maintenance).
• Once enabled, a directive affects every user and every client (Kinetic browser UI, DMT, REST API, EDI) that triggers it.
• Changing the screen (Application Studio) does not enforce a rule on the server. BPM does.

The two types side by side

Method Directive stages (Pre, Base, Post)

Method Directives have three timing stages around the business object method:

• Pre-Processing: runs before Epicor's core method executes. This is the standard choice for validation (stopping a save with an Raise Exception widget when required conditions are not met) or modifying input dataset fields before Epicor processes them.
• Base Processing: replaces Epicor's standard method execution entirely. Avoid creating Base Processing directives in customer environments—overriding Epicor's core business object logic can break standard ERP behavior and upgrades.
• Post-Processing: runs after Epicor's core method has finished. This is commonly used to enrich output data returned to the screen or trigger follow-up logic after the method succeeds.

Data Directive types (In-Transaction vs. Standard)

Data Directives do not use Pre-Processing or Post-Processing. Instead, they come in two distinct types:

• In-Transaction: runs inside the SQL database transaction, evaluating one modified row at a time before the change is committed. Use In-Transaction Data Directives when you need to set field values on the row being saved or raise an exception that rolls back the database write. Keep In-Transaction logic as fast and lightweight as possible.
• Standard: runs once per batch after the database transaction has been committed to SQL. Because the data is already saved, a Standard Data Directive cannot block the save or directly change the committed row buffer without calling another update. Use Standard Data Directives for post-commit side effects such as sending BPM email alerts, writing to audit logs, or triggering external integrations.

How to choose (a simple decision path)

1. "I want to validate or modify parameters when a specific business action runs." Use a Pre-Processing Method Directive on the exact method called by that action (always run a client/browser trace first to verify which method is actually called).

1. "A field or record must always follow a rule no matter which method, screen, DMT import, or integration writes the row." Use an In-Transaction Data Directive on the table.

1. "I want to send an email or trigger an integration only after a table change is safely committed to the database." Use a Standard Data Directive on the table (or a Post-Processing Method Directive if tied to one specific method). See our BPM email alerts article.

1. "The same logic is needed in several directives or screens." Put the logic in an Epicor Function (EFx) and invoke it from your directives.

1. "I only want to change how a screen looks." That is not a BPM job. Use Application Studio.

A worked example (and the MasterUpdate trap)

Requirement: "Do not allow a sales order line to be saved without a required reference value."

• The Method Directive approach (and common trap): If you put a Pre-Processing Method Directive on SalesOrder.Update, you may discover that users saving orders in the Kinetic screen bypass your rule completely. Why? Because the Sales Order screen typically calls SalesOrder.MasterUpdate rather than SalesOrder.Update (whereas DMT or certain REST calls may call Update directly). Always trace the screen first if you use a Method Directive.
• The Data Directive approach: If the rule must hold unconditionally—whether the line is created via SalesOrder.MasterUpdate in the browser, SalesOrder.Update in DMT, Counter Sales, or EDI—an In-Transaction Data Directive on Erp.OrderDtl (checking Added or Updated rows) guarantees that no row is committed without the required value.

Either way, document the business reason, the condition, the exact message shown to the user, and who approved the rule.

Common problems

1. Infinite loops. A directive that calls a business object or updates the same table it is attached to can trigger itself repeatedly. Always add a tight change condition (such as "field X changed from any to another") rather than firing unconditionally on every update.

1. Heavy logic inside In-Transaction Data Directives on busy tables. An In-Transaction Data Directive on a high-volume table like Erp.PartTran, Erp.LaborDtl, or Erp.OrderDtl runs inside the open SQL transaction. Slow queries or external API calls inside an In-Transaction directive hold database locks and slow down everyone.

1. Putting Method Directives on the wrong method without tracing. Epicor business objects often have multiple update methods (such as Update, UpdateExt, and MasterUpdate). Always capture a browser network trace or server trace to confirm the exact method before building a Method Directive.

1. Poor error messages. Users should be told clearly what is wrong and how to fix it. "Error" is not a useful message.

1. Editing live without a backup. Export the directive or solution before editing, and uncheck Enabled rather than deleting a directive when you need to roll back quickly.

Good habits

• Give every directive a clear name and a group name, plus a description that states its business purpose.
• Keep a register: directive name, type (Method Pre/Post or Data In-Tran/Standard), target method or table, owner, and date.
• Keep each directive small and focused on one rule, or offload complex reusable logic to an Epicor Function.
• Test the success path, the failure path, DMT/REST entry points, and missing or empty data.
• Include BPM directives in your pre-upgrade regression testing.

FAQ

What is the difference between a Method Directive and a Data Directive in Epicor?

A Method Directive runs when a specific business object method (like SalesOrder.MasterUpdate) is called. A Data Directive runs whenever a record in a specific database table (like Erp.OrderDtl) is added, updated, or deleted.

What is the difference between an In-Transaction and a Standard Data Directive?

An In-Transaction Data Directive runs row-by-row inside the open database transaction before changes are committed, allowing you to validate and block saves or set field values. A Standard Data Directive runs once per batch after the transaction is committed, making it ideal for notifications and post-save actions.

Does a Method Directive have an In-Transaction stage?

No. Method Directives have Pre-Processing, Base Processing, and Post-Processing stages. In-Transaction is a Data Directive type.

Why didn't my Method Directive on Update fire when I clicked Save in the Kinetic screen?

Many Epicor screens call specialized wrapper methods such as MasterUpdate or UpdateExt instead of the basic Update method. Run a network trace in your browser's developer tools to see the exact business object method the screen invokes.

Can one directive call shared logic?

Yes. Best practice in Epicor Kinetic is to build reusable server-side logic in an Epicor Function (EFx) and invoke that function from your Method or Data Directives.

References

Cross-check against official Epicor documentation matching your release and hosting model:

• Epicor Kinetic help: Business Process Management (BPM) overview
• Epicor Kinetic help: Method Directives and Data Directives
• Epicor Kinetic help: Epicor Functions framework