How to use Calculated Fields in Journey Orchestrator Programs

  • 29 October 2019
  • 9 replies
  • 489 views

Userlevel 7
Badge +2

One of the most common questions I get during Admin Office Hours is “How can I account for updates to participant data mid-stream during a Program?”

 

When I explain to Admins that we have a feature for this called Calculated Fields within the Program setup, they often seem pleasantly surprised but then a little intimidated by the steps that are involved in making sure everything runs right. I’ve put together a tutorial video below that will hopefully help simplify this process. 
 

 

The main things to remember: 

  1. When setting up your calculated field, make sure to set up the filters to associated the Account ID with the Account ID you’ve mapped in your participant sources. Same goes for email address at the contact level. 
  2. You’ll want to use this field in a conditional wait in your program. In the video below, I start my query with contacts that have a score below 50. My conditional wait then checks in to see if any contact still has a score below 60 after 7 days. If yes, I create a CTA. If no (meaning the contact’s score has improved above 60), they get a thank you email.

What I get then is the following screenshot. After publishing the program, I changed one of the three contacts’ score to 70, meaning that contact got an email while the other two got a CTA. You can see that the program correctly picked up that new score and therefore sent the contact with a 70 score down the path of getting an email.

 

Calculated Field Program Worked!

9 replies

Userlevel 6
Badge +5

Hi @spencer_engel  - to your first reminder point, essentially you need to filter an ID field from the data source (SFDC) to a matching ID field from the query. So, it could be Account ID = (field) Account ID or it could be something else as long as you make a custom mapping - for example Opportunity ID if you want to check for changes to an open Opportunity (e.g. Renewal)

Userlevel 6
Badge +2

I’ve not used Calculated fields yet - would this be use case for it?
Pulling in Accounts with a specific CTA that’s status is open. Make CTA Status a calculated field. 7 days after an email, check that the status of the CTA is still open?

Userlevel 7
Badge +2

I’ve not used Calculated fields yet - would this be use case for it?
Pulling in Accounts with a specific CTA that’s status is open. Make CTA Status a calculated field. 7 days after an email, check that the status of the CTA is still open?

Yes, absolutely! That’s a great use case.

If I use this in a long program where I want to evaluate the same field at multiple times (let’s say 3 times) during a program. Will I need a calculated field for each conditional wait or can I use the same calculated field at each conditional wait?

 

Scenario1:

“CSM Name Calculated1” used at 3 separate conditional waits to check for a change in CSM

Scenario2:

“CSM Name Calculated1” used at Conditional wait 1

“CSM Name Calculated2” used at Conditional wait 2

“CSM Name Calculated3” used at conditional wait 3

 

Thanks

Userlevel 7
Badge +2

If I use this in a long program where I want to evaluate the same field at multiple times (let’s say 3 times) during a program. Will I need a calculated field for each conditional wait or can I use the same calculated field at each conditional wait?

 

Scenario1:

“CSM Name Calculated1” used at 3 separate conditional waits to check for a change in CSM

Scenario2:

“CSM Name Calculated1” used at Conditional wait 1

“CSM Name Calculated2” used at Conditional wait 2

“CSM Name Calculated3” used at conditional wait 3

 

Thanks

Scenario 1 should do it. Tagging JO product manager @nitisha_rathi to confirm though.

If I use this in a long program where I want to evaluate the same field at multiple times (let’s say 3 times) during a program. Will I need a calculated field for each conditional wait or can I use the same calculated field at each conditional wait?

 

Scenario1:

“CSM Name Calculated1” used at 3 separate conditional waits to check for a change in CSM

Scenario2:

“CSM Name Calculated1” used at Conditional wait 1

“CSM Name Calculated2” used at Conditional wait 2

“CSM Name Calculated3” used at conditional wait 3

 

Thanks

Scenario 1 should do it. Tagging JO product manager @nitisha_rathi to confirm though.

One calculated field can be used in multiple conditional waits. No need to create separate fields for multiple conditional waits.

Userlevel 5
Badge +3

@spencer_engel is there a way with calculated field to compare to something static?

 

We have a field called “next review” to help us understand when a CSM is planning on a review. We want to start a journey X weeks before the date to confirm if the date is still accurate and to prompt the CSM to update if not.

 

We want to in the steps after check if the date is pushed out. if it remains, we will continue a journey that helps the CSM with the prep and then after the date has passed to prompt to be sure to log in Timeline and update the date again. I am not seeing where you can compare a conditional wait field to a field like you can in a query builder

Userlevel 5
Badge +8

Is it possible to use a calculated field as a from or reply-to email address in the Journey?  The problem I am trying to solve is the email comes from the CSM, but the Participant List locks down the current CSM at the time the Journey is created.  CSMs often change assignments during the month, and follow-up emails should come from the current CSM, not the one earlier in the month.

Userlevel 5
Badge +8

Is it possible to use a calculated field as a from or reply-to email address in the Journey?  The problem I am trying to solve is the email comes from the CSM, but the Participant List locks down the current CSM at the time the Journey is created.  CSMs often change assignments during the month, and follow-up emails should come from the current CSM, not the one earlier in the month.

I found my error - this seems to be working now.

Reply