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 the event trigger:

  • People already moving through the campaign workflow based on the original event continue their path.
  • New people enter the campaign based on the new event.

If you change the event filter:

  • Existing people continue on their original path to receive the subsequent actions in the workflow until they finish the campaign.
  • New people enter the campaign based on the new event filter.

If you change the segment filter(s):

  • Existing people are re-evaluated once they reach the next message to be sent in the sequence. If they no longer match, they fall out of the campaign and won’t receive any subsequent messages.
  • New people match the campaign based on the new segment filter(s).
Important note: Inside event-triggered campaigns, there’s a 30-minute window after the event takes place for people to match both event filters and segment filters, regardless of any delay that you might add to the campaign. This means that if someone doesn’t initially match a filter, there are still 30 minutes for retries.

Also important: the 30 minute retry only applies to the initial match. If someone fails to match the segment filter for later on when we’re continuing the campaign after a delay, they will be kicked out immediately.

…in segment triggered campaigns

If you change the trigger segment(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 trigger segment(s) 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 new trigger segment(s) falls out of the campaign and won’t receive messages. People who still match the new trigger segment(s) simply continue the campaign.
  • New people match based on the new trigger segment(s).
Important note: Segment triggered campaigns only send messages once, so even if someone who already passed through the campaign matches your new trigger segment(s), they won't receive the messages again.

If you change the filter segment(s):

  • Existing people are re-evaluated as soon as they reach the next message in the workflow. Anyone who doesn’t match the new filter(s) exits the campaign, while people who match the new filter segment(s) simply continue the campaign.
  • New people match based on the new filter segment(s).

…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, deleting or re-ordering messages

People continue on a linear path 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.