Filtering and mapping actions
UpdatedHow it works
Each data-out integration has a list of available actions. An action is how we map incoming data to your outgoing integration. In most cases, the defaults are all you’ll ever need.
But you might want to add additional action filters or change the values we map to various events to change when we send data out or to fine-tune the data that we send with each action.
You can toggle actions on and off and change the data structure for actions in your integration’s Actions tab.
Here’s a quick demonstration showing how actions work and how easy it is to change actions to fit your needs.
Incoming data maps to Actions
If incoming traffic matches an action’s Trigger and Filter, we’ll perform the associated action that sends data to your integration.
integration trigger} b-->|yes|c(Map data to
integration) b-.->|no|d(Event is not
forwarded to integration)
Actions have a few properties.
- Action/Type: the type of action we’ll perform.
- Filter/Trigger: the criteria that incoming data must meet to trigger the action
- Mappings: the way we manipulate incoming data for your outgoing integration.
Changing action mappings
Again, you’ll generally want to use our default actions and mappings. But, when you set up an integration, you can go to the Actions tab and enable or disable actions. You can also click to change the way we map values to actions.
Be careful when editing actions for your workspace
The Customer.io integration is how data gets into Customer.io—the people, events, and other data that you’ll use to send messages to your audience. It’s already configured with 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. to support incoming data. You can edit these actions if you want to change how we handle incoming data, but take care not to inadvertently break integrations with Customer.io.
When should I change triggers?
Changing a trigger determines when we send data to your integration. You might change a trigger if you need to limit the data you send out of Customer.io.
For example, many services have an some type of “Identify User” action that occurs whenever you pass an identify call to Customer.io. If your outgoing integration relies on an email trait, you might change the filter so that you only send identify calls when the call contain an email trait.
When should I change data structure mapping?
You’ll want to change the data structure of an action when your incoming data doesn’t naturally map to an outbound service. For example, you may want to change the traitsInformation that you know about a person, captured from identify events in Data Pipelines. Traits are analogous to attributes in Customer.io Journeys. from incoming identify calls that you send to your outbound integration.
Imagine that your outbound integration expects a phone number, but your incoming data captures an imei trait. In this case, you could add a new mapping that converts traits.imei to a phone trait that your outbound integration expects.
