|
| 1 | +--- |
| 2 | +title: Cordial (Actions) Destination |
| 3 | +hidden: true |
| 4 | +hide-boilerplate: true |
| 5 | +hide-dossier: true |
| 6 | +--- |
| 7 | + |
| 8 | +{% include content/plan-grid.md name="actions" %} |
| 9 | + |
| 10 | +[Cordial](https://cordial.com/) is an all-in-one marketing platform that enables brands to collect, normalize, and activate real-time data from anywhere in your technology stack to create and deliver tailored messages that flex and adapt to changing customer signals. |
| 11 | + |
| 12 | +> info "Good to know" |
| 13 | +> This page is about the [Actions-framework](/docs/connections/destinations/actions/) Cordial Segment destination. There's also a page about the [non-Actions Cordial destination](/docs/connections/destinations/catalog/cordialio/). Both of these destinations receive data from Segment. |
| 14 | +
|
| 15 | +## Benefits of Cordial (Actions) vs Cordial Classic |
| 16 | + |
| 17 | +Cordial (Actions) provides the following benefits over the classic Cordial destination: |
| 18 | + |
| 19 | +- **Transparent data mapping**. The Classic Cordial destination receives data from Segment as is. The Cordial backend then converts those Segment events to Cordial's format and clients have limited control over this conversion. The Cordial (Actions) destination allows clients to fully define their own mappings of Segment events, making sure they receive data structured specifically for their needs. |
| 20 | +- **Only sends the data you need**. With Cordial (Actions) you can define only those destination actions and mappings that make sense for your use cases, while Cordial Classic always sends four predefined API calls: identify, track, group, and page. |
| 21 | +- **Sends Personas components to Cordial**. With Cordial (Actions) it's possible to define action mappings that will send audiences and user computed traits defined in the Segment Personas platform to Cordial. |
| 22 | + |
| 23 | +## Getting started |
| 24 | + |
| 25 | +To enable destination actions to connect to Cordial: |
| 26 | +1. Make sure you have your Cordial API Key. To create a new API key, navigate to the account settings menu and select **API Keys**. [Learn more](https://support.cordial.com/hc/en-us/articles/115005365087){:target="_blank"}. |
| 27 | +2. From the Segment web app, click **Connections > Catalog**. |
| 28 | +3. Search for the **Cordial (Actions)** destination item in the left navigation, and click it. |
| 29 | +4. Click **Configure Cordial**. |
| 30 | +5. Select the Source you want to connect to Cordial (Actions). |
| 31 | + |
| 32 | +<!-- The line below renders a table of connection settings (if applicable), Pre-built Mappings, and available actions. --> |
| 33 | + |
| 34 | +{% include components/actions-fields.html %} |
| 35 | + |
| 36 | +## Migration from the classic Cordial destination |
| 37 | + |
| 38 | +### User Identities Mappings |
| 39 | + |
| 40 | +Every Cordial destination action needs to be invoked with data identifying a Cordial contact. To identify a contact every destination action has a `User Identities` field, which maps Segment event fields to Cordial contact identifiers. Each entry in the list represents a contact identifier and how it maps from a Segment event. For example, `channels.email.address <- userId` or `customerId <- traits.customerId`. At least one identifier should be valid, otherwise the contact won't be identified and the request will be ignored. |
| 41 | + |
| 42 | +Typically, the `User Identities` field maps the Segment events `userId` field to the Cordial secondary identifier field. For example, if Segment's `userId` field is known to be an email, the mapping will be `channels.email.address <- userId`, meaning the value of `userId` will be sent as `channels.email.address` to Cordial. |
| 43 | + |
| 44 | +### Updating contacts |
| 45 | + |
| 46 | +If you plan to create and update contacts in Cordial, define the `upsertContact` destination action. In addition to the `User Identities` field, the action defines the `Contact Attributes` field. This field defines an exclusive set of attributes that will be updated in a contact. Typically, you map them from Segment traits. For example, `customerId <- traits.customerId`. For the Cordial Classic destination, these mappings are stored in Cordial's database. In the Cordial (Actions) destination, they become explicit in the `upsertContact` destination action mappings. |
| 47 | + |
| 48 | +### Sending events |
| 49 | + |
| 50 | +To send events, define the `createContactactivity` destination action. In addition to the `User Identities` field, additional fields such as `Event name`, `Event timestamp`, and `Event properties` may be defined. Refer to documentation for each field when defining the destination action. |
| 51 | + |
| 52 | +### Adding users to and removing from lists |
| 53 | + |
| 54 | +If you plan to segment users in Cordial, make sure you define the `addContactToList` and `removeContactFromList` destination actions. Both actions require the Segment group ID. `addContactToList` optionally accepts a list name. |
| 55 | + |
| 56 | +Although optional, you should consider the list name as a required option, because it simplifies segmenting contacts in Cordial based on lists. Lists without a name are called following the `segment_[groupId]` pattern. |
0 commit comments