Skip to content

Field note

Entra Provisioning: Null and Missing Values

An omitted department field can become a directory change once null flow is enabled.

Published17 Oct 2026

Updatedyesterday

Read time4 min. 836 words.

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.

Department contains “Finance”Employee has movedReplace the old value
Department is explicitly emptyDepartment was intentionally removedClear only if approved for this attribute
Department is omittedProducer sent a partial recordReject the incomplete record or supply the full source state
Source lookup failedThe producer could not establish the valueStop 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

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?