Fix Oracle EBS Workflow Notification Mailer Not Sending Emails
Oracle EBS Workflow Notification Mailer not sending emails
Also searched as
- Workflow Notification Mailer status Suspended OAM
- EBS workflow emails not going out
- Notification Mailer error EBS Workflow Manager
- workflow mailer stuck EBS after mail server change
Short answer
When EBS notifications stop reaching inboxes, check the mailer status in Oracle Applications Manager (OAM) Workflow Manager first - a Suspended or Error status almost always points at an SMTP or IMAP connectivity or credential problem introduced by a mail server change, not at Workflow itself. Fix the mail server configuration, restart the mailer component, and requeue the backlog.
Applies to: EBS 12.1 and 12.2 (Oracle Workflow Java based Notification Mailer)
How to diagnose and restart a stuck Notification Mailer
- 1Log into Oracle Applications Manager (OAM) and go to Workflow Manager > Notification Mailers - check the status column for Running, Suspended, Down, or Error.
- 2Open the mailer's log from the Component Status page; Java stack traces here usually name the exact SMTP or IMAP failure (authentication, connection refused, SSL handshake).
- 3Confirm the outbound (SMTP) and inbound (IMAP) server settings under the mailer's Configuration > Advanced tab still match what the mail team actually runs - credentials, port, and SSL/TLS requirements change more often than people update EBS for.
- 4Test raw connectivity from the apps tier with telnet or openssl s_client to the SMTP/IMAP host and port before assuming the mailer configuration is wrong.
- 5If the mail server now requires TLS/SSL where it previously did not, update the mailer's Advanced configuration and, if needed, import the mail server certificate into the Java keystore used by the mailer JVM.
- 6Restart the Notification Mailer component from OAM (Stop then Start) after any configuration change - most settings do not take effect on a running mailer.
- 7Once mail flow resumes, check for a backlog in Workflow Administrator Web Applications > Status Monitor to find notifications stuck in Open or Error status and requeue or reassign them.
Why mailers go from Running to Suspended
Oracle Workflow suspends a mailer automatically after repeated processing failures to avoid spamming the log and hammering a broken mail server - it is a protective behavior, not the root cause. The real cause is almost always outside EBS: a mail server migration, a password rotation, a new firewall rule blocking the apps tier, or an SSL certificate that expired on the mail host.
Because the Notification Mailer is a background Java process managed through the Workflow Java Container rather than a Forms or concurrent manager process, its log detail is easy for EBS admins to overlook compared to the more familiar concurrent manager logs they check daily. OAM's Component Status page is the fastest place to see the actual underlying exception rather than digging through generic Workflow Engine logs that rarely mention the mailer at all.
SSL/TLS and authentication changes are the usual trigger
Corporate mail teams routinely tighten SMTP and IMAP security - enforcing TLS everywhere, rotating a shared service account password, or retiring legacy basic authentication in favor of modern auth - without realizing an EBS Notification Mailer still depends on the old configuration until it stops working. When mail suddenly stops after a change made entirely outside the EBS team, check the mail server's own change log first before spending time troubleshooting Workflow configuration that has not actually changed.
If TLS is newly required, the mailer's underlying Java process needs the mail server's certificate imported and trusted in its keystore, and the Advanced configuration tab needs the SSL/TLS options explicitly enabled with the correct port, commonly 587 or 465 for SMTP and 993 for IMAPS. Skipping the keystore import is the single most common reason a mailer configured with the right hostname and port still fails the handshake.
Clearing the backlog after the fix
Notifications generated while the mailer was down do not disappear - they simply queue up in WF_NOTIFICATIONS and WF_MAIL_STATUS waiting to be sent. Once connectivity is restored, the mailer processes the backlog automatically in the background, but very large backlogs built up over hours or days can take real time and may need a manual nudge through the Workflow Administrator Status Monitor, or by bouncing the mailer again after the initial catch-up run.
Watch the mailer log closely during catch-up for the same error recurring rather than assuming the fix is complete once the status shows Running again. If authentication or TLS is only partially fixed, the mailer can successfully drain a handful of messages before suspending a second time, which looks like real progress at first glance but actually leaves the bulk of the backlog stuck behind it.
Common pitfalls
- !Assuming the problem is inside Workflow or EBS when the real change happened on the mail server side and nobody told the EBS team.
- !Changing the mailer configuration but forgetting to restart the component - most settings only apply on a fresh start.
- !Not importing the mail server's SSL certificate into the mailer's Java keystore after TLS was newly enforced, causing repeated handshake failures.
- !Overlooking the backlog after the fix - notifications queued during the outage need to actually process, not just stop erroring.
- !Editing WF_NOTIFICATIONS or WF_MAIL_STATUS directly in SQL to clear a backlog instead of letting the mailer or Status Monitor process it correctly.
How an ERP-grounded AI assistant handles this
ERPray grounded on Oracle Workflow can read the mailer's Java log alongside WF_NOTIFICATIONS and tell you, in one pass, whether the failure is authentication, TLS, or connectivity - and how many notifications are stuck and for which users - so the EBS admin can hand the mail team a precise ask instead of a vague emails are not going out ticket.
Frequently asked questions
Why did the mailer status change to Suspended with no EBS change made?
Workflow automatically suspends a mailer after a run of repeated send failures, purely as a safeguard against hammering a broken mail server or flooding the log. The trigger for those failures is almost always external to EBS - a mail server change, an expired or rotated password, or a newly enforced TLS requirement - not a change made inside EBS itself.
Do I need to restart the mailer after every configuration change?
Yes, in almost every case. The Notification Mailer runs as a long-lived Java container process, and most configuration changes made through OAM, including server address, port, and SSL/TLS settings, only take effect the next time the mailer component is stopped and started again, not immediately on save.
How do I clear a large notification backlog quickly?
Fix the underlying connectivity, credential, or TLS issue first, then restart the mailer and let it process the queued notifications automatically rather than intervening manually. Use the Workflow Administrator Web Applications Status Monitor to reassign or close any notifications that are genuinely no longer relevant once the backlog has mostly cleared.
Can a firewall change cause this even if the mail server itself is fine?
Yes. A new firewall rule or network segmentation between the apps tier and the mail server produces the same Suspended or Error symptoms as a credential problem - test raw connectivity with telnet or openssl before assuming it is a Workflow configuration issue.
Related
Fix FRM-40735: WHEN-VALIDATE-RECORD Trigger Raised Unhandled Exception ORA-06508
FRM-40735 with ORA-06508 almost always means a PL/SQL package used by the form was recompiled while your session still held the old cached state, or the trigger's own exception handling does not trap a real data error. Exit the form completely and re-enter it; if the error repeats for all users, recompile invalid objects on the database and check for a bad custom trigger.
Error fixOracle EBS Concurrent Manager Will Not Start: How to Fix It
A concurrent manager that will not start in Oracle EBS is almost always one of three things: the node registered in FND_NODES no longer matches the actual hostname (common after cloning), stale OS processes are blocking a fresh start, or the database and listener the manager connects to are unreachable. Check the internal manager log, verify the node name, clear stale processes, and restart with adcmctl.sh.
Error fixFix ORA-01555: Snapshot Too Old in Oracle EBS Concurrent Requests
ORA-01555 in a concurrent request means the program tried to read data from undo that has already been overwritten, usually because the report or custom PL/SQL ran long enough, or committed often enough mid-cursor, that the undo tablespace could not retain the needed read-consistent image. Increase UNDO_RETENTION and undo tablespace size first, then review the program for commits inside open cursor loops.
Error fixFix adop phase=prepare Failures in EBS 12.2 Online Patching
An adop prepare phase failure in EBS 12.2 almost always means the patch edition (patch file system) and the run edition are out of sync, or a previous cutover or cleanup did not complete cleanly. Read adop.log for the specific worker error, resync the file systems with adop phase=fs_clone if needed, and never start a new patch cycle on top of an unfinished one.
How-toHow to Import AP Invoices in Oracle EBS with Payables Open Interface Import
Load invoice header and line data into AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE, then run the Payables Open Interface Import concurrent program to create standard invoices in Oracle Payables. Rows that fail validation land in AP_INTERFACE_REJECTIONS with a specific reject reason you can query directly, without opening the Invoice Workbench.
How-toHow to Use Forms Personalization in Oracle EBS (No CUSTOM.pll Needed)
Forms Personalization lets you change field properties, set defaults, run built-ins and show messages on any Oracle Forms screen through Help > Diagnostics > Custom Code > Personalize, with no custom library or forms compile required. Rules are stored per form and responsibility in FND_FORM_CUSTOM_RULES and apply at runtime for every user who opens that form.
AI for ERPAI for Oracle E-Business Suite, Without Leaving On-Prem
Add AI to Oracle E-Business Suite 12.2 without moving off-prem. Query concurrent programs, interface tables, and AP/PO data with a private LLM. See how.
AI for ERPAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
Stuck on Oracle E-Business Suite (EBS)?
Talk to engineers who work inside Oracle E-Business Suite (EBS) every week, and who build private AI that answers these questions from your own ERP data.