# Add conditions to messages, data blocks, or delays

You can control which customers enter your campaigns with triggers, filters, and frequency settings. You can also add **conditions** to messages, data blocks, and delays to filter your audience within your campaign.

Click an action to edit conditions:

[![condition-setup.png](https://docs.customer.io/images/condition-setup.png)](#3fc2980c6694735fe7b0f7828eeed570-lightbox)

Hover over the condition on the action to see the details:

[![condition-hover.png](https://docs.customer.io/images/condition-hover.png)](#42ae5f13d9efd57af59e5b512fa70ae3-lightbox)

## How they work[](#how-do-action-conditions-work)

Conditions are optional checks you can add to any message, data block, or delay in your campaign. We check the conditions before initiating the block’s action (sending a message, starting a delay timer, or sending a webhook, for instance).

If people don’t meet the conditions, they skip the action and continue through the campaign. If they should leave the campaign entirely, then consider adding these conditions to the campaign’s trigger criteria.

You can build conditions from people’s [attributesA key-value pair that you associate with a person or an object—like a person’s name, the date they were created in your workspace, or a company’s billing date etc. Use attributes to target people and personalize messages.](/journeys/attributes/), [eventsSomething that a person in your workspace did. Events can trigger campaigns, add people to segments, etc, and you can use properties from events to personalize messages.](/events/) data, message data, and [segmentsA segment is a group of people in your workspace. Use segments to trigger campaigns, track membership over time, or fine-tune your audience. There are two types of segments: data-driven and manual. Data-driven segments automatically update when people start or stop matching criteria. Manual segments are static.](/journeys/segments/) membership. You can also use [journey attributesAn attribute stored on a journey during a campaign. Journey attributes expire when people exit your campaign.](/journeys/set-journey-attributes/) in conditions. When building conditions based on email opens or clicks, you can also specify whether to target human only or [human and machine engagement](/journeys/analytics/#how-we-track-human-opens-and-clicks).

 You can use JSON dot notation in condition logic

If you store attributes or event data in JSON objects or arrays, you can use JSON dot notation in your branch conditions to evaluate these properties. Use `array[]` to represent any item in an array or `array[0]` to represent the first item in the array. See [Storing and using JSON](/journeys/getting-started-with-json/#referencing-json-data-dot-notation) for more information about dot notation in Customer.io.

## When to use action conditions[](#when-should-you-use-action-conditions)

Use conditions to personalize journeys even further within a single campaign. Here are a few ideas:

*   **Channel targeting**: send an SMS message, but only if the customer has a phone number
*   **Tailored onboarding**: skip tutorial messages if your users have already completed those tasks to keep your emails relevant
*   **Messaging by segment**: send custom content to users based on segment membership

## Edit conditions[](#how-to-get-started)

Drag and drop a block onto the canvas or click one to edit it. Click **Conditions** to expand it. Then define your criteria.

[![condition-setup.png](https://docs.customer.io/images/condition-setup.png)](#3fc2980c6694735fe7b0f7828eeed570-lightbox)

Specify which conditions a person should meet to receive the message, enter the delay, or to cue the data update. If people do **not** meet the conditions, they will **skip** this item and move on in the workflow.

### Event has been performed conditions[](#event-has-been-performed-conditions)

The *Event has been performed* and *Event has not been performed* conditions check whether a person has **ever** performed an event. It isn’t limited to the current campaign.

If you use the *Event has been performed* condition, and a person performed the event before they entered the campaign—even if they performed the event well before they started a campaign journey—they’ll meet the condition.

### Use RegEx in conditions[](#use-regex-in-conditions)

Event names and other data you may want to create conditions with can include special characters. In most cases, we’ll treat special characters as literal characters: `&` is `&`. However, the following special characters perform Regular Expression (RegEx) functions that look for patterns of characters. To treat them as characters, not search functions, you can escape them with `\` (for example, `\+1`). Otherwise, this is how they work:

Special character

RegEx function

`*`

This is a wild card: it represents any character.  
  
For example, `s*n` matches event names “sink”, “sun”, and “lesson”.  
  
If you don’t place any characters after `*`, it’ll match the string up to `*`. For example, `si*` matches “reside” and “sink”.

`+`

This represents “and”: it matches both values in a statement. You can use it with attribute conditions and event conditions, but *not* event names.  
  
For example, if you wanted to find a person whose email address contains `person` and `gmail`, you could write `email contains person+gmail`. A few emails this would match on include `person@gmail.com`, `person+test@gmail.com`, or `person2@gmail.com` because these addresses contain both `person` and `gmail`.

`|`

This represents “or”: it lets a person who has performed (or not performed) either event to enter the segment.  
  
For example, a segment based on `hide|seek` events lets a person who has performed *either* the `hide` or `seek` events to enter the segment.

 Use the conditions with `contain` to use RegEx

To use regular expressions, you need to use the “contains” or “does not contain” conditions. Using “equals” or “does not equal” will yield no results.