We’re experiencing a critical issue with our phase gate workflow in ENOVIA R2022x where stakeholders are not receiving notifications when projects transition between phases. The workflow executes successfully and the phase changes are recorded, but no emails are sent to the designated reviewers and approvers.
I’ve verified the notification recipient configuration in the workflow template, and all the correct roles and users are assigned. The mail server settings appear correct in site.xconf, but I’m not entirely sure what else to check. We’ve had several missed deadlines because approvers didn’t know they had pending reviews.
Has anyone encountered similar notification failures in project management workflows? What should I check in the agent logs to diagnose this? Any guidance on troubleshooting the mail server connection would be appreciated.
Based on the symptoms you’re describing, this is likely a multi-factor issue involving all three areas you need to investigate systematically.
Notification Recipient Configuration:
First, verify the workflow template’s notification activity configuration. Navigate to Business Administration > Workflow Administrator and open your phase gate workflow template. Examine each transition that should trigger notifications and confirm the ‘Send Notification’ activity exists with correct recipient roles. Check that role assignments resolve to actual users by using the ‘Test Role Assignment’ feature. Verify that distribution lists or teams are properly configured if you’re using those instead of individual roles.
Mail Server Setup:
The mail server configuration requires several components to work correctly. In site.xconf, verify these critical properties: wt.mail.mailhost (SMTP server address), wt.mail.from (sender email address), and wt.mail.smtp.auth (if authentication is required). Test the SMTP connection independently using telnet or a mail testing utility from the ENOVIA server to rule out network/firewall issues. Check MethodServer logs specifically for javax.mail exceptions around the time workflows execute. If using authenticated SMTP, verify credentials are correct and the account isn’t locked.
Agent Log Review:
Enable detailed logging for notification processing by adding these properties to log4j.properties: log4j.logger.wt.queue.ProcessingQueue=DEBUG and log4j.logger.wt.notification=DEBUG. Restart the Method Server and trigger a phase transition. Review MethodServer logs for entries showing notification queue processing. Look for patterns like ‘Notification queued’, ‘Processing notification’, and ‘Notification sent successfully’. If you see queuing but no sending, the issue is in mail server connectivity. If you don’t see queuing at all, the workflow configuration isn’t triggering the notification activity.
A common root cause is the notification agent being disabled or the queue being paused. Check Site > Utilities > Background Method Objects and verify the notification agent shows ‘Enabled’ status with recent execution timestamps. If the agent hasn’t run in the timeframe when your workflows executed, that’s your smoking gun.
One often-overlooked aspect: verify the notification templates themselves are published and active. Draft templates won’t send notifications even if everything else is configured correctly. Also confirm that your phase gate workflow is using the correct template version - sometimes multiple versions exist and the workflow references an outdated one.
Implement this diagnostic approach systematically and you should identify where the notification chain is breaking.
This draft is based on general ENOVIA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
First thing to check is whether the Method Server queue is processing notification tasks. Go to Site > Utilities > Queue Management and look for any stuck entries in the notification queue. Sometimes the queue gets backed up and notifications pile up without being sent.
I’ve seen this before. Check your MethodServer logs for any SMTP connection errors. The mail server configuration might look correct in site.xconf, but there could be authentication issues or firewall rules blocking the connection. Look for entries like ‘javax.mail.AuthenticationFailedException’ or ‘Connection refused’ in the MethodServer-*.log files. Also verify that the wt.mail.mailhost property is set correctly and that the SMTP port (usually 25 or 587) is accessible from your ENOVIA server.
Check the notification agent status. Sometimes the agent gets disabled or stops running without throwing obvious errors. Navigate to Site > Utilities > Background Method Objects and verify that the notification agent is enabled and has recent execution timestamps. If it hasn’t run recently, restart it and monitor whether notifications start flowing.
One thing that catches people is the notification preference settings. Even if the workflow is configured correctly, individual users might have their notification preferences set to ‘None’ or disabled for specific event types. Have your stakeholders check their personal preferences under User Settings > Notifications. Also, verify that the notification templates themselves are active and not in draft status. I’ve seen cases where someone modified a template but forgot to activate it, breaking all notifications using that template.
Another area to investigate is the workflow activity configuration itself. Make sure the ‘Send Notification’ activity is properly connected in the workflow graph and that the transition conditions are being met. Sometimes the workflow takes an unexpected path that bypasses the notification step. Use the workflow visualizer to trace the actual execution path and confirm the notification activity is being triggered. Also check if there are any custom routing rules that might be interfering with the standard notification mechanism.
I had a similar case where notifications failed silently due to invalid email addresses. Check your user directory synchronization - if users have blank or malformed email addresses in LDAP, ENOVIA won’t throw an error but simply won’t send the notification. Query your database to verify email addresses are populated correctly for all stakeholders in the workflow roles.