# Epicor BPM TxScope: Standard vs In-Transaction Directives and When Functions Need a Transaction

> Source: https://netray.co/erp-help/epicor-bpm-txscope-transaction-scope
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

A transaction scope groups database writes so they commit or roll back together. In Epicor BPM, a Standard directive runs outside the business object's database transaction, while an In-Transaction directive runs inside it, so an exception rolls back the whole save. In custom code you open your own scope with IceContext.CreateDefaultTransactionScope and call Complete.

## Kind

advanced

## System

epicor

## Erp

Epicor Kinetic

## Module

BPM / Transactions

## Query

epicor bpm txscope

## Alternate Queries

- epicor bpm transaction scope
- epicor bpm scope
- epicor bpm standard vs in transaction
- epicor function requires transaction

## Applies To

Epicor Kinetic and 10.x BPM and Epicor Functions. Behaviour of Standard versus In-Transaction depends on the method and processing stage, so read your release documentation for details.

## Steps

### How to choose and use transaction scope

**Items:**

- Decide whether your change must roll back if the main save fails. If yes, use an In-Transaction directive; if you are only validating or sending a notification, Standard is enough.
- In Method Directive Maintenance, set the directive type when creating it. It cannot always be changed afterward, so recreate if needed.
- For your own writes in custom code, wrap them in a transaction scope block.
- Call Complete on the scope only when every step succeeded. Leaving without Complete rolls back.
- Keep the scope short. Do lookups before it, writes inside it.
- Avoid calling slow services, email or web requests inside a transaction.
- Test a failure case on purpose and confirm that data rolled back.

## Sections

### Standard versus In-Transaction

**Body:**

Business object methods like Update open a database transaction around the save. An In-Transaction directive runs inside that transaction. If it throws, the entire save rolls back, which is the safe choice for rules that must stay consistent with the saved data, such as updating a related record at the same moment.

A Standard directive runs outside the database transaction. Pre-processing standard directives are ideal for validation and messages. Post-processing standard directives run after commit, so a failure there does not undo the save, and any writes they make are separate. In-transaction directives hold locks for longer, so keep them quick.

### TxScope in custom code and functions

**Body:**

In custom code, create a scope with the Epicor context helper and wrap the writes. Without Complete, the scope rolls back when disposed. If the code runs inside an In-Transaction directive, the outer transaction still controls the final commit.

Epicor Functions run in their own context. Depending on your release, the function definition offers a setting that says whether it requires a transaction, and calling code can add its own scope. If a function writes several tables, make it transactional so partial writes cannot remain. Check the function options in Function Maintenance for your release.

**Code:**

using (var txScope = IceContext.CreateDefaultTransactionScope())
{
    var rec = Db.UD01.Where(u => u.Company == Session.CompanyID && u.Key1 == "A").FirstOrDefault();
    if (rec != null)
    {
        rec.Number01 = rec.Number01 + 1;
        Db.Validate();
    }
    txScope.Complete();
}

### Rollback and locking pitfalls

**Body:**

Long transactions block other users. If you query a big table inside an In-Transaction directive, other sessions wait for locks until commit. Move reads out and keep only the writes inside.

Rollback also reverses your writes but not side effects such as emails, files written to disk or calls to external systems. Do those after commit in a Standard post-processing directive. Nested updates to the same record can trigger record-in-process style errors; see the update vs UpdateExt page.

## Pitfalls

- Forgetting Complete, so the writes silently roll back.
- Sending email or calling an API inside a transaction, then rolling back.
- Running large searches inside an In-Transaction directive and blocking users.
- Using a Standard post-processing directive for writes that must be atomic with the save.
- Swallowing exceptions in custom code so the transaction commits a partial change.

## Ai Angle

Transaction choices are easy to get wrong, so a reviewer helps. An assistant can read a directive and point out external calls inside a transaction, a missing Complete, or a long query in an In-Transaction block. It reports; your developer decides.

## Faq

### What is the difference between Standard and In-Transaction directives in Epicor?

**Answer:** Standard directives run outside the business object's database transaction. In-Transaction directives run inside it, so an exception rolls back the save. Choose In-Transaction for rules that must be atomic with the data.

### Do I always need a TxScope in BPM custom code?

**Answer:** No. If your code is only validating, you do not. Use a scope when you write more than one record and need them to commit or roll back together, outside an existing In-Transaction directive.

### When does an Epicor function need a transaction?

**Answer:** When it changes several records that must stay consistent. Check the function options in your release and test a failure to confirm rollback.

### Why did my data roll back?

**Answer:** Either an exception occurred inside the transaction, or the scope was disposed without calling Complete. Check the server log for the exception.

## Search terms

epicor bpm txscope, epicor bpm transaction scope, epicor in-transaction directive, epicor standard vs in transaction, epicor function requires transaction, epicor bpm rollback, epicor createdefaulttransactionscope, epicor bpm locking

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json