--- schema_version: "1" id: 817740067be301e46690c471fec1b560413af211d6b2bdf9a455e8fa8ca5beb5 title: How Data Binding Works collection: developer version: current locale: en-us portal_url: https://docs.salesforce.com/developer/current/en-us/marketing-cloud/guides/mc-apis/how-data-binding-works.md canonical_url: https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/how-data-binding-works.html source_site: developer.salesforce.com content_type: documentation content_hash: cd204ab764a857aac745e8d41f06dca80ff6d549e02c9fbbbff2a6b0086ff45e products: - Marketing Cloud Engagement APIs and Programmatic Languages - Marketing Cloud --- # How Data Binding Works Data binding allows you to bind an activity to data in a running journey. This process greatly simplifies how a marketer or developer dynamically connects data for each contact flowing through a journey. The syntax for data binding is based on the Mustache template language library. Data binding lets you write expressions evaluated by the Journey Builder engine at runtime, when an activity executes for a contact. The `inArguments` and `outArguments` include these expressions. The system doesn't evaluate these expressions when saving, validating, or publishing a journey. **note:** Data binding expressions are case-sensitive. Ensure that the expression exactly match your data extension name and field name. The standard POST body to an Activity without Data Binding leaves the `inArguments` and `outArguments` empty. ```json { "contents": { "inArguments": [], "outArguments": [], "journeyId": "1234abcd-56ef-78gh-90ij-9876klmn5432", "activityId": "1234abcd-56ef-78gh-90ij-9876klmn5432", "definitionInstanceId": "1234abcd-56ef-78gh-90ij-9876klmn5432", "keyValue": "somekeyvalue@domain.tld" } } ``` While this call contains some useful information, it provides a limited approach. InArguments provide your Activity with information needed to handle internal decisions, update your data, or reach out to services your Custom Activity depends on. OutArguments contain the key and value pair for each field expected on the response body of the request. The following example uses Data Binding within the config.json: ```json { "workflowApiVersion": "1.0", "type": "MOBILE", "lang": { "en-US": { "name": "My Custom Activity", "description": "This activity will make the world a better place" } }, "arguments": { "execute": { "inArguments": [ { "contactIdentifier": "{{Contact.Key}}" }, { "emailAddress": "{{InteractionDefaults.Email}}" }, { "twitterHandle": "{{Contact.Default.Twitter}}" }, { "lastLogin": "{{Contact.Attribute.Engagement.LastLogin}}" } ], "outArguments": [ { "foundSignupDate": "" } ], "url": "https://some-endpoint.com/execute" } }, "configurationArguments": { "save": {}, "publish": {}, "validate": {}, "edit": { "uri": "https://my.endpoint.tld/path/to/activity/index.html", "height": 350, "width": 550 } } } ``` ## Data Binding Syntax Basics Using Mustache syntax provides a similar experience to using personalization strings. However, data binding is limited to Contacts and Event Data for a journey for the supplied Contact. To illustrate how Mustache syntax works, assume you use the following JSON data: ```json { "Contact": [ { "ID": 1234567890, "Key": "1234abcd-56ef-78gh-90ij-9876klmn5432", "FirstName": "John", "LastName": "Smith", "Nickname": "Johnny", "PhysicalAddresses": [ { "type": "work", "Address1": "9876 Money Maker Lane", "Address2": "Suite 100", "City": "Palo Alto", "State": "CA", "PostalCode": "94301" } ] } ] } ``` To bind the full name of the Contact, use Handlebars syntax. ``` {{Contact.Attribute.Persona.FirstName}} {{Contact.Attribute.Persona.LastName}} ``` ## Supported Methods of Data Binding Using Data Binding with Contact Builder provides a powerful set of data. - `Contact.Key` - The Journey Builder Engine requires this contact key value to provide the appropriate context. - `InteractionDefaults.Email` - Use this pattern to retrieve the default address of the given type for the specified Contact. - `Contact.Default.[Twitter||Facebook||SMS]` - Use this pattern to retrieve the default address (non-email) of the given type for the specified Contact. - `Contact.Attribute.[FullyQualifiedAttributeName]` - Use this pattern to retrieve the specified attribute from the Contact Builder. The fully qualified attribute names generally appear in the form of **\[AttributeSet Name].\[AttributeName]**. By default, the attribute set name from Contact Builder's Data Designer is the same as the data extension name. The attribute set name of a system-defined set may be different from the data extension name, so use the attribute set name from Contact Builder. (The attribute set name is different from the attribute group name.) Attribute sets and names can use special characters like spaces, but you **must** surround these values with double quotation marks. Example: `Contact.Attribute."Product Orders"."Product Name"` Here are some examples based on the following data assumptions: - The contact opted-in for subscriptions - The contact subscribed with Email, Twitter and SMS channels as defaults using the following values: - john.smith@example.com - @johnnyballgame - 555-555-5555 - Contact includes related data on an attribute set named `Person` (using the JSON data from above). ``` // To fetch the Default Email Address for the Contact {{InteractionDefaults.Email}} // To fetch the Default Twitter Address for the Contact {{Contact.Default.Twitter}} // To fetch the Default SMS Address for the Contact {{Contact.Default.SMS}} // To fetch the Home Postal Code for the Contact {{Contact.Attribute.Person.Work.PostalCode}} // To fetch full name for the Contact {{Contact.Attribute.Person.FirstName}} {{Contact.Attribute.Person.LastName}} ``` ### Journey Context You may need to retrieve information from the running journey's context. An expression can also reference the outArguments from a prior activity in the current journey context using the following placeholder patterns: - `Interaction.[ActivityCustomerKey].[OutArgumentName]` - Uses a journey-unique Activity Customer Key and the Activity specifies the OutArgumentName value. - `Context.IsTest` - Returns **true** for a journey in Test Mode. Use this parameter when the Activity needs to act differently when running the journey as a test. - `Context.PublicationId` - Use the publication ID to associate the currently executing activity to a particular publication (version) of the journey. - `Context.DefinitionId` - Use the definition ID to associate the currently executing activity to a particular definition of the journey. - `Context.DefinitionInstanceId` - This key identifies the actual instance of a journey. Each time a contact runs through the engine, the engine creates a unique ID. Use this information to match logs. - `Context.StartActivityKey` - This key contains the starting key for the session associated with the activity. The key includes a blank value when starting a new activity. Coming off of a wait, this key contains the key of the wait activity. - `Context.VersionNumber` - This key retrieves the entire journey response body, from which you can pull the journey version number. See the Journey Spec for an example of the response body format. ### Event Context You can reference an event within an expression (the incoming data associated with the entry event). Adhere to the following pattern when using data binding with events: ```Handlebars // Capture a field "ProductId" from the EventDefinitionKey "my-custom-product-entry-event-key" {{Event.my-custom-product-entry-event-key.ProductId}} ``` ## Evaluating Expressions An activity can include many different data bound fields. The fields include Mustache expressions specified at journey design time. For instance, for an activity with a databound field expecting an email, the customer can specify `{{InteractionDefaults.Email}}`. - When processing a contact in a journey, the engine evaluates all expressions. - Once a journey publishes, and every subsequent hour, the system compiles each expression to ensure evaluation at runtime. - When the system can’t compile an expression, publish fails and the system disables the journey. These types of failures could happen if a customer renames or deletes a field or does anything to invalidate the expression. - The system compiles all expressions in memory during this hourly validation. This process allows the engine to cache all information needed to retrieve for a given journey, and it speeds up the replacement process of the Mustache placeholders. For example, you can combine all contact calls that can happen within this session of the journey into one contact service call. - The `defaults` property on the journey Object contains an ordered list of email expressions that determine which email address to use as the default, starting with the first expression. ## Best Practices Handlebars allows for complex ways of using placeholders. Use the fully qualified name approach for specifying placeholders to cut down on the change of ambiguation issues. The system checks the inner scope before the outer scope. If there is non-alpha character, such as a space or a colon, in the attribute set or field name, use double quotation marks with Handlebars syntax. ```Handlebars {{#with Contact.FilterId}} {{#with Contact.AttributeId}} {{1234abcd-56ef-78gh-90ij-9876klmn5432}}-{{1234abcd-56ef-78gh-90ij-9876klmn5432}} {{/with}} {{/with}} ``` ## See Also - [Custom Activities](https://developer.salesforce.com/docs/marketing/marketing-cloud/mc-app-development/creating-activities.md) - [Validation Checks to Publish a Journey](https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/interaction-operating-states.md) - [Journey Specification](https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/getting-started-spec.md) - _Salesforce Help_: [Personalization Strings](https://help.salesforce.com/articleView?id=mktg.mc_es_personalization_strings.htm) - [Mustache Template Language](http://mustache.github.io/)