Right now, when a participant field is synced it will not be updated once the program is active. For example, say a CSM changes between emails in a program where it is configured to send from a CSM, I can't think of any ways to make it so this change is reflected within this program. I am not sure how this would be built but it would be nice to designate some fields to be always up to date.
Seems calculated fields can be used as a token in the email but the From Name and From email address don't accept calculated fields.
Programs - Designate participant fields to be updated if changed e.g. CSM
Userlevel 7
+1
Userlevel 7
+1
I would like to see this.
Right now, I have a Conditional Wait that checks to see if the owner changed and then sends an alternative email if it has. Since we can't use the calculated field in the email header fields, the message is sent from a generic email and sender name rather thant the specific person.
Right now, I have a Conditional Wait that checks to see if the owner changed and then sends an alternative email if it has. Since we can't use the calculated field in the email header fields, the message is sent from a generic email and sender name rather thant the specific person.
Userlevel 7
I 100% agree Alex!
For another example, we want to start a participant along a Program if their upcoming renewal is within 30 days AND if their renewal opp is not in a certain stage. If, within the time between the 30 day and 15 day mark, the renewal opp moves into a certain stage, I want them to drop from the program so that they don't get the second "reminder" email at day 15.
For another example, we want to start a participant along a Program if their upcoming renewal is within 30 days AND if their renewal opp is not in a certain stage. If, within the time between the 30 day and 15 day mark, the renewal opp moves into a certain stage, I want them to drop from the program so that they don't get the second "reminder" email at day 15.
Userlevel 7
+1
I think you can already do this:
- Add Opportunity ID to the participant query
- Make a new Custom Mapping and map it to the Opportunity ID from your query
- Make a New Calculated field based on the Opportunity Object. Show "Stage" and set filter to SFDC Opportunity equal to the Field "Opportunity ID"
- Add the Calculated Field to a Conditional Wait step and set the Condition to equal whatever Stage should continue to get reminder emails or set Condition to Not Equal whatever Stage should be dropped from receiving emails.
Userlevel 7
+1
For Example
Custom Mapping:
Calculated Field:
Conditional Wait Step:
Custom Mapping:
Calculated Field:
Conditional Wait Step:
Userlevel 7
@john_apple I'm having trouble understanding whether what you described would look at the updated stage of the opportunity, rather than the stage of the opportunity when the participant entered the program. The stage of the opportunity could change between the first and second emails sent.. so will the calculated field refresh and pull the new data from the source object during the conditional wait period?
Userlevel 7
One issue I'm running into in testing this is that the field "Id" from the Opportunity object is not available as a filter when I create a calculated field.
Userlevel 7
+1
Hi @kate_green
When you make the initial query, that will pull the Opportunity Stage at the time of the sync (snapshot in time).
When the participant reaches the Conditional Wait, the logic of the Calculated Field will find the matching opportunity from the initial query and then provide the current Stage of the opportunity to compare to the initial query - like comparing a before and after snapshot.
If they are the same, then the participant would continue in the Program. If they are not the same, then they would be dropped.
When you make the initial query, that will pull the Opportunity Stage at the time of the sync (snapshot in time).
When the participant reaches the Conditional Wait, the logic of the Calculated Field will find the matching opportunity from the initial query and then provide the current Stage of the opportunity to compare to the initial query - like comparing a before and after snapshot.
If they are the same, then the participant would continue in the Program. If they are not the same, then they would be dropped.
Userlevel 7
Where you say "If they are the same, then the participant would continue in the Program. If they are not the same, then they would be dropped."...
Could I also have them dropped if the Stage is now a specific value - "Closed Won" or "Signed Paperwork Received" for example?
Could I also have them dropped if the Stage is now a specific value - "Closed Won" or "Signed Paperwork Received" for example?
Userlevel 7
+1
Do you see SFDC Opportunity ID as a field from the Opportunity Object?
Userlevel 7
+1
"Could I also have them dropped if the Stage is now a specific value - "Closed Won" or "Signed Paperwork Received" for example?"
Yes - Set the Calculated Fields on the Conditional Wait to be Stage DOES NOT Equal "Closed Won" AND Stage DOES NOT equal "Signed Paperwork Received"
Yes - Set the Calculated Fields on the Conditional Wait to be Stage DOES NOT Equal "Closed Won" AND Stage DOES NOT equal "Signed Paperwork Received"
Userlevel 7
+1
Can we open this back up? This request was more for updating specific fields used in the program. Like say you are sending the email from the CSM or tokenizing their name in the email and then the CSM changes. That would need to be reflected in the program emails.
Userlevel 7
Hi
Userlevel 7
+1
Hi
Yes, Can we change this to an idea? As this was a while ago I am not sure if I made this a question but it seems to be one now.
The request is to allow some way to update participant fields of an active program. Say the CSM changes and the program is sending emails out from the CSM, we would need that to change to the new CSM.
Userlevel 7
+1
Once this is made into a feature request, it might be good to notify the people on this thread
Also, this is becoming a more and more requested feature, at least in my interactions. I’ll be sure to forward this thread to interested customers.
Userlevel 7
Hi everyone, I converted this post to an Idea, so please vote for it if it’s a key request for you.
Userlevel 7
+1
Userlevel 7
+6
Userlevel 7
I believe this will be addressed in the April 6.13 release for both NXT and Salesforce edition. Gainsight will support the addition of Calculated fields in the Email Addresses fields. This allows the system to pick up the correct receiver and sender at the time of sending the email, even if it has changed since the participant entered the Program.
Stay tuned for more details in the upcoming release notes...
Hello Everyone!
Happy to announce that your request has been considered and included as part of the v6.13 release. Gainsight now supports the use of Calculated fields in the Email Address fields of a Program. This allows the system to pick up the correct receiver and sender at the time of sending the email.
This feature is implemented in both SFDC & NXT versions.
Thanks for posting!
Userlevel 6
+1
Hi there - just came across this which is incredibly helpful, but I learned something when trying to implement this myself:
In a program, the Recipient Email Address field does not need to be an Email data type field to be mapped to Recipient Email Address. For example we occassionally have datasets where it is a String value that contains an email address, and I’m still able to map this String value to Recipient Email Address and send emails.
However, if planning to use Calculated Fields for the To, Reply To, or From fields on the Send Email step, the field does need to be an Email data type field, and cannot be string. I am trying to use this Calculated Field method to dynamically change the recipient of the email, but I cannot accomplish this as my field containing the email address for the recipient is a String value.
Can I add to this request to also allow for String values?
Userlevel 6
Hi there - just came across this which is incredibly helpful, but I learned something when trying to implement this myself:
In a program, the Recipient Email Address field does not need to be an Email data type field to be mapped to Recipient Email Address. For example we occassionally have datasets where it is a String value that contains an email address, and I’m still able to map this String value to Recipient Email Address and send emails.
However, if planning to use Calculated Fields for the To, Reply To, or From fields on the Send Email step, the field does need to be an Email data type field, and cannot be string. I am trying to use this Calculated Field method to dynamically change the recipient of the email, but I cannot accomplish this as my field containing the email address for the recipient is a String value.
Can I add to this request to also allow for String values?
looping
Reply
Login to the community
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.