Journey Builder now blocks re-sending journeys to supporters who already received them when re-published. Only new supporters matching the trigger are queued. This prevents duplicate messages, improves supporter experience, and allows safer updates.
What’s New
When editing and re-publishing a journey, the system will now prevent re-sending the journey to supporters who have already received it via the same trigger.
This update modifies the publishing logic to ensure that previously-processed supporters are not re-queued or re-targeted when a journey is re-published.
Only new supporters meeting the trigger condition after the update will receive the latest version of the journey.
This applies to all triggers (e.g., keyword-based, engagement-based, campaign-based), and does not affect manual sends or test user flows.
Why It Matters
Previously, editing and republishing a journey would inadvertently re-trigger the journey for all supporters associated with the original trigger — including those who had already received it. This created duplicate messages, user confusion, and potential reputational risk for nonprofits.
With this change, teams can now safely iterate and deploy improvements to live journeys without fear of re-sending to prior recipients. This improves trust in journey management, supports more agile optimization, and reduces friction for Professional Services and Customer Success teams who might refine journeys after the initial launch.
This also directly contributes to platform stability and supporter experience as we scale toward broader campaign volume and increased automation.
Known Limitations
This update does not prevent retriggering for new entries to the journey — any supporter who re-qualifies based on a trigger after republishing may still receive the journey again (depending on trigger rules).
Given a List A having Supporter S, if a Supporter K is added to List A while also adding Support S, who was already in the list, both of them will receive the journey.
Supporters in multi-entry journeys may still re-enter based on separate paths or logic not related to the initial trigger.
Test Cases – Republishing Without Re-triggering
Initial Send
Publish a journey with a Supporter you control, in a List as a Trigger
Confirm journey is delivered.
Edit and Re-publish.
Make a minor edit to the journey (e.g., update message copy).
Re-publish the journey.
Confirm that the previous test supporter does not receive the journey again.
New Supporter Trigger Post-Edit
Trigger the updated journey using a different supporter.
Confirm that the new version of the journey is sent.
Same Supporter, New Trigger Event
Attempt to trigger the journey again for the same supporter (e.g., resend "JOIN").
Confirm journey is not resent unless journey logic explicitly allows re-entry.
Multi-Entry Journey Validation
Set up a journey with multiple valid entry paths.
Enter the journey through one path.
After publishing edits, attempt entry through a different path.
Confirm journey is only re-entered if the path logic allows it.
