Field note
Entra Provisioning: Null and Missing Values
An omitted department field can become a directory change once null flow is enabled.
An integration may use an absent field to mean “nothing changed”. A receiving system may interpret the same absence as “remove the old value”. Both implementations can appear reasonable until a routine update clears information that another workflow depends on.
Microsoft’s 12 October Entra roundup includes preview null-value provisioning.
Before enabling it, agree what an empty value means for each attribute and each source.
The behaviour that needs attention
Microsoft’s null-clearing documentation describes an opt-in setting at two places: the source schema attribute and the target mapping. Both must allow null flow before an empty source value clears the mapped target during an update.
The preview applies to supported inbound provisioning scenarios and single-valued attributes. It is not a general promise that every connector, outbound integration or multi-valued field supports clearing.
For API-driven inbound provisioning, Microsoft’s API guidance warns that omitting a null-enabled attribute can also clear its target value. It recommends complete user records for both full and delta submissions. This is the detail to review with the developer who produces the payload.
Do not enable the feature solely because an old office telephone number remains in the directory. First establish whether the source feed represents removal consistently.
Write the attribute contract
Use an example record before touching production. Suppose a test employee has a department value of “Operations”. The following is an illustrative review table, not a tested tenant result.
| Source record sent | Intended business meaning | Expected result to agree |
|---|---|---|
| Department contains “Finance” | Employee has moved | Replace the old value |
| Department is explicitly empty | Department was intentionally removed | Clear only if approved for this attribute |
| Department is omitted | Producer sent a partial record | Reject the incomplete record or supply the full source state |
| Source lookup failed | The producer could not establish the value | Stop or quarantine the record; do not manufacture an empty value |
The last row belongs in the integration design. A failed HR API request must not silently become a successful payload full of empty attributes. Preserve the difference between “known to be empty” and “could not be read”.
List downstream consumers of each candidate field. Department, manager-related data and custom attributes may drive access, reporting or communications. Ask those owners what happens when the value disappears. A technically optional attribute can still be operationally significant.
Keep creation defaults separate from updates
The attribute-mapping reference explains that the default-if-null setting applies during user creation, rather than acting as a general update fallback. Do not assume a configured default will rescue an incomplete update.
For every candidate attribute, record its source, target, transformation, creation default and null-flow settings. Review the source producer as well as the Entra configuration. A complete record at one stage can become partial after a transformation or error-handling branch.
Exclude matching identifiers and fields required to create the account from the initial clearing pilot. Microsoft’s preview guidance specifically cautions against enabling clearing for attributes required to match or create users.
Use one harmless optional attribute and a small, approved population to prove the path. Keep the source values and mapping configuration available for comparison and recovery.
Verify the target, not the upload response
Microsoft’s API-driven flow is asynchronous: acceptance of an upload is followed by provisioning processing and record-level log results. A successful submission response is therefore not the acceptance test.
Run a deliberate value change, an intentional clear and a complete unchanged record. Review the individual provisioning outcome and the target object after each. Add the incomplete-record and failed-source tests to the producer’s validation, so they fail before a damaging payload is submitted.
Repeat the same approved record to check that ordinary retries do not create unexpected changes. The repeat should be part of a defined test sequence, not an assumption about how every connector behaves.
If values clear unexpectedly, pause the affected feed or mapping under the change plan. Restore the last approved configuration and identify precisely which records changed. Disabling null flow will not reconstruct already removed data; recovery needs trustworthy source values and a controlled replay.
Extend the pilot attribute by attribute. The useful result is a documented contract between the producer and the directory, with evidence that deliberate removal works and uncertainty does not get converted into deletion.
References
- Microsoft — October Entra announcement, 12 October 2026. Accessed 17 October 2026.
- Microsoft — Clear attribute values (Preview). Accessed 17 October 2026.
- Microsoft — API-driven inbound provisioning concepts. Accessed 17 October 2026.
- Microsoft — Customise provisioning attribute mappings. Accessed 17 October 2026.
Related notes
17 Oct 2026 · 4 min
17 Oct 2026 · 5 min
17 Oct 2026 · 4 min
Need help mapping this to your own tenant, controls, or assessment timeline?