Explain Database Triggers in EBS Customizations in Oracle Applications

16 / 60

PL/SQLintermediate

Database Triggers in EBS Customizations

Explain the appropriate and risky uses of database triggers within an Oracle EBS environment

Database triggers (row-level or statement-level, BEFORE/AFTER INSERT/UPDATE/DELETE) are occasionally used in EBS customizations to enforce custom validation or populate custom columns automatically, but they are treated with extreme caution because EBS core tables already have extensive Oracle-owned trigger logic, and adding custom triggers risks interfering with seeded behavior or breaking during patching.

Adding a custom trigger to a seeded EBS table is like splicing your own wiring into a building's fire alarm system — it might work today, but the next time the fire department (Oracle patch) services the panel, your unofficial wiring could get ripped out or cause a false alarm.

Key Concepts

Oracle's official guidance (documented in My Oracle Support notes on customization standards) is that custom triggers should never be placed directly on seeded Oracle base tables in a way that risks conflicting with seeded triggers; instead, Oracle recommends using Custom Library / CUSTOM.pll (for Forms-based validation), Business Events (for Workflow-based reactions), or extending via the appropriate public API's user hooks where available. When custom triggers genuinely are needed on custom (non-seeded) tables, they follow normal Oracle best practices: keep trigger logic minimal, avoid mutating table errors, and avoid recursive trigger chains.

never be placed directly on seeded Oracle base tablesCustom Library / CUSTOM.pllBusiness Events

A well-known interview trap is asking candidates whether they would add a trigger on AP_INVOICES_ALL to implement custom validation — the expected, correct answer is no, because Oracle's own AP APIs already fire numerous internal triggers and business logic; a custom trigger risks a mutating table exception, unpredictable firing order relative to seeded triggers, and will likely need to be re-validated (or could silently break) after every patch or upgrade.

mutating table exceptionAP_INVOICES_ALL

Understanding compound triggers (which combine BEFORE/AFTER STATEMENT and ROW timing points in one trigger body to avoid mutating table errors) is also a common advanced topic, especially for developers who must aggregate data across all rows affected by a single DML statement.

compound triggers