What happens when you make changes to a campaign

Each campaign type in Customer.io behaves a little bit differently, so changes will have a different effect on the messages they contain. What kind of change you make is also significant— whether it’s a trigger, filter, delay action, or message. We’ll describe all of those in detail below, for each campaign type as appropriate.

Changing triggers and/or filters…


…in event triggered campaigns

If you change which event is used as the trigger:

  • People already moving through the campaign’s workflow based on the original event will continue their journey.
  • Future events will trigger the campaign based on the campaign’s new trigger event.

If you change the trigger’s event data filter(s):

  • People already moving through the campaign’s workflow based on the original event data filter will continue their journey.
  • Future events will trigger the campaign based on the trigger’s new event data filter.

If you change which segments are used as filter(s):

  • People that are waiting in a delay or time window will be re-evaluated once they reach the next message to be sent in the workflow. Anyone who doesn’t match the campaign’s new filter conditions will exit the campaign, while people who do match the campaign’s new filter conditions simply continue the campaign.
  • Future event performers will be filtered based on the campaign’s new filter conditions.
Important note: When events come in and the person does not match the filter conditions, we will retry the event for up to 30 minutes (regardless of any delay that you might add to the campaign). If the person matches the filter conditions within those 30 minutes they will enter the campaign. If the person still does not match the filter conditions after those 30 minutes, they will not enter the campaign.

Also important: The 30 minute retry only applies to the initial match. If someone fails to match the filter conditions later when we're continuing the campaign after a delay, they may exit the campaign immediately according to the exit conditions that are set for the campaign.

If you change the underlying configuration of the campaign’s filter’s segment(s):

  • When you update a segment that is used as a filter on active triggered campaign(s), we do not currently notify your campaign(s) of these changes. This means that no one will be re-evaluated to see if they should join or exit the campaign based solely on the updated segment conditions.

…in segment triggered campaigns

If you change which segments are used as trigger(s):

  • People that are waiting in a delay or time window will be re-evaluated before moving to the next action, delay, or time window. For example, if people are waiting in a delay when you’re changing the campaign’s trigger conditions and the delay is followed by a time window, people are re-evaluated when they enter the time window. At this point, anyone who doesn’t match the campaign’s new trigger conditions will exit the campaign. People who still match the campaign’s new trigger conditions will simply continue the campaign.
  • Future segment matches will trigger the campaign based on the campaign’s new trigger conditions.
Important note: By default, people are only allowed to enter segment triggered campaigns once, so even if someone who already passed through the campaign matches the campaign's new trigger conditions, they won't enter the campaign again.

If you change which segments are used as filter(s):

  • People that are waiting in a delay or time window will be re-evaluated once they reach the next message to be sent in the workflow. Anyone who doesn’t match the campaign’s new filter conditions will exit the campaign, while people who do match the campaign’s new filter conditions simply continue the campaign.
  • Future segment matches will be filtered based on the campaign’s new filter conditions.

If you change the underlying configuration of the campaign’s trigger or filter’s segment(s):

  • When you update a segment that is used as a trigger or filter on active triggered campaign(s), we do not currently notify your campaign(s) of these changes. This means that no one will be re-evaluated to see if they should join or exit the campaign based solely on the updated segment conditions.

…in API triggered broadcasts

These work a little bit differently in that your recipients don’t have to be defined at the outset. When you trigger your broadcast via the API, you can specify recipients in that call. That API call will override anything you’ve set in the ‘Recipients’ section.

Also, API Triggered Broadcasts send messages multiple times, similar to event triggered campaigns. This is true even if a customer enters and leaves your recipient segment(s). You have more fine-grained control here when it comes to overriding recipients.

If you change the recipient segment(s) in the UI:

If you change these in the Recipients tab of your campaign overview, that change will go into effect the next time you trigger the broadcast.

If you use a different recipient segment(s) in your API call:

If you trigger the send via API and specify your recipient segment(s) there, whatever segment ID you use in that API call will take precedence; it doesn’t matter what you’ve set in the Recipients tab in the app. So if, in the app, your broadcast is set to send to people in Segment A, but your API call specifies Segment B, then the broadcast will be sent to Segment B, not both!

Making changes while a broadcast is in the sending queue:

An API triggered broadcast is “in the sending queue” if you’ve triggered it to send, either manually or via the API, and we’re generating deliveries for it— essentially, the broadcast is in the process of being sent to all of its recipients. Any changes you make to messages during that time will take effect immediately! We recommend that you don’t do this, because it might mean that you send different messages to different people.

You can tell whether or not a send is in progress by checking out your Task History in the top navigation bar:

Changing or deleting delays


If you shorten a delay (for example, from 7 days to 5 days):

  • All people waiting in that particular delay are re-evaluated. You will see a processing circle while this is happening.
  • People who have already waited for more than the new delay (in our case, more than 5 days) will immediately move to the next action.
  • Everyone else continues waiting in the delay for the required period.

If you lengthen a delay (for example from 5 days to 7 days):

  • People all wait based on the new delay (7 days instead of 5). The only visual feedback is the new delay being saved; there is no re-evaluation done.

If you delete a delay:

  • People automatically move to the next action in the workflow.
  • If the next item is a delay or a time window, they wait the required number of minutes/hours/days or until the time window is open.
  • If the next item is a message or other item (attribute update, webhook) it is triggered immediately.

Changing or deleting time windows

If you limit or extend a time window:

  • People adapt to the new time window.
  • If the time window wasn’t open before the change, but it is now, everyone previously waiting will move to the next action in the workflow.

As an example, let’s say it is currently Monday at 09:30. There is a time window currently set to allow sending on Tuesday and Thursday from 09:00 to 12:00, and we alter it to allow sending on Monday from 09:00 to 12:00 also. People currently waiting in the delay will immediately proceed to the next action in the workflow. If, instead, we were to alter it to allow sending on Monday from 10:00 to 12:00, all people waiting in the time window would be scheduled to move to the next action in the workflow at 10:00 (i.e. in 30 minutes), instead of waiting until Tuesday at 09:00.

If you delete a time window:

  • All the people waiting for the next available slot in the time window will immediately move to the next action in the workflow.

Changing or deleting Wait Until

Changing, deleting or re-ordering messages

People continue on a linear journey through the campaign.

If you add a new message or move an existing one to a different position in the workflow:

  • It will be received by all the people who didn’t yet reach that particular message (even those who are waiting in a delay or time window right before it).
  • If the person already received that particular message because it initially placed earlier in the workflow, they will skip ahead to the next action.

If you delete a message:

  • People waiting in any delay/time window before that message will move to the next action following the deleted message (if one exists).

Changing workflow item behavior

“Send Automatically” sends the message or other item as soon as they match the delays/time windows you set.

If you change an item/message to “Don’t Send”:

  • People skip it and move to the next action in the workflow, if there is one

If you change an item/message to “Queue Draft”:

  • Messages and other workflow items (attribute updates, webhooks) are created under “Drafts.” You’ll have to send them manually by clicking “Send All” or choosing particular ones and pressing the “Send” button next to each of them.
  • People move to the next action in the workflow even if the drafts aren’t sent.

Changing sending behavior

If you change email tracking from “Enable Tracking” to “No tracking”:

  • Links will no longer be wrapped in tracking links. Opens or clicks will not be recorded for that particular email.

If you change “Don’t send to unsubscribed” to “Send even if unsubscribed”:

  • Unsubscribed people will start receiving your particular email.
  • If you have the first email in a campaign set to “Don’t send to unsubscribed”, but the second email has “Send even if unsubscribed”, those who have unsubscribed will skip the first email and receive the second one and any others that are meant for unsubscribed people.
Important note:
  • Event-triggered campaigns default to "Send even if unsubscribed”.
  • Segment triggered campaigns and API triggered broadcasts default to "Don’t send to unsubscribed”.

Changing message/action content

  • If you edit the content of a message, any existing drafts will update to reflect your changes, but the ones that were already sent won’t be affected.
  • People who received the message previously won’t receive an updated version, even if it changed position in the workflow.