We’re experiencing a critical issue with our ECN workflow in Windchill 12.0 CPS05 where email notifications are not being sent to reviewers when change notices are routed for approval. This has resulted in multiple missed approval deadlines over the past two weeks.
The workflow processes correctly and tasks appear in users’ work items, but the email notifications that should trigger when a review task is assigned are simply not being delivered. We’ve confirmed that our mail server configuration appears correct in the site preferences, and other system emails (like password resets) are working fine.
I’ve checked the workflow notification settings in the process definition, and notification preferences are enabled at the user level for all affected reviewers. However, no emails are being generated when ECN review tasks are created. This is impacting our change approval cycle significantly as reviewers aren’t aware of pending tasks unless they manually check their Windchill inbox.
Has anyone encountered similar notification issues with ECN workflows? Any suggestions on where else to look for configuration problems?
Based on the discussion, here’s a comprehensive solution addressing all three configuration areas:
Mail Server Configuration Fix:
The SMTP relay error indicates your mail server is rejecting workflow notification emails. This happens because workflow notifications use the sender address defined in wt.properties (wt.mail.from property), which differs from system administrative emails. You need to coordinate with your mail server administrator to whitelist this sender address for relay access, or configure SMTP authentication if your server requires it.
Workflow Notification Settings:
Verify your ECN workflow template has notifications properly configured. In Workflow Administrator, open your ECN process template and confirm each review activity node has:
Also ensure notification agents are running in MethodServer. Check Method Server > Notification Queue Manager to confirm agents are active and processing queued notifications.
User Notification Preferences:
Even with correct server and workflow settings, individual user preferences can block emails. Have affected users verify their notification preferences under My Profile > Notification Preferences. The ‘Workflow Task Assignment’ notification type must be enabled with email delivery selected (not just inbox).
Post-Fix Cleanup:
After resolving the relay issue, clear the backed-up notification queue:
Navigate to Site > Utilities > Notification Report
Identify failed notifications in ‘Pending’ or ‘Error’ status
Use the Notification Queue Manager to either retry or purge old failed notifications
Monitor the MethodServer logs to confirm new notifications are being sent successfully
Test the complete flow by creating a test ECN and routing it through the workflow. Verify that review task assignment triggers immediate email delivery to the assigned reviewer. The relay access fix should resolve your immediate issue, but verifying all three configuration areas ensures robust notification delivery going forward.
This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen this before. First thing to check - go to Site > Utilities > Notification Report and run a test for one of the affected users. This will show you if notifications are being queued but not sent, or if they’re not being generated at all. Also verify the MethodServer logs for any JavaMail exceptions around the time tasks are assigned.
Check your workflow template’s notification settings specifically. In the ECN workflow process, each activity node should have the ‘Send Notification’ checkbox enabled. I’ve seen cases where workflow templates were migrated or updated and these settings got disabled. Navigate to the workflow administrator, open your ECN process template, and inspect each review activity node to confirm notifications are configured. Also check if notification agents are running properly in your MethodServer.
Thanks for the suggestions. I ran the Notification Report and it shows notifications are being queued but marked as ‘Pending’ indefinitely. The MethodServer logs show ‘SMTPSendFailedException: 550 Relay access denied’ errors. This is strange because other system emails work fine. Could this be related to specific sender addresses used by workflow notifications versus other system emails?
That relay error is your smoking gun. Workflow notifications use a different sender address than system administrative emails. Check your wt.properties file for the ‘wt.mail.from’ property and compare it to what your mail server allows as authenticated senders. Your mail server is rejecting the workflow notification emails because the sender address isn’t authorized to relay through it. You’ll need to either update the sender address in Windchill or add it to your mail server’s relay whitelist.
Tom’s right about the relay issue. Also worth checking if you have authentication enabled on your SMTP server. Some organizations require SMTP authentication for workflow notifications but not for system emails sent from the admin context.
Adding to the previous responses - once you fix the relay issue, you should also verify your notification queue isn’t backed up with failed messages. Sometimes these need to be manually cleared or they can cause ongoing delivery delays even after the root cause is resolved.