What problem are you facing?
When using queryType: UserValidation (and other query types), the function returns only a fixed set of fields — id, displayName, userPrincipalName, mail — which are hardcoded and cannot be configured. In practice, compositions often need additional Entra ID attributes alongside user identity, such as department, jobTitle, city, or officeLocation, to drive downstream logic (e.g. setting resource ownership metadata, access policies, or labels based on org structure).
The same limitation applies to GroupObjectIDs (no visibility, mailNickname) and ServicePrincipalDetails (no servicePrincipalType). Currently the only workaround is to add a separate pipeline step or an external data source, which adds complexity and additional API calls.
How could this Function help solve your problem?
Add an optional additionalFields []string input parameter that appends extra Microsoft Graph attributes to query results for all supported query types:
input:
apiVersion: msgraph.fn.crossplane.io/v1alpha1
kind: Input
queryType: UserValidation
usersRef: spec.owners
target: status.validatedUsers
additionalFields:
- department
- jobTitle
- cityExpected result:
status:
validatedUsers:
- id: 1bbbbbbb-...
displayName: Some Name
userPrincipalName: someName@example.com
mail: someName@example.com
city: Kyiv
department: Ops
jobTitle: Staff EngineerThe field should be optional and backward-compatible — omitting it produces the same output as today. Fields not present for a given object should be silently skipped rather than causing an error.
What problem are you facing?
When using queryType: UserValidation (and other query types), the function returns only a fixed set of fields — id, displayName, userPrincipalName, mail — which are hardcoded and cannot be configured. In practice, compositions often need additional Entra ID attributes alongside user identity, such as department, jobTitle, city, or officeLocation, to drive downstream logic (e.g. setting resource ownership metadata, access policies, or labels based on org structure).
The same limitation applies to GroupObjectIDs (no visibility, mailNickname) and ServicePrincipalDetails (no servicePrincipalType). Currently the only workaround is to add a separate pipeline step or an external data source, which adds complexity and additional API calls.
How could this Function help solve your problem?
Add an optional additionalFields []string input parameter that appends extra Microsoft Graph attributes to query results for all supported query types:
Expected result:
The field should be optional and backward-compatible — omitting it produces the same output as today. Fields not present for a given object should be silently skipped rather than causing an error.