I've published several times on the How I Solved This series of the Salesforce Admins Blog, including the first of the series and the first video HIST post. But they took a pause on posts of that kind for a while, so I've got what I think is a clever solution using Flow that I'll just have to publish myself!
I work with a great little organization called For Pete's Sake Take a Break From Cancer Foundation. They work to give cancer patients and their families a trip together to get some respite from the stress of regular life and the disease and just enjoy each others company.
When For Pete's Sake (FPS) gets an inquiry about a patient that might benefit from a respite trip, this data comes into Salesforce as a Lead. Besides the standard Lead fields, which are used for the patient's name, phone, email, etc, there are custom fields to hold the names of other people that will be part of the patient's engagement with FPS, including the nominating healthcare provider, the person that inquired about a respite (for their friend, spouse, family member, etc), the primary caregiver, spouse, children, etc. When the lead gets converted the patient will become a contact, of course, and all of those other fields will either become contacts in their own right or be matched to existing contacts already in Salesforce.
But the lead conversion is meant to only happen at the point that the nomination for the patient is complete. Nominations must come from a doctor that has received onboarding from FPS and the nomination form includes various parts, such as certifications that the patient meets the program guidelines.
So all that is by way of pointing out that FPS might get an inquiry (that creates a lead) but have a lot of follow-up work before lead conversion. In today's case FPS program staff might need to reach out to the "inquirer" if the initial inquiry didn't have all the necessary information. The bulk of this follow-up work is going to be done by email, as you can imagine. And it would be best if we tracked those emails in Salesforce so that we can see the progress right on the lead. But here's where things get interesting: the lead is the patient. But the emails FPS program staff needs to send are to the Inquirer. That person is almost certainly not in Salesforce (yet).
When she needed to email the inquirer, FPS's mission coordinator, Pam, used the email composer, but this challenge initially was generated when Pam asked me if there was a way that when she opened the composer it could default to the Inquirer Email, rather than the email of the patient. Pam always had to manually copy the inquirer email and paste it into the To line, after first removing the actual Lead from that line.
While that was a small initial annoyance, Pam also noted that those outbound messages would disappear as soon as she sent them. Unlike messages usually sent with the email composer, that go into the activity feed, these would send, but not show in the feed on the lead from which Pam just sent them. Being an extremely detail-oriented employee, Pam would copy the text of the email she was about to send and create a Task so that there would be a note on activity feed.
Props to Pam for documenting all the communication, but that's a ton of extra work!
First, I had to deliver some bad news: I don't think it's possible to have the email composer default the To field to a different field than the standard Email field of the object the composer it sitting on. (Or, if it is possible, it would be enough of a challenge that I already knew that was not where For Pete's Sake would want to spend the effort and cost.) But I was pretty sure I could save Pam from the effort of copying the email contact (before she sent it) and creating a task.
Business Problem: User needs to send an email from a Lead record, but not to the standard Email field on that lead, rather to a custom Inquirer Email field. The sent email should be recorded on the lead's activity feed and also on the contact record of the recipient. If the To email does not match an existing contact, create one from the correct fields on the lead (Inquirer First Name, Inquirer Last Name, Inquirer Email, etc.). Relate the message to the contact and to the lead.
Figuring Out the Email Composer
When you send an email out of Salesforce, you create an EmailMessage.
(That's what you link to if you click on it in the Activity Feed.)
A little playing with the email composer component showed me a couple of things.
By default, when the composer launches on a person record (lead or contact), it actually has that record in the To field, not a text email address.
If you type an email address, Salesfore will attempt to replace that with a record (that has that email address).
If you use a text email address that is not in Salesforce for any contact (or work hard at using an email that is in Salesforce but don't actually let it get replaced with the record in that field), the message will go to the recipient. (That's good.)
But a message that was sent to an email address, not a record, does not show up in the activity feed of any record. (That's bad. More on this below.)
First: Down a Blind Alley
If you could edit EmailMessages, I figured, maybe I could just put the lead in the Related To field as way to additionally connect that message to the lead.
I spent a lot of time trying that. But it didn't work.
With a little poking around I noticed that email messages also have EmailMessageRelation records. That looked like it must be a junction between EmailMessage and a contact or lead. Maybe all I needed to do was create an EmailMessageRelation!
Nope. I managed to create EmailMessageRelation records, but they didn't cause the message to show in the Activity Feed.
Next: Ask the Community
Stymied by my first plan, I turned to the amazing Salesforce community. I asked for help in Ohana Slack. JM Hoskinson pointed out that EmailMessages appear to always have a Parent Task that is linked in the ParentId field of the EmailMessage. That seemed like a great place to work from!
I think this Parent Task might be what actually shows up in the activity feed. So all I should have to do is find the parent task when an email goes out (under the right conditions) and add the lead into the WhoId field.
I spent a very frustrating afternoon to eventually discover that there is no Parent Task if you send to a text email address rather than selecting a Lead or a Contact in the email composer—even if the email address is set as Email on a contact in Salesforce!
In practice, this means that if you send to an "email" rather than a "person" (lead or contact) from the Salesforce email composer, your message will go out and there will be an EmailMessage record but there will be virtually no way to find that EmailMessage again in the UI. For starters, it won't be on the activity feed of a contact or lead that has the email address you just sent to. But won't be easy to find anywhere else, either. With hard work I was able to find the outbound messages using the Developer Console, but I already knew exactly the messages I was looking for.
How I Solved It
Ironically, it's the lack of the Parent Task that I was able to exploit to solve the business requirement.
For Pete’s Sake now has a flow called EmailMessage_On Create-Find or create Inquirer and connect.
Naming conventions are important. Let's break down how I named this flow:
It starts with the name of the object that it's used on. (I intentially wrote "used on" rather than "triggered by." This is a record triggered flow, so EmailMessage is the object that actually triggers it. But even if this was auto-launched or scheduled but primarily works with EmailMessage, I would still start the name with "EmailMessage." That way all flows for the same object sort together in lists.)
I don't always include the context—which I know some people strongly recommend. (I think including the context can result in too-long names.) But this flow fires only On Create, so I thought it was worth noting that in the name for speed in understanding.
And then after the hyphen I give a short title indicating what the flow actually does.
Here's what this looks like on the composer canvas:
While that's a lot of nodes on the canvas, the logic and actions of the flow are relatively simple:
It's a record triggered flow that fires when an EmailMessage is created and ParentId is blank (meaning "does not have a Parent Task").
Looks for a contact with the email address this message went to. (Most inquirers are going to be new to us, having just inquired about one friend, so they won't be in Salesforce yet. But if there is a contact, creates a task on that contact for this email message.)
If there is not a contact, finds a Lead with that email in the Inquirer Email field. (If none is found, the flow ends. That is for the case of an email sent to a text email field that has nothing to do with the case of writing to the Inquirer on a lead.)
Then creates a new contact from the Inquirer fields.
Then creates two tasks, one on the contact and one on the lead.
The Task on the lead has a link to the contact that was created in the body of the Task so that when you view it in the Lead activity feed you can easily navigate to the newly-created contact for the Inquirer.
(At the time of this flow firing, the created contact—the Inquirer—is independent of the lead. But when the lead is converted there are flows that will create relationships between the patient and the other people on the lead, including finding the Inquirer that this flow just created as a contact.)
Do Try This At Home
I hope this inspires you to create cool solutions for your organization's challenges. Have you created a flow to solve an email-related challenge? I'd love to hear about it