Automated workflow fails to send email notifications on task

CRM Adobe Experience Cloud
, , , , , , , ,
1

Our approval workflow automation is broken - it’s not sending email notifications when tasks are assigned to approvers. The workflow itself progresses correctly through all stages, but users aren’t getting notified, causing significant delays in our approval process.

I’ve verified that the workflow notification step is configured in the workflow model, and the SMTP server settings appear correct in the system configuration. The email template reference looks valid too, but clearly something isn’t working.

This started happening after our IT team updated the mail server infrastructure last month. Before that, notifications worked perfectly. Now approvers only discover they have pending tasks when they manually check the workflow dashboard, which defeats the purpose of automation.

The workflow logs don’t show any obvious errors related to email sending - it’s like the notification step is just being skipped silently. Has anyone dealt with email notification failures in AEM workflows where the workflow itself runs fine but notifications just don’t get sent?

system 2

Let me provide a complete solution covering all three aspects of your notification failure:

1. Workflow Notification Step Configuration: First, verify your workflow model’s notification step is properly configured. Open the workflow in the Workflow Model Editor:

  • Locate the ‘Participant Step’ where approvers are assigned
  • Check that ‘Notify User via Email’ is enabled in the step properties
  • Verify the ‘Email Subject’ and ‘Email Body’ fields are populated
  • Confirm the ‘Notify’ option is set to ‘Assignee’ or appropriate participant group

The fact that your workflow progresses correctly but skips notifications suggests the notification step might be configured but the underlying email service is failing. The workflow engine catches email failures silently to prevent workflow interruption - that’s why you don’t see errors in workflow logs.

2. SMTP Configuration After Infrastructure Change: Your mail server migration from port 25 to port 587 with TLS requires comprehensive SMTP reconfiguration. Navigate to OSGi Console > Configuration > Day CQ Mail Service:

Update these settings to match your new mail infrastructure:

  • SMTP Server Hostname: mail.company.com (verify this is correct)
  • SMTP Server Port: 587 (changed from 25)
  • SMTP over TLS: ENABLED (critical for port 587)
  • SMTP Authentication: ENABLED (most modern mail servers require this)
  • SMTP User: [service account username]
  • SMTP Password: [service account password]
  • From Address: noreply@company.com (ensure this is an allowed sender)

Additionally, in the ‘Additional Properties’ field, add:


mail.smtp.starttls.enable=true
mail.smtp.starttls.required=true
mail.smtp.ssl.protocols=TLSv1.2

The starttls.required=true setting is important - it forces TLS negotiation and will fail explicitly if TLS can’t be established, giving you clearer error messages.

Network and Firewall Considerations: After mail server migration, verify:

  • Your AEM server’s IP address is whitelisted on the new mail server
  • Outbound port 587 is open on the AEM server’s firewall
  • DNS resolution works correctly for mail.company.com from the AEM server
  • If using a relay, ensure relay authentication is configured

Test connectivity from the AEM server command line:


telnet mail.company.com 587

You should see a connection established. If it times out, you have a network/firewall issue to resolve with IT.

3. Email Template Reference Validation: While email templates aren’t affected by SMTP changes, verify they’re still valid:

  • Navigate to /etc/workflow/notification/email/default in CRXDE
  • Check that your workflow’s email template exists and is readable
  • Common template paths:
    • /etc/workflow/notification/email/default/html.txt (HTML format)
    • /etc/workflow/notification/email/default/txt.txt (Plain text fallback)

Verify template placeholders are correct:

  • ${workflowTitle} - workflow name
  • ${workItem.workflowTitle} - task title
  • ${payloadPath} - content path
  • ${recipientName} - assignee name

If you have custom email templates, ensure they reference valid workflow variables. Template errors can cause silent notification failures.

Testing and Verification: After updating SMTP configuration:

  1. Test Mail Service Directly:

    • In Day CQ Mail Service config, use ‘Send Test Email’ button
    • Enter a test recipient address
    • If this fails, SMTP config is still incorrect
    • Check error.log immediately after test for detailed error messages

  2. Test Workflow Notification:

    • Create a simple test workflow with just a notification step
    • Assign it to yourself
    • Trigger the workflow
    • Check if you receive the notification email

  3. Monitor Logs:

    • Watch error.log while testing: `tail -f error.log | grep -i mail
    • Look for authentication errors, connection timeouts, or TLS handshake failures
    • Common errors after migration: ‘Authentication failed’, ‘TLS required’, ‘Relay access denied’

Common Post-Migration Issues:

  • Authentication Failure: New mail server requires credentials but service account not configured
  • TLS Version Mismatch: Old TLS 1.0/1.1 disabled on new server, need to specify TLSv1.2+
  • Sender Policy: New mail server restricts ‘From’ addresses - ensure noreply@company.com is allowed
  • Rate Limiting: New server has stricter rate limits - if bulk notifications, may need throttling

Long-term Monitoring: Set up monitoring for email notification health:

  • Create a scheduled test workflow that sends notification daily
  • Monitor delivery success rate
  • Alert if test notifications fail
  • Document SMTP configuration in runbook for future migrations

Once you’ve updated the SMTP configuration with TLS settings and verified connectivity, your workflow notifications should resume. The key is ensuring all three components align: the workflow notification step is configured, SMTP service is properly connected with TLS, and email templates are valid. Test thoroughly before announcing to users that notifications are working again.

This draft is based on general Adobe Experience Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Check the Day CQ Mail Service configuration in the OSGi console. After mail server changes, the SMTP settings often need updating. Verify the hostname, port, and authentication credentials match your new mail infrastructure. Also check if TLS/SSL settings changed - that’s a common issue after mail server migrations.

4

Silent notification failures usually mean the email service is failing but not throwing exceptions that bubble up to workflow logs. Check the AEM error.log file directly - search for ‘mail’ or ‘smtp’ entries around the time workflows run. You’ll likely find connection errors or authentication failures there. Also verify your mail server allows connections from the AEM server IP address - firewall rules often get updated during infrastructure changes.

5

Found some errors in error.log: ‘Could not connect to SMTP host: mail.company.com, port: 25’. Our IT team mentioned they moved to port 587 with TLS. I updated the port in Day CQ Mail Service config but still no emails. Do I need to enable TLS explicitly somewhere? And how do I verify the email template reference is still valid after these changes?

7

Yes, port 587 requires explicit TLS configuration. In the Day CQ Mail Service OSGi config, you need to check ‘SMTP over TLS’ and might need to set ‘SMTP Port’ to 587. Also add ‘mail.smtp.starttls.enable=true’ to the properties. For authentication, if your new mail server requires it, enable ‘SMTP authentication’ and provide credentials. Email templates are separate from SMTP config, so template references shouldn’t be affected by infrastructure changes.

8

Don’t forget to test the mail configuration directly from the OSGi console after making changes. There’s usually a ‘Test Connection’ or ‘Send Test Email’ option in the Day CQ Mail Service config. This will confirm SMTP connectivity before you debug the workflow notification step itself.