function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Kelly KKelly K 

Salesforce for Outlook - when does it fill out WhoId?

Hi All,

I've implemented a trigger on the task object that stamps a last activity date/time onto the lead & contact object whenever a task is created or updated. This has been working great - except it was recently reported to me that any tasks that are created via salesforce for outlook were not receiving the update from the trigger.

So I've poked into it: https://developer.salesforce.com/forums/ForumsMain?id=906F000000095HTIAY and found out that this is the reason why it's being bypassed.

So I updated my trigger to isolate records coming in with a blank who and what Id and sent them over to the @future method - this was working for a bit in my sandbox environment, but then it noticed it stopped pushing the updates as I cleaned up some of my code (cosmetic, not functional). Completing further testing, I see the following:

This is from the trigger:

10:22:18.145 (145723116)|USER_DEBUG|[35]|DEBUG|tasks created with blank Ids: 1

Then this is from the @future handler

10:22:18.043 (43643966)|USER_DEBUG|[43]|DEBUG|entering at future method
10:22:18.043 (43651600)|SYSTEM_METHOD_EXIT|[43]|System.debug(ANY)
10:22:18.046 (46422518)|SOQL_EXECUTE_BEGIN|[49]|Aggregations:0|select Id, WhoId, Prospecting_call_connected__c, Prospecting_call_affirmative__c, SystemModstamp from Task where Id = :tmpVar1
10:22:18.052 (52227113)|SOQL_EXECUTE_END|[49]|Rows:1
10:22:18.052 (52345117)|SYSTEM_METHOD_ENTRY|[52]|LIST<Task>.iterator()
10:22:18.052 (52462775)|SYSTEM_METHOD_EXIT|[52]|LIST<Task>.iterator()
10:22:18.052 (52485423)|SYSTEM_METHOD_ENTRY|[52]|system.ListIterator.hasNext()
10:22:18.052 (52505395)|SYSTEM_METHOD_EXIT|[52]|system.ListIterator.hasNext()
10:22:18.052 (52565994)|SYSTEM_METHOD_ENTRY|[53]|System.debug(ANY)
10:22:18.052 (52587658)|USER_DEBUG|[53]|DEBUG|null

I suspect that what is happening is that Salesforce for Outlook is filling out the who and what Id using an @future method. There's no way to determine or force the run order on @future methods.

Can anyone confirm that this is what occurs or has figured out a solution?

ShashankShashank (Salesforce Developers) 
If the task is created using the Salesforce for Outlook side panel, this is expected functionality. The workaround I am aware of is to use future methids, but since we cannot guarantee the order, you can probably try using Scheduled Apex. http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_scheduler.htm
Kelly KKelly K
Actually - I figured it out the other day. SFO doesn't run using an @future method. The issue I was coming across is I have a few things in place to prevent recursion at the class and trigger level and it was blocking the @future run that was processing the SFO items. Once I modified that part, my code + SFO are working together now.
dandamudidandamudi
@kelly K
How did you  made logic to get the whoid in future method with taskids, 
i am trying to get the whoids in future apex method but still i am getting null values here is my logic.
 @future
    public static void HandletaskWhoidWhatIdnull(Set<Id> taskids){
   
        for(task tsk : [SELECT Id,WhoId,WhatId FROM Task Where Id IN :taskids]){
            system.debug('whoid'+tsk.whoId);
        }
    }

can you please help me to solve this
Kelly KKelly K
Oh gosh, that was a long time ago. 

From what I remember, using an @future call on tasks to grab the who and what Id was still not reliable as it gave intermittent results. I logged a ticket with salesforce and the reason for this behavior is that the @future call can run asynchronously to the backend process that occurs to populate the who and what Id. In short, it's possible that your @future call will run before that process has occured.

It's entirely possible that you are running into the same issue as your code looks correct.

What I ultimately had to do to solve for the issue, was move everything to a batch process. With a batch process I had much greater control to ensure that all data was populated before the record was processed. It also moves away from using an @future call, which is limited and avoided some other limitation issues that prevented mass updates.