Once you're familiar with the fields that are available for you to search on, you can start constructing queries. You can use those fields and choose search terms to find important information about your data.
You can use the
_exists_keyword to search for items that have any non-null value in the specified field.
Could you please add a better definition for the _exists_ keyword that explains the odd behavior reported by @angelo_mekenkamp here?
I see users returned when using the positive search query:
I see user returned when using the negative search query (having an end date):
I’ve created a ticket to investigate and document the behavior of the _exists_ keyword: SAASDOCS-8669
I’d appreciate a bit more detail on the specific issue you’re both seeing, if possible.
@adamian, could you give me some more details about what the expected behavior is, vs. what you’re actually seeing in your tenant?
@angelo_mekenkamp, if you’re available to chime in on this I’d very much appreciate it, although I understand the thread you created is very old.
Thank you @rebekah_reveile for looking into this.
I indeed tried to flag this bug to SailPoint a long time ago, but got stuck with a “nothing wrong here, works as expected” response. I see now that other partners/customers are noticing the same issue with the exists keyword behaving incorrectly.
Please checkout ISC Search _exists_ keyword unexpected behavior
And in particular checkout ticket #PLTDP-4093 (which we can’t see ourselves as it is an internal ticket)
Please let me know if you need anything else @rebekah_reveile
Thanks, Angelo. 
It seems like the expected behavior is for _exists_ to show anything that isn’t null, and what it shows instead is anything that isn’t null that is in the expected format based on the field. Is that an accurate interpretation of the problem y’all are seeing?
I’ll also double check with the engineering team. Thank you both for bringing this to our attention.
Yeah that is getting close to the core of the issue. Thank you for validating! I would like to add that from a customer/partner endpoint perspective, there is no expected format of this field. It is just a string if you look at the identity attributes API. list-identity-attributes | SailPoint Developer Community
Somewhere internally in SailPoint it might have been written somewhere that certain identity attributes should be in a specific format, but this is not enforced, documented or necessarily used by customers. We can choose the format ourselves and use it in attribute sync in the way we get the value from an HR source and populate it to target applications. It seems that just in search, it fails here. So perhaps this format was once an idea and then chosen to be abandoned? But if it is should still be a mandatory format (which I hope it’s not), it has been enforced and documented poorly.
Where would you expect to find the formatting requirements for each field? We have the required formats documented, but if you haven’t seen it, that means there are others that haven’t seen it either. I’d like to add more info so that other customers and partners can find this information more easily.
On which places is this documented and why is this even a requirement from SailPoint? What benefit justifies this limitation?
Kind regards,
Angelo
The required format for each field is documented in Searchable Fields. In the description for each date field, we state that an ISO 8601 format is required for date-type fields.
For an explanation of this limitation, I’ll bring in @erik_huckle, the product manager for Search. Can you give us some more information on the benefits of formatting requirements for the values in searchable fields?
Hi @rebekah_reveile,
Yes, I have seen this. But this is incorrect information. We can’t determine the input type ourselves. Search is automatically taking these values (with a 24 hours SLA) from the identity attributes startDate and endDate. And these identity attributes are not of type date, but are of type string, which is also why we don’t get errors when we perform account aggregation on the authoritative source and map these account attributes to the identity profile to startDate and endDate. These are of type string and can accept things like 2021-08-13T12:00:11.001Z, but also 2023:1:6 or 24-12-15, or 15-12-2024, or even Jun 12th 2024. It is then possible for the customer to define a transform with a dateformat and datecompare operation, to use the date in the way they receive it, to determine lifecycle states.
Perhaps a wrong assumption has been made here by the search team, by documenting that the values that we get here are dates in ISO 8601 format, because they can’t guarantee this and it is not always the case for customers. Different customers can have different values from the authoritative sources. As a consequence of this wrong assumption, if we search for !_exists_:attributes.endDate, we can still see in the results rows where there is a value for endDate visible. Hence the remark from @adamian:
Thank you for clarifying, Angelo. I’ve reached out to the engineers for more information on this, and I’ve added your comments to our ticket. Thank you for helping to improve our docs!
Hey Angelo! Thanks for your patience as we sort this out.
We’ve updated the documentation about the _exists_ keyword in the Building a Search Query doc to reflect the actual behavior of the _exists_ keyword. After checking with the developers, we’ve confirmed it does return only values with the format listed in the Searchable Fields doc.
But I also spoke with @jordan_mandernach, the product manager for this feature, and we discussed investigating this behavior further. Jordan, this is the thread I told you about. Please let me know if you need anything.
