The push succeeded and nothing changed

Someone changes department in the HR system. The change reaches the identity provider, provisioning runs successfully, and every dashboard stays green.

Months later the downstream application still shows the old department.

Nothing appears broken because the connection itself is healthy. The problem is that the value is not moving.

Creating an account and maintaining it are different jobs

Provisioning sounds like one feature, but there are usually at least two separate operations. One creates the account. The other keeps it updated afterwards.

A mapping can be configured to populate a value only when the account is created. That works perfectly during a migration because everyone receives the correct data on day one.

The gap only becomes visible later, when somebody changes title, department, manager or another profile field.

The application was provisioned correctly. It just was not configured to keep that field current.

A green log can answer the wrong question

A successful provisioning event tells you that the provisioning system completed the operation it was configured to perform. It does not automatically prove that the field you care about changed.

The useful question is not: Did the push succeed? It is: Was this attribute included, and what did the destination do with it?

Read the detailed event or payload where the platform exposes it. If the attribute was not sent, investigate the mapping. If it was sent, move your attention to the destination.

That immediately cuts the problem in half.

The destination may have its own rules

Applications do not all treat profile fields the same way.

Some fields may be controlled by provisioning. Others can be edited by the user. Some platforms hold similar information at both organization and workspace level. The integration may update one while the interface displays the other.

Custom fields create another common problem. The field may need to exist in the destination before provisioning can populate it.

If the source is configured for a field the destination does not support, behavior varies by product. It may reject the update, ignore the field, or accept the request without producing the result you expected.

A correct source mapping is therefore only half the test.

Fixing the mapping is not always the end

Once you correct a mapping, do not assume every existing account is immediately repaired.

Some provisioning systems reevaluate the affected population automatically. Others offer an on-demand provision or resynchronization. In some cases an actual profile change is needed before the user is picked up again.

For small numbers, test one user first. For a larger correction, use the platform's supported bulk or provisioning tools rather than unassigning and reassigning users unless there is no safer option. Unassigning can remove access, disrupt sessions or produce unexpected account behavior.

Whatever method you use, verify the final value in the destination application. The identity provider already knows what the answer should be.

The check worth running

Pick a field that changes reasonably often, such as title, department or manager. Find three people whose value changed several months ago and compare that value across two or three applications provisioned from your identity provider.

If the applications disagree with the source of truth, your provisioning may be very good at creating accounts and much less good at maintaining them.

Explore this expertise: Identity & Access Management

All technical notes