Tasks and Events (collectively known as Activities) are some of the most disliked objects in Salesforce. There is just so much that is unique about them as an object that they’re difficult to work with at the best of times, and can be just impossible to work with in others.
For example, in the Object Manager, Tasks, Events, and Activities appear to be three separate objects. But really, they’re two separate objects that you often report on as one single object. It’s enough to boggle the mind.
In this post, we’re going to go over two different ways to get a little more information on an Activity record, and what the pros and cons of doing so may include. This information should help you to improve your activity reporting, and help support your users as well.
Why All the Drama?
Tasks, Events, and Activities are a pain, not only for the abovementioned ‘three objects in one’ problem but because the standard lookup fields on the object are “polymorphic fields.”
A polymorphic field is a lookup field, but instead of relating to just one object type, it could relate to multiple objects. Since we’re just talking about Leads and Contacts in this post, we’re going to focus on the Name field (which is present on both Tasks and Events) and indicate who an activity is related to. That’s not the only polymorphic field here – the Related To field is also polymorphic.
The Name field here could relate to either a Lead or a Contact. The biggest problem that people encounter here is that they want additional information from the Lead or Contact to appear on the Activity record itself but cannot create a formula because the field is not a traditional lookup field – it’s polymorphic.
The Use Case
Typically, the request I get from clients has two parts:
- They want to see additional fields when looking at the Task record, displaying information from that Lead or Contact. This could be demographic information, custom status fields from tools like SalesLoft, Outreach, or LeanData, or even fields like Product of Interest, or supplemental phone or email fields.
- They want to see those same additional fields on a single report. For example, their Sales Development Team might have a list of tasks to call certain Leads and Contacts, but they need more information to call down the list, and they want that information to appear on the list without needing to open each individual record.
Example Scenario
Let’s say we have a Sales Development Team (SDRs) that needs a single task call list. This list needs to include First Name, Last Name, Phone, Mobile Phone, Lead Status, Lead Rating, and two custom fields that exist on both the Lead and Contact: Product of Interest and Target Account (a checkbox). They also need to see all those same fields directly on the Task record itself.
Tasks and Events don’t include Mobile Phone, Lead Status, or Lead Rating, and also wouldn’t include any custom fields. So, how can we accomplish this?
The First Option: Formulas and Flows
In another object, you could easily create a formula field, but that won’t work with a polymorphic field. Since we can’t use the Name field as it is to create a formula, we have to create a couple of custom fields ourselves.
Create Lookup Fields
This next step should be familiar to most admins. We’re going to create two custom lookup fields – one for Leads and one for Contacts. However, we need to create them on the Activity object. Any custom fields that you want to appear on the Task or Event objects will actually need to be created in the Activity object in the Object Manager.
I also choose not to add these two custom fields to the Page Layout because I still want the users to use the regular Name field and don’t want to cause confusion. Similarly, go ahead and uncheck the related lists to reduce any confusion.
Create Formulas
Now that our lookup fields exist, we can also go ahead and create the formulas that our users require. This is the formula we’re going to use to create the Mobile Phone field:
IF(ISBLANK(Contact__c),
Lead__r.MobilePhone ,
Contact__r.MobilePhone )
Repeat this process for the other fields you need. If you need help creating custom formula fields, check out these great resources here and here. Once you’re finished, your Activity object should look something like this:
Create Flows
So now we have some lookup fields and our formulas. The next step is to populate either of the lookup fields, and then the users will start seeing data appear in those new formulas! However, this is also the trickiest part of this process, since we need to use a Flow. In order to create a good Flow, we need to know what will trigger it and what it is meant to do.
The Flow should be triggered when a Task or Event is created with a person attached, or when an existing Task or Event is given a new person. Since we’re talking about Leads, we also need to consider that a Lead could be converted to a Contact, and we’d want to update the Task/Activity in that scenario as well.
- New or Existing Task with “Name” (WhoId)
- New or Existing Event with “Name” (WhoId)
- Lead Converted to Contact with Tasks and/or Events
These three flows are very basic and only do one thing: populate the Lead or Contact lookup field we created earlier.
The final step would be to populate the Lead/Contact lookup on the existing Task/Event records. You can do this with a bulk update, but make sure not to skip this step! Otherwise, your users will not get any benefit, as they’re probably going to be looking at a mix of new and existing Task/Event records.
For the purposes of this post, I’ve labeled the two new custom lookups “Lead (Custom Lookup)” and “Contact (Custom Lookup)” to help identify and separate these from the standard fields. You may want to do this too, especially if you plan on hiding these fields from the users (which I highly recommend to prevent confusion.)
As you can see in the above screenshot, some of these custom fields are populated, and some are not (highlighted in yellow). The records that are populated were created after I activated the flows. The records that are blank were created before I activated the flows and need to be backfilled.
Once your backfill is complete, and your flows are tested and activated, we can add these new formula fields to the Task Page Layout and let the users know they’re available to be added to reports.
The Second Option: Lightning Record Page and Reports
If all of that seemed like an overwhelming amount of effort, or if, for practical reasons, you’re just not a fan of formula fields due to their limitations, there is another option. Let’s take a look at our example scenario again:
We have a Sales Development Team (SDRs) that needs a single task call list. This list needs to include First Name, Last Name, Phone, Mobile Phone, Lead Status, Lead Rating, and two custom fields that exist on both the Lead and Contact: Product of Interest and Target Account (a checkbox). They also need to see all those same fields directly on the Task record itself.
Create Reports and Dashboard
Their first need is a single task list that includes custom fields. Now, this is not possible without using the Flow solution above (or some custom-coded solution). The closest you can get is two Tasks/Events lists: one for Leads and one for Contacts. These would display all the proper custom fields from the related Lead or Contact.
Users may not like this at first; however, I’ve found that there is a certain appreciation for being able to get all the related fields from a Lead or a Contact onto those two reports. Then, we could take both of those reports and combine them on a dashboard:
Update the Lightning Record Page
Their second need is to be able to see Lead or Contact data on the Task record itself. Fortunately, we can use a custom Action and a couple of Lightning components to achieve this goal.
Create an “Update” action on the Lead and Contact, specifically for Tasks/Events. Modify the layout of that action to include the custom fields your users need to see:
Then, navigate to the Lightning Record Page for Tasks, and add a Related Record component:
In the First Lookup, select “Name”, and in the Lookup Field Type, select “Contact”. Repeat this process adding a second component, but instead of selecting “Contact”, select “Lead”. Finally, on the right sidebar, make sure to select the action that you created earlier.
The drawback to this method is that your users will see both components. If the Task is tied to a Contact, the Lead box will be blank. If the Task is tied to a Lead, the Contact box will be blank. If you can train your users to ignore the blank one, then you’re all set!
Optional: Create One Formula
However, if you are willing to do one single formula, we can fix this so that the blank one no longer appears.
Navigate back to the Object Manager → Activities. Create a new formula field called “Person Type”. You can copy this formula:
CASE(LEFT(WhoId,3),
"00Q", "Lead",
"003", "Contact",
null )
Now, navigate back to the Lightning page on the Task object (or Events, if you’re working with those). Remember those Related Record components we added earlier? We’re just going to apply some visibility restrictions to them:
Repeat this process for your Leads, setting Record → Person Type Equal Lead.
How to Choose the Right Option
The right option for you is really going to depend on your org, how many fields the users need to see, and how adamant they are about having all the fields on a single report (and not a dashboard). Too many formulas can slow down your org, so you wouldn’t want to have many of them. I’m always a fan of using a Lightning component alternative whenever possible.
Summary
Getting Lead and Contact information onto a task is one of the most frequent requests I receive from orgs that use Activity records frequently. I hope that this post helps you understand your options as an administrator and assists you in making the best choice for your Salesforce org.
Any thoughts? Leave them in the comments below.
