0

I have a simple question that needs a definitive answer.

I've created a DE with 3 fields. SubscriberKey, FirstName, LastName

I want to bring these fields into my config.json and post them to my endpoint.

"arguments": {
"execute": {
  "inArguments": [
      {"subscriberKey": "{{SubscriberKey}}"},
      {"firstName": "{{SubscriberKey.Attribute.DEname.FirstName}}"},
      {"lastName": "{{SubscriberKey.Attribute.DEname.LastName}}"}
],
  "outArguments": [],
  "url": "Some endpoint",
  "verb": "POST",
  "body": "",
  "header": "",
  "format": "json",
  "useJwt": true,
  "timeout": 1000
}
},

docs https://developer.salesforce.com/docs/atlas.en-us.mc-apis.meta/mc-apis/how-data-binding-works.htm

Everywhere I look including the above documentation it mentions the need to create a relationship with a field in Contact Builder. Is this a necessary step? Is it not possible to reference DE values directly and bring them into a custom activity config without creating this relationship?

With the above example, I am hitting the endpoint but the fields are not visible. I have not created a data relationship with contact builder but why is this a necessary step?

Thanks in advance!

9
  • Are the values always taken from this same data extension, or are they taken from the entry data?
    – Macca
    Aug 4 '20 at 3:28
  • Hi @Macca - values will always be retrieved from this DE. I am using this DE as the entry source for this journey.
    – Dr. Tenma
    Aug 4 '20 at 3:31
  • For instance, in AMPscript you can easily reference values in your DE by declaring a variable in your email HTML. I want similar functionality for this activity, however, don't understand the need to create a data relationship in contact builder when I am just required to bring values directly from the DE being used for the journey.
    – Dr. Tenma
    Aug 4 '20 at 3:36
  • Yes. You'd need to define the relationship between your Data Extension and the Contact Model using Contact Builder's Data Designer. There could be multiple ways in which that data extension might be relatable to your Contact, so in order to allow Journey Builder to understand how to lookup values in that table, you need to provide the fully qualified path in order to successfully data bind. You don't actually need to do this for the SubscriberKey, just use "{{Contact.Key}}".
    – Macca
    Aug 4 '20 at 3:51
  • @Macca thank you, so what your saying is that since SubscriberKey is already defined in my org I can simply use it as the contact key?
    – Dr. Tenma
    Aug 4 '20 at 4:04
0

You would need to define the relationship between your Data Extension and the Contact Model using Contact Builder's Data Designer. There could be multiple ways in which that data extension might be relatable to your Contact, so in order to allow Journey Builder to understand how to lookup values in that table, you need to provide the fully qualified path in order to successfully data bind. You don't actually need to do this for the SubscriberKey, just use "{{Contact.Key}}".

Data binding syntax is detailed on the page you quoted in your question. For Contact Model data binding, you use the following syntax - Contact.Attribute.[FullyQualifiedAttributeName]. The actual fully qualified path would vary depending on how you've configured your attribute groups and relationships in Contact Builder. To illustrate, assuming you have a Data Extension called "MyCustomers" linked directly to your contact data in Contact Builder similar to that below:

enter image description here

Assuming this data model and your requirement to get back ContactKey, FirstName and LastName as InArguments on execute, your inArguments definition passed back using Postmonger on saving the activity would look like this:

[{
  "SubscriberKey": "{{Contact.Key}}"
}, {
  "FirstName": "{{Contact.Attribute.MyCustomers.FirstName}}"
}, {
  "LastName": "{{Contact.Attribute.MyCustomers.LastName}}"
}]

Note that where there are any spaces in the fully qualified path, you'll need to place the elements of the path in quotes, eg: {{Contact.Attribute.\"My Customers\".\"Last Name\"}}.

17
  • thank you very much for this comprehensive answer. It is much appreciated and does clear some things up. There is one last thing that I am wondering. With the info you have provided I have successfully posted the subscriberKey using {{Contact.Key}} and this is without creating a data relationship in contact builder. How is it possible that I am able to POST subscriberKey from my DE when I have not yet binded my data to an attribute group?
    – Dr. Tenma
    Aug 6 '20 at 18:34
  • I suppose what I'm trying to fully understand is why I need to link my DE to contact builder when the data in my DE is static and not dependent on the contact model. When records pass over my activity it would be ideal to simply access data in this static DE that I'm using for the entry source e.g. (first name and last name) without having to create a data relationship.
    – Dr. Tenma
    Aug 6 '20 at 22:52
  • In my example above I have a table called "MyCustomers". It could have a bunch of fields in it and any one of them could relate back to the ContactKey that's running through the Journey Builder Interaction. My example above uses a field called "SubscriberKey", so the relationship's pretty obvious to you or I, but how would Journey Builder know that it can get the FirstName and LastName inArgs for the Contact based on ContactKey=SubscriberKey?
    – Macca
    Aug 7 '20 at 1:04
  • Adding "MyCustomers" to the Data Designer and defining the relationship between the Contact and the table to be Contact.ContactKey = MyCustomers.SubscriberKey allows Journey Builder to bind your inArgs to the Contact.
    – Macca
    Aug 7 '20 at 1:04
  • Instead of linking in contact builder you also have access to static fields from your entry source DE using {{Event.Entry-event-key.YOUR_FIELD}}. Any event fields do not require a relationship in contact builder because they are a cache of the entire row that was injected into the journey, from the time it was injected. If you are not expecting these fields to be updated between the journey entry and this activity, I would recommend this as it is simpler.
    – Tyler
    Aug 7 '20 at 2:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.