Record Not Returned in Query in Managed Package

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.

The Problem

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 Rows:0.

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.

The Question

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 Outreach_Status__c.

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.

Source : Link , Question Author : Matt Lacey , Answer Author : Matt Lacey

Leave a Comment