You might not have access to this feature!

This feature is only available on our premium and enterprise plans. [Talk to our team](mailto:premium@customer.io) about upgrading your plan.

# Filter data coming into Customer.io

[PremiumThis feature is available for Premium plans.](/accounts-and-workspaces/plan-features/) [EnterpriseThis feature is available for Enterprise plans.](/accounts-and-workspaces/plan-features/) [BetaThis feature is new and we're actively working on it.](/beta-experimental-features/#beta-features)

By default, all data you send into Customer.io shows up in your workspace. But for some integrations, you might want to filter out certain records, attributes, or event data. You can do this by updating your workspace’s actions.

## How it works[](#how-it-works)

When you sync data from an integration like HubSpot to Customer.io, we re-shape it to match Customer.io’s data model through **Actions**. By default, your **Journeys Workspace Actions** are set up to process and use **all** of the data you sync to Customer.io. This works for most integrations.

But what do you do if you want to filter out certain requests from HubSpot?

You’d create a new *Customer.io Journeys (Workspace)* instance to handle data from these integrations independently from default settings! In your new *Customer.io Journeys (Workspace)* integration, you’ll modify **Actions** to handle requests from these integrations without affecting other integrations.

### Basic process to filter data[](#basic-process-to-filter-data)

You likely want to follow this process and set up filters *before* you add your new integration to your workspace—or at least before you finish setting it up and sending data to Customer.io.

If you set up your source integration first, you might send unwanted data to Customer.io that you’ll have to remove later!

1.  [Add a new *Customer.io (Workspace)* integration](#create-customerio-workspace-instance).
2.  [Modify the **Actions**](#modify-your-actions) for the new integration to filter data from HubSpot.
3.  [Connect your HubSpot integration to your new Customer.io (Workspace) instance](#3-add-the-new-integration-and-connect-it-to-your-filters).

## 1\. Add a new Customer.io (Workspace) instance[](#create-customerio-workspace-instance)

You’ll add a new Customer.io (Workspace) integration to store your filters. Setting up a separate integration here ensures that your filters don’t affect other integrations in your workspace; they’ll only affect your incoming HubSpot data.

1.  Go to [\> **Workspace Settings** > **API and webhook credentials**](https://fly.customer.io/workspaces/last/settings/api_credentials).
2.  Click **Create Track API Key** and give your credentials a name—you might want to name it something like “Filtering for ”.
    
    [![create a new track API key](https://docs.customer.io/images/track-credentials.png)](#61bc977605f241fa10cce411933b0275-lightbox)
    
3.  Now go to [**Integrations**](https://fly.customer.io/workspaces/last/journeys/integrations/all/overview) and click **Create Integration**.
4.  Select **Customer.io (Workspace)** and click **Create**.
    
    [![the integrations page with the workspace integration selected](https://docs.customer.io/images/cdp-new-journeys-destination.png)](#9022a2cfe3da7b88f602d115ecb67c79-lightbox)
    
5.  Give the new integration a name, like “Filtering for <integration name>.” Keeping the name aligned with the API credentials you created in the previous step can help you keep track of your filters.
6.  Enter the **Site ID** and **API Key** you copied in the previous step and click **Next: Configure Data**.
    
    [![the configure data page with the workspace integration selected](https://docs.customer.io/images/cdp-new-journeys-setup.png)](#3a520476ac837f10dfd15ac10d26b452-lightbox)
    
7.  Deselect the *Messaging data* integration and select the API credentials you created in the previous steps. This ensures that we don’t send any data through these filters yet.
    
    [![the configure data page with the workspace integration selected](https://docs.customer.io/images/cdp-new-journeys-sources.png)](#43c4bbd046ab5c27d8d6b22b9bc0f73e-lightbox)
    
8.  Click **Save**.

Now you can [modify your actions](#modify-your-actions) to filter data from your new integration.

## 2\. Modify actions to filter requests[](#modify-your-actions)

When you look at your new Customer.io (Workspace) instance, you’ll see a list of actions. You’ll modify these actions to filter requests coming from HubSpot.

For example, you might:

*   **[Filter out requests](#filter-out-incoming-requests)** that don’t contain specific traits or properties. You’ll do this by editing the **Trigger** for one or more actions.
*   **[Filter for marketing contacts](#filter-for-marketing-contacts)** to only sync marketing contacts to Customer.io. You’ll do this by editing the **Trigger** for one or more actions.
*   **[Set up filters for objects](#filters-for-objects)** to handle specific objects (like companies, deals, and so on). You’ll do this by editing the **Trigger** for one or more actions.
*   **[Add new actions](#add-new-actions-to-handle-specific-requests)** to handle specific requests differently from others. You’ll do this by creating a **New Action** and editing the trigger for an existing action.

### Filter requests[](#filter-requests)

Most of the default triggers are based on the incoming request type—`track`, `identify`, `page`, `screen`, `group`, and `alias`. We also have a few additional triggers for specific events—like `Object Deleted` and `User Suppressed`.

By default, these actions process any data matching the *Type* and *Event name* criteria. Here’s where you’ll add conditions to filter out requests that don’t contain specific traits or event properties.

For example, when you sync *Contacts* from your HubSpot data source, you might not want to process user profiles that don’t contain a phone number. In this case, you would add a condition to the **Identify** action and add a condition where the *Traits* `phone` *exists*. That means that we’ll only process identify requests where the `phone` trait exists.

[![the identify action with a condition to filter out requests where the phone trait does not exist](https://docs.customer.io/images/cdp-new-journeys-filter.png)](#6f7c9e779260ef1ea5e93946466afbf3-lightbox)

### Filter for marketing contacts[](#filter-for-marketing-contacts)

If you use HubSpot’s Marketing Cloud, you have a concept of *marketing* contacts. You might want to filter these contacts into, or out of, Customer.io to make sure you contact the right people.

You can do this by updating the `identify` action to filter on the `hs_marketable_status` trait. If `hs_marketable_status` *is* “true”, the contact is marketable. If it’s “false”, the contact is not marketable.

Note that **you can’t use the *is true* operator** because `hs_marketable_status` is a string, not a boolean.

[![the identify action with a condition to accept requests where the hs_marketable_status trait is true](https://docs.customer.io/images/cdp-hubspot-marketing-contacts.png)](#a4e85d001fe98fabc9fea8949e864e40-lightbox)

### Filters for objects[](#filters-for-objects)

You might want to create filters for different objects—companies, deals, and so on. To do this, you’ll set up your filter based on the `recordType` from HubSpot. The `recordType` represents the kind of data you bring in from HubSpot.

To manage object filters, you’ll need to make two changes to your actions:

1.  Create a filter for the `recordType` type you want to filter.
2.  Exclude the `recordType` from other `group` actions. If you don’t do this, then the `recordType` you want to create a specific case for will get handled along with other objects! This would effectively override the filter you created for the specific object.

For example, if you sync *Companies* from HubSpot, `recordType` will be `companies`. And if you wanted to filter requests for companies that have a phone trait, you’d filter on `context.sync.recordType` *is* `companies` and the `phone` trait exists. So you’d great a new *Group* action with this criteria.

Then, on your existing `group` actions (sometimes called *Create or Update Object*), you’ll add a condition to the trigger where `recordType` *is not* `companies`. This ensures that you respect the filter you created for the `companies` record type!

Step 1: create an action to handle the specific object

Step 2: exclude the object from other group actions

[![the group action with a condition to filter out requests where the recordType is companies and the phone trait exists](https://docs.customer.io/images/cdp-hubspot-group-filter.png)](#f9989a2714e73ba9b4df9ce866241b01-lightbox)

[![the group action with a condition to filter out requests where the recordType is companies and the phone trait exists](https://docs.customer.io/images/cdp-hubspot-group-filter-exclude.png)](#899f8781c97143d0af117c90317e6be6-lightbox)

### Add new actions to handle specific requests[](#add-new-actions-to-handle-specific-requests)

Imagine that we capture `event_sign_up` events from one integration, but we capture them as `event_signup` events from all our other integrations and we want to make the event name consistent.

In this case, we would:

1.  Create a new action for the `event_sign_up` event and set the trigger to *Track Event Name* *is* `event_sign_up`.
2.  In the **Data Structure**, change *The name of the event* from `$.event` to `event_signup` and **Save** the action.
    
    [![the track event action with a condition to filter out requests where the event name is event_sign_up](https://docs.customer.io/images/cdp-new-journeys-filter-event-data.png)](#71a0aa0a1c73ac71a8e0f74b21337dc7-lightbox)
    
3.  Edit the existing **Track Event** action and add a condition to the trigger where *Track Event Name* *is not* `event_sign_up`.
    
    [![the track event action with a condition to filter out requests where the event name is not event_sign_up](https://docs.customer.io/images/cdp-new-journeys-filter-event.png)](#174a41c14f0343ca7911763ebc8b7950-lightbox)
    

## 3\. Connect your HubSpot integration to your filters[](#3-connect-your-hubspot-integration-to-your-filters)

Now that you’ve set up your filters, you can connect your HubSpot integration and start syncing data to Customer.io.

1.  If you haven’t already, [set up your new HubSpot integration](/integrations/data-in/connections/hubspot/getting-started#set-up-your-hubspot-source).
2.  When you set up **Syncs** make sure that you include the fields or other data that you use to filter requests in the sync. For example, if you filter requests based on the `phone` trait, you’ll need to include the `phone` field in the sync.
    
    [![the sync fields page with the phone field selected](https://docs.customer.io/images/cdp-hubspot-sync-fields-phone.png)](#d2a93a6bd589a28d0909ea8a8f1f37ee-lightbox)
    
3.  In the final step where you select the places you want to send your data, select your new *Customer.io (Workspace)* destination. Deselect the default *Journeys Workspace* destination.
    
    [![create a new integration](https://docs.customer.io/images/cdp-hubspot-set-destination.png)](#a20523f0a7a75be858c7ee1d655fc2a7-lightbox)
    
4.  Click **Enable Integration**.

Now your new integration is set up and will start accepting data from your sources. If you want to tailor the data that your sources send to destinations, go to your destination’s actionsThe source event and data that triggers an API call to your destination. For example, an incoming `identify` event from your sources *adds or updates a person* in our Customer.io Journeys destination. tab. See [Actions](/integrations/data-out/actions) for more information.