Material approval workflow not sending email notifications to approvers

ERP Microsoft Dynamics 365
, , , , , , , ,
1

We’re facing an issue where our material approval workflow is not sending email notifications to approvers. The workflow itself is functioning - items move through approval stages correctly when users manually check their worklist in D365. However, no emails are being sent for any material approval requests.

What makes this more concerning is that SMTP test from system administration fails with a connection timeout error:


SMTP Test Failed
Connection timeout: smtp.company.com:587
Authentication: TLS 1.2
Error code: 10060

Yet the workflow history clearly shows that notifications are being generated. We can see entries like ‘Email notification queued for user John.Smith’ in the workflow tracking, but nothing actually reaches the recipients’ inboxes. We’ve verified that the email addresses in user profiles are correct and that our SMTP server is operational (other applications can send email through it without issues).

This is impacting our procurement cycle as approvers aren’t aware of pending requests. Any guidance on troubleshooting this notification failure?

system 2

Here’s a comprehensive solution that addresses all three aspects of your email notification issue:

1. No Emails Sent for Any Material Approval Requests: This indicates a systemic problem rather than workflow-specific configuration. The root cause is the failed SMTP connectivity, which prevents any emails from being delivered. However, you need to fix multiple layers:

First, verify the email distributor batch job is running: System administration > Periodic tasks > Email processing > Batch. This job must be enabled with recurrence set to run every 1-5 minutes. If it’s disabled or has failed executions, enable it and set appropriate recurrence.

Second, check the workflow notification configuration: Organization administration > Setup > Workflow > Workflow parameters. Ensure ‘Notifications’ tab has ‘Send notifications as email messages’ enabled and the email template is configured correctly.

2. SMTP Test from System Admin Fails: The connection timeout on port 587 with TLS 1.2 indicates either network blocking or authentication issues. Here’s the systematic fix:

  • Verify network connectivity from AOS server: Log into your AOS server and run Test-NetConnection -ComputerName smtp.company.com -Port 587. If this fails, it’s a firewall issue.

  • Check TLS/SSL requirements: Port 587 requires STARTTLS. Go to System administration > Setup > Email > Email parameters. Under SMTP settings, ensure ‘Enable Secure Sockets Layer (SSL)’ is checked and ‘SMTP port’ is 587.

  • Validate authentication credentials: Your SMTP server likely requires authentication. In Email parameters, verify the ‘User name’ and ‘Password’ fields are populated with valid credentials. Important: These credentials might need to be for a service account, not a personal mailbox, depending on your SMTP relay configuration.

  • Update to modern authentication if needed: If your organization uses Office 365/Exchange Online, you may need to switch from basic authentication to OAuth. This requires registering an app in Azure AD and configuring the certificate-based authentication in D365.

3. Workflow History Shows Notifications Generated: This confirms the workflow engine is functioning correctly and attempting to queue emails. The problem is in the email delivery layer. To resolve:

  • Clear the email queue backlog: Before fixing SMTP, you have queued emails that will attempt to send once connectivity is restored. Query SysEmailTable to see pending emails. After fixing SMTP, these will be processed by the email distributor batch job.

  • Verify email template content: Navigate to Organization administration > Setup > Organization email templates. Find the template used for material approvals (usually ‘Workflow approval’). Ensure the template has valid content and the ‘From’ address is properly configured.

  • Test with manual email: After fixing SMTP settings, go to System administration > Setup > Email > Email parameters and use the ‘Test email’ button with a valid recipient. This will confirm SMTP connectivity before testing the full workflow.

Complete Resolution Steps:

  1. Work with network team to verify firewall rules allow AOS servers to connect to smtp.company.com:587 with TLS passthrough
  2. Update email parameters with correct SMTP settings and valid authentication credentials
  3. Verify email distributor batch job is enabled and running every 1-5 minutes
  4. Test SMTP connectivity using the built-in test function
  5. Trigger a test material approval workflow and monitor SysEmailTable for email generation
  6. Check recipient inbox and spam folders for the test notification
  7. If still failing, enable email logging in System administration > Setup > Email > Email parameters > Advanced settings > ‘Log email activity’ to capture detailed errors

Once SMTP connectivity is confirmed working, the queued notifications should start flowing within minutes as the email distributor batch job processes the backlog. All future material approval workflows will then send notifications successfully.

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

3

The SMTP timeout is your primary issue. Even though other applications can connect to your SMTP server, D365 has specific requirements for email relay. Check if your SMTP server requires authentication and if so, verify that the credentials configured in D365 System parameters are correct and haven’t expired. Also confirm that the AOS server’s IP address is whitelisted on your SMTP relay.

4

I checked with our network team and the AOS servers are whitelisted on the SMTP relay. The credentials look correct in the system parameters, but I’m not sure how to verify if they’ve expired. Is there a way to test SMTP authentication separately from the full email send test?

5

The connection timeout on port 587 suggests a firewall or network routing issue between your AOS environment and the SMTP server. Port 587 requires explicit TLS negotiation which can be blocked by certain firewall configurations even if port 25 works fine. Have your network team verify that outbound connections from the AOS servers to smtp.company.com on port 587 are allowed with proper TLS passthrough. You can test this using telnet or PowerShell’s Test-NetConnection from the AOS server itself.

sureshdev 6

Confirmed this resolves the issue — enabling the Email distributor batch job under System administration > Periodic tasks > Email processing with a 1-minute recurrence immediately restored approval notifications.

7

Beyond the network connectivity, check the email distributor batch job. This is what actually sends the queued email notifications. Go to System administration > Inquiries > Batch jobs and search for ‘Email distributor batch job’. Verify it’s enabled and running on a regular schedule (should be every few minutes). If this job is stopped or failing, emails will queue up but never send, which matches your symptom of notifications being generated but not delivered.

8

I want to add that the workflow notification configuration has multiple layers. Even if SMTP works, check Organization administration > Setup > Organization email templates. Make sure the material approval workflow is mapped to a valid email template and that template is active. Also verify in Workflow configuration that the notification step is set to ‘Send email’ and not just ‘Add to worklist’. Sometimes during workflow setup, notifications get configured for worklist only.

9

Check the SysEmailTable directly. You can query this table to see if email records are being created and what their status is. If emails are stuck in ‘Waiting’ status, it’s definitely the email distributor batch job. If they’re showing as ‘Failed’, you’ll see the actual error message which will point you to whether it’s authentication, network, or configuration related.