SuccessFactors to AD provisioning: accountDisabled expression evaluates True but is not exported in Modified Properties

Question

SuccessFactors to AD provisioning: accountDisabled expression evaluates True but is not exported in Modified Properties

Sri Lekha G 0

Hi Team,

We are working on Microsoft Entra provisioning from SAP SuccessFactors to on-premises Active Directory.

Use case: We need to disable or enable the AD account based on two SuccessFactors custom fields:

customString25 = Exempt flag

customString27 = Block Leave flag

Expected logic:

If customString25 = Yes, the user should remain enabled.

If customString27 = Yes and the user is not exempt, the AD account should be disabled.

If customString27 = No/blank and the user is not exempt, the AD account should remain enabled.

If activeEmploymentsCount = 0, the AD account should be disabled.

Current accountDisabled expression configured in Entra:

IIF([customString25]="Yes",False, IIF([customString27]="Yes",True, IIF([activeEmploymentsCount]="0",True,False)))

Configuration verified:

customString25 and customString27 are visible in Entra Import User.

accountDisabled mapping type is Expression.

accountDisabled mapping is set to apply Always, not only during object creation.

Expression Builder returns the expected Boolean True/False values.

Test AD account is currently enabled.

User matching between SuccessFactors and AD is successful.

Termination and rehire scenarios worked earlier, so AD enable/disable permissions appear to be working.

cn and manager mappings were adjusted so they should not block this test.

Issue: During Provision on Demand, the expression evaluates correctly in the expression builder, but accountDisabled is not consistently appearing in the final Evaluate Action / Modified Properties, and the AD account is not being disabled for the Block Leave scenario.

Question: Why would accountDisabled not be included in the final export/modified properties when:

the expression evaluates to True,

the mapping is set to Always,

the AD account is currently enabled,

and the user is matched successfully?

Is there any known limitation, cache/delta behavior, restart requirement, or connector-specific behavior when newly added SuccessFactors custom fields are used in an accountDisabled expression for provisioning to on-premises AD?

Any guidance or troubleshooting steps would be appreciated.

Sridevi Machavarapu 30,110 Reputation points Microsoft External Staff Moderator

2026-05-15T21:40:16.11+00:00
Hello Sri Lekha G,

The expression and configuration appear correct, especially since the Expression Builder returns the expected True/False values.

One recommendation is to handle activeEmploymentsCount as an integer to avoid possible type comparison issues:

IIF([customString25]="Yes", False, IIF([customString27]="Yes", True, IIF(ToInt([activeEmploymentsCount])=0, True, False)))

If accountDisabled is not appearing under Modified Properties, the provisioning service may not be detecting the attribute as a change, so the export is skipped even though the expression evaluates to True.

Please check the following:

Restart provisioning after saving the updated mappings, especially if customString25 and customString27 were added recently.

Confirm there are no other mappings updating accountDisabled.

Allow a regular provisioning cycle to run in addition to Provision on Demand.

Review provisioning logs for messages indicating the export was skipped because no change was detected.

As a quick isolation test, temporarily set the expression to:

True

If accountDisabled still does not appear in the export details, the issue is more likely related to provisioning cache/state behavior than the expression logic itself.