Skip to main content

Hi, Way back when, I had a GS Admin tell me that I could only create a Journey Orchestrator program for 1 Relationship Type. And I see that when you create a JO, either Old or Redesigned, I only get the choice of selecting 1 Relationship. 

But I am noticing some JO program admins creating programs with 1 Relationship selected upon creation, but within the Query Builders, they are selecting more than 1 Relationship. 

I believe the reasoning for only having 1 Relationship per JO Program was due to Journey Analytics. But I’d like to get some confirmation on this.  Are there any other drawbacks that I should be aware of? 

Thanks!

I’m calling in the JO magician I know of ​@dayn.johnson - would you be able to chime in here please?

Ahh, unfortunately we don’t use relationships, ​@revathimenon, so I’m not able to answer myself – however, consulting Gemini (my new go-to), I got the following:

Gemini response (2- minute read):

 

Summary

Your understanding is correct. While you can only select one primary Relationship Type when initially creating a Journey Orchestrator program, you can indeed include additional Relationship Types within the program's Participant Query Builders. This is a common practice used by many JO admins.

Your initial thought that the single Relationship Type selection is tied to Journey Analytics is the primary reason for this design. When you analyze the performance of a program, the top-level analytics are aggregated and categorized based on that initial Relationship Type you selected. Using multiple Relationship Types within the queries can make these high-level, out-of-the-box analytics less straightforward to interpret, as the data is not cleanly segmented by each Relationship Type.

However, the flexibility of the Query Builder allows for more complex and targeted audience selection, which is often a worthwhile trade-off.

Are there other drawbacks?

Besides the analytics consideration, there are a few other potential drawbacks to be aware of:

  • Tokenization and Dynamic Fields: If your email templates or program steps use tokens (e.g., {{Relationship::FieldName}}), these tokens will pull data from the primary Relationship Type selected for the program. If your query includes other Relationship Types, you need to be careful that the data you're trying to tokenize is available and relevant across all of them. Mismatched data can lead to blank or incorrect information in your communications.

  • Program Complexity and Maintenance: As you add more Relationship Types through multiple queries, the program's logic becomes more complex. This can make it harder to troubleshoot issues and to update the program in the future. It's important to document your logic clearly.

  • CTA and Action Steps: Similar to tokenization, if you are creating Calls to Action (CTAs) or other actions within the program, you need to ensure they are configured to work correctly for all the included Relationship Types. This might require more nuanced configuration in your action steps.

Conclusion

Using a single Journey Orchestrator program with multiple Relationship Types via the Query Builder is a valid and often necessary approach to target the right audience. The main drawback is the potential for less clear Journey Analytics at the program level. As long as you are mindful of this and carefully manage your tokenization and action steps, the benefits of more precise audience segmentation often outweigh the complexities.

Terms & ConditionsCookie settingsAccessibility statement