Forum Discussion
Microsoft Graph API : Some attributes are null when filtering by signInActivity/lastSignInDateTime
Are you getting the data for the same users though? Keep in mind that when you query the signInActivity property, Graph makes a call to a different service on the backend, and only then correlates the results with the user store. There are few implications here, the first one being that said service doesn't give you real-time data, so any changes in user properties are not reflected immediately. Another one is that the service returns sign in activity for cross-tenant access, that is it gives a separate entry for when a email address removed for privacy reasons accesses any other tenant, and said entries are populated without any user details apart from id. I wrote an article about this a while back: https://www.michev.info/blog/post/5845/non-existent-users-show-up-in-sign-in-activity-data-or-how-logs-continue-to-disappoint
So now that we know permissions are not the issue, make sure the user data is in order. The article above also tells you how to query the AAD reporting service directly, so you can see the "raw" replies therein.
Hi Vasil. Thanks for the link to your article. I also did another test where I know for sure my test user will appear in the results:
const graphUsersUrl = "https://graph.microsoft.com/V1.0/users?$top=999&$filter=signInActivity/lastSignInDateTime ge 2025-06-23T14:45:15Z and signInActivity/lastSignInDateTime le 2025-06-25T14:45:15Z&$select=id,givenName,surname,identities,signInActivity";
In the result after running the above query, I can find my test user with the correct GUID (but NO givenName or surname) in the result set (there are other users in the results too, which is the scenario you mentioned in your article (e.g. other tenants etc).
Why is it that the correct GUID for my test user is in the result, but the givenName or surname are null? With the correct GUID, it is not a mismatch GUID for other tenants.
- VasilMichevJun 27, 2025MVP
Dunno, looks like it fails to match the id returned from the reporting service to the user object for some reason. If you are able to reliably reproduce this behavior, best open a support case and report it.