I think I’m going to have to find someone internal for this one, but posting to see if anyone has any ideas about this at all.
We’ve got code in a managed package that’s querying for tasks associated to a person account, and it’s not finding a task that definitely exists.
This is the query straight from the debug logs but with some fields removed (there’s a bit of funky spacing because it’s auto-generated and I tend to err on the side of too much whitespace):
select WhatId, Id, CreatedDate from Task where WhatId = '0014100000GcYdJAAV' and Outreach_Status__c != null and Template_ID__c != null and IsClosed = false order by ActivityDate desc
The next line of the logs is
Now if I take this same exact query, copied from the logs, and run it in the Query Editor in the dev console I see one record.
Next, if I take this same exact query, copied from the logs, and run it in Execute Anonymous in the dev console I see one record.
This record definitely exists, and I can see it in the UI too.
Things I’ve Checked
Sharing for tasks is private, the code being run enforces sharing. The user running this code is an admin, and owns the task. FLS is not the issue. Other code in the package running different queries against tasks (still with sharing) includes it in results.
Is there something I’m missing? Is this just yet another quirk of person accounts? If the query failed everywhere I wouldn’t be so confused, but the fact that it works in other places has got me stumped.
Well, I should have known it would be me doing something dumb. Somewhere a couple of versions ago a few fields were added to the package, one of which was
The query has the following as part of the where clause:
and Outreach_Status__c != null
So of course, once the fields were added to the package, the code was actually querying the packaged field and not the regular custom field, despite the query in the logs showing it without the namespace.
As a workaround I’ve renamed the standard custom field so that it can be queried, so not ideal, but not the end of the world in this instance.