Handling multiple emails for Students and communicate effectively using Salesforce and Marketing cloud for Higher Education

If you are in Higher education using Salesforce, the story of your students using different emails on RFI forms, applications causes deep a lot of anxiety for Salesforce Admins. Once they enroll , they use their university email and at some point start using their employer email id for Alumni. As a marketer , you always wrestle with which email should we use to market to them resulting in lot of unsubscribe, bounce backs and bad marketing results. Familiar with these stories. This post would help to unpack this problem and provide you some guidelines.

Source of the problem

Before you go deep on solving the problem, we need to identify the cause and source of the problem. Having worked with more than 35 universities, I understand each university is different and has different tools. First, start collecting the sources of where the email address is created or updated for your students. Here are some common areas.

  1. RFI forms
  2. Test score lists
  3. Applications
  4. Student information systems( Banner, People soft and other systems)
  5. Advancement systems( Donor, employer data)

Create a laundry list of all sources where email addresses are created or updated. Identify systems that are creating and updating them.

Storing Multiple Emails

Once all the email sources are identified, the question is how do we capture or store it in Salesforce? With Salesforce providing 1 standard email field on the contact and EDA providing different email fields, the question comes down to should I create duplicate email fields on a contact or should I keep overwriting the email fields on contact? Here are some solutions.

  1. Identify the lifecycle stage the student was when he updated the email. For RFI forms, it might be prospecting, application forms can be applicant, case support forms can be enrolled student, etc.
  2. Leverage one custom object to track the multiple emails based on the lifecycle stage. This can be simple as a touchpoint custom object which will have a master-detail to contact and store email id, life cycle stage picklist on every time a record gets created or updated in Salesforce.
  3. If you use application packages like enrollment RX or interactions package you can leverage their objects like touchpoints and interactions to store the records. See the screen shot below as an example.

Capturing Multiple email fields on contact object

Now if you are trying to send a one-off journey to students in marketing cloud, pardot, you would need an easy way to do segmentation and get the right email to send to the student. So the question is How many email fields should I create on the contact? What value should I populate on the standard email field and EDA email fields? Here are some solutions for it.

  1. If the student is an applicant or applies to one or more programs, leveraging the applicant email as the standard email field works. This would help you to handle standard salesforce community registration features like creating applicant portal users, forgot password, and others.
  2. Creating one custom field for university emails is standard practice. You can leverage this email field for your SAL case inquiries, student communication, and other university messages.
  3. In a scenario where a student can apply to multiple programs or part of multiple communities in your portal like an applicant, an enrolled student portal, or an alumni portal, standard email can be a problem. So keeping 1 email field for every portal can help like Applicant email, Alumni email, Student email, etc and have the custom registration forms use the corresponding emails to handle it.
  4. I have seen universities use one prospective student email on contact which can be helpful in marketing. To populate this email, you can leverage automation rules which can be of the following nature.
    1. Update contact email based on the most recent touchpoint
    2. Update contact prospect email based on recent click-through
  5. Please see the below screenshot as an example.

Handling Multiple emails in Marketing cloud

If you are using marketing cloud, it has an all subscriber list which captures emails with subscriber id. Most of the universities have a contact id as subscriber id which could be a problem. The challenge is if marketing cloud journeys send multiple journeys to multiple emails, how do we ensure marketing cloud sends it to the right email? How do we track the email results to one contact record in Salesforce? Here are some solutions to handle it.

  1. Create automation in marketing cloud where all subscriber list will be updated with the right email before the journey sends the email. This has to be pre-send activity where you can update the list with query activity or a ftp activity.
  2. Leveraging email custom object id (touchpoint id)  as the subscriber key compared contact id. So if your custom object in Salesforce is designed to capture one unique email per student, If a student uses 5 emails, you would have 5 records. So the all subscriber key could always the right key for the right email. All the email results will be displayed under the touch point object compared to the contact object which is also fine.
  3. Leverage A master and child data extension architecture in marketing cloud . So in a scenario where there are not child objects in salesforce or contact just has multiple email fields, creating a master and child data extension in marketing cloud which would have 1 record for contact in the master and one record per unique email in the child data extension. This would be populated by automation and every time the subscriber is part of the journey, the child data extension is used to send the emails. This can cause tracking challenges in salesforce but marketing cloud will show the right results., application and students

Optins and Opt outs Impacts

One of the challenges would be to handle opt-in and opt-outs based on the subscriber. Marketing cloud has publication lists that would capture every campaign or journey the student is enrolled based on the lifecycle. So the question is how do we handle opt-outs based on email and global opt-outs as well? Here are some options.

  1. If the strategy is to handle it in marketing cloud and standard customer preference center, unsubscribes will be handled out of the box with marketing cloud by removing them on publication lists.
  2. If the requirement is to handle on Salesforce, leveraging custom amp script and salesforce automation, every unsubscribe can be updated in Salesforce on campaign objects or any custom object where the preferences stored.
  3. For global opt-outs, it can be handled on a business unit level or global level in Marketing cloud.

To summarize, here are the  3 key takeaways to handle multiple emails for students.

  1. Having a storing strategy in Salesforce to store the emails based on the lifecycle of the student.
  2. On using marketing cloud, having a strategy to handle all subscribers with automation to ensure the right email is sent to the student based on the email used.
  3. On the contact object, create emails based on life cycle than arbitrary and duplicate fields.

I hope this post provides you guidance on handling multiple emails. I do have a decision toolkit that would help you to decide the number of email fields needed for your needs. Feel free to post your comments or email me at buyan@eigenx.com for further questions.

Please subscribe

Subscribe to our mailing list and get tips to maximize salesforce to your email inbox.

Thank you for subscribing.

Something went wrong.

buyan47

Author: buyan47

Hi there! My name is Buyan Thyagarajan. I am a Salesforce consultant specializing in Higher Education, Manufacturing and Marketing Automation. My blogs will help you to maximize your Salesforce CRM investments, prevent problems beforehand and make the right decisions. If you need to talk to me right away, you can email me at buyan47@gmail.com or call me at 302-438-4097

Leave a Reply

Your email address will not be published. Required fields are marked *