function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Jeff Garbers - PRODJeff Garbers - PROD 

WhoId in Task created by Email-to-Salesforce inconsistent at trigger time?

I've implemented a trigger that reassigns Tasks created by Email-to-Salesforce.  The first step in the trigger is to determine the Contact or Lead to whom the email was sent, represented in the Task object by WhoId.  In my development instance, when my trigger gets a Task, WhoId is populated with the ID of the Contact with the email address to which the message was sent.  But when deployed to production, WhoId is consistently null on those new Tasks.  At some point (not by my code) the new Task does get assigned to the corresponding Contact, but at the time my trigger fires, WhoId is null, and my business logic doesn't know who got the email.

Can anyone explain the inconsistency in behavior of this feature between my dev and production instances, and perhaps suggest a workaround? I could try parsing out the email addresses from the "Additional To:" part of the Task's Description field and looking them up, but I'm confused as to why what I have works in one place and not the other.

Thanks in advance for any help!

 
Jeff Garbers - PRODJeff Garbers - PROD
I noticed that in my Dev org, the "Allow Users to Relate Multiple Contacts to Tasks and Events" option is disabled, whereas in the Production org, it's enabled. Could that what's causing the inconsistent WhoId values at trigger time?
Jeff Garbers - PRODJeff Garbers - PROD
Just in case somebody else runs across this... yes, it appears that the "Allow Users to Relate Multiple Contacts to Tasks and Events" setting caused the different behavior.  Rather than rely on the WhoId or the TaskWhoId members, both of which were null when the Task arrived at my trigger, I wound up parsing the email addresses out of the Description field and looking them up.