Critical Delay in Sending Publications (Targeted Communications) via EmailIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Users may notice delays in the delivery of emails triggered by publications. Some of these emails may be time-sensitive announcements that need to reach their audience quickly, but there can be a gap between when a publication is created and when the emails are actually sent. Symptoms<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } When the scheduled time for a publication is reached, the publication itself completes successfully, but the associated email notifications are not sent immediately. Instead, there is a noticeable delay before the emails are generated and delivered to recipients. No errors or failures are displayed in the UI, and the publication eventually sends without manual intervention, but not at the expected scheduled time. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All supported versions Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } A potential cause of delayed email delivery for publications is the combination of a very large recipient audience and the way recipients are evaluated and built before email sending begins. Email Segmentation and Delivery Behavior When a publication targets a high number of recipients, the platform does not send a single email to all recipients at once if the recipient count exceeds the value defined in the glide.email.smtp.max_recipients system property. Instead, email delivery is segmented into multiple messages, each containing up to the maximum number of recipients allowed by that property. With the default and recommended value of 100, a publication targeting tens of thousands of users is divided into hundreds of individual email messages. This behavior is intentional and helps prevent SMTP servers from being overloaded. While this segmentation explains why overall email delivery may take time, it does not fully account for delays that occur before email sending begins. Recipient Build Phase (Primary Source of Delay) In many cases, the delay occurs earlier in the workflow during the recipient build phase. Publications can target recipients dynamically using conditions that are evaluated at publish time. When a publication relies on dynamic recipient logic, the platform must first evaluate all conditions and build the complete list of recipients before any email messages are created or queued. Important: These conditions are evaluated every time the publication is published. The recipient list is not cached or stored for reuse. Each publication run triggers a full re-evaluation of all recipient conditions. As the number of potential recipients grows and the logic becomes more complex, this evaluation process can take a significant amount of processing time. During this period, the publication may appear to have been published successfully, but email processing will not start until the recipient list has been fully built. Transition to Email Sending Only after the recipient list has been fully evaluated and assigned does the platform proceed with: Splitting recipients into multiple email batches, andInitiating the SMTP sender jobs. Once this phase begins, email delivery typically proceeds as expected. However, the time spent building the recipient list can result in a noticeable delay between publication time and the start of email delivery. Reviewing Recipient Lists and Conditions You can review the recipient lists associated with a publication by using: Quick Search: Targeted Communications → Recipient List, orNavigating directly to: sn_publications_recipients_list.list From there, you can identify which recipient lists belong to the publication and review the conditions used to generate recipients. Performance issues commonly occur when: The source table contains thousands of records, andThe conditions used are not efficient (for example, using “contains” instead of indexed or exact-match conditions). Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } It is recommended to review the recipient list conditions used in the publication to optimize their performance and reduce the time required for processing. When recipient conditions are implemented through custom scripts developed by the customer, they fall outside of ServiceNow Support scope. For further analysis, the engineer or development team responsible for designing or maintaining this business logic should be engaged. Possible Workaround for Complex Recipient Evaluation Scenarios In scenarios where a publication targets a very large audience and the recipient list relies on complex dynamic conditions, the recipient build phase can require significant processing time. This may result in noticeable delays between publication and the start of email delivery. As a workaround to explore in complex or high-volume use cases, recipient evaluation can be shifted outside of the publication workflow by precomputing recipients and referencing a simplified data source at publish time. Instead of evaluating complex conditions against large tables during publication, this approach performs recipient computation in advance: Recipient eligibility is calculated ahead of timeResults are stored in a lightweight tableThe publication references this table using simple dynamic conditions This reduces processing overhead during publication and can improve publish-time performance. High-Level Implementation Approach 1. Create a Lightweight Recipient Cache Table A custom table can be created to store publication recipients, typically containing a reference to sys_user and a limited set of relevant attributes.Only users eligible to receive the publication should be stored in this table 2. Populate and Maintain the Table Using Scheduled Logic A Scheduled Script Execution or background job can be used to: Query large or complex source tablesApply advanced or computationally expensive logicPeriodically refresh the recipient cache table (for example, daily or weekly) This allows intensive processing to occur outside of publish time and during off-peak hours 3. Configure the Recipient List to Reference the Cache Table The publication’s dynamic recipient list can then be configured to query only the lightweight cache table using simple conditions (for example, an active flag or a basic attribute match). This ensures that recipient evaluation at publish time remains efficient and predictable. Important Considerations This approach does not modify or bypass supported publication functionalityRecipient lists remain dynamic, with complexity handled upstreamThis workaround is intended only for complex or high-volume scenarios, not standard use casesThis workaround must be thoroughly tested in a non-production environment before being considered for production use. Responsibility for the following remains with the customer: Design and validation of scheduled logicData accuracy and performance testingReview by the development and architecture teamsEvaluation of long-term maintainability and security impact ServiceNow Support can provide guidance on platform behavior and best practices; however, the implementation, validation, and maintenance of custom logic remain the customer’s responsibility. Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Scheduled publishing: Content published later than expected.Minimize SMTP Recipient Quantity