• Home
  • Ideas
  • Programs - Designate participant fields to be updated if changed e.g. CSM

Programs - Designate participant fields to be updated if changed e.g. CSM

Related products: None
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.



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.



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.



I think you can already do this:







  1. Add Opportunity ID to the participant query





  2. Make a new Custom Mapping and map it to the Opportunity ID from your query





  3. Make a New Calculated field based on the Opportunity Object. Show "Stage" and set filter to SFDC Opportunity equal to the Field "Opportunity ID"





  4. 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.



For Example





Custom Mapping:











Calculated Field:











Conditional Wait Step:









@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?



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.



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.



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?



Do you see SFDC Opportunity ID as a field from the Opportunity Object?









"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"



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.

 

Hi @alex_legay Is this really a feature request?

Hi @alex_legay Is this really a feature request?

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.

Once this is made into a feature request, it might be good to notify the people on this thread @lila_meyer. https://community.gainsight.com/jo-email-notifications-10/are-programs-participant-field-values-static-6097

 

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. 

Hi everyone, I converted this post to an Idea, so please vote for it if it’s a key request for you. 

@nitisha_rathi This is what I brought up earlier today. Can you confirm if this is indeed on the roadmap?

@alex_legay I ran into this exact scenario, and I didn’t find a way to replace with the new CSM, but I did add a conditional wait with a calculated field to check and see if the CSM was the same, and if not, to remove the customer from the program. Not ideal, but fixed the immediate problem of the email coming from an old CSM.  

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!

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?

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 @PavanCh on this convo

Adding another comment here -- it’s also come to my attention that calculated fields cannot be used for CTA Owner assignments. What this means, is that while I can change my Email sender if the CSM changes, I cannot change who the CTA is assigned to. This is a disjointed JO program experience. If I can change my email sender to be the new CSM on the account, I should also be able to assign the CTA that is triggered from the program to the new CSM on the account.

Seconding Sarah on every comment, especially for programs in which we generate the sender details with a case statement when nobody is assigned to the account… 

@mpatra could you share an update?

@sarahmiracle @alizee Thank you so much identifying and sharing these differences. We are discussing these internally, and are also working on more natively solving for these dynamic/fresh sender data situations. + @vmallya @mpatra  

Terms & ConditionsCookie settings