ISC Attribute Sync Repeatedly Updating userID Despite Successful Provisoning

Hello Community,

We are investigating an Attribute sync behavior in ISC and would appreciate any guidanceor insights from others who may have encountered a similar issue.

Environmet : ISC
Source: Webservices connector LMS
Attribute sync enabled (identity attribute LMS start date = Account attribute activeDate)
Description - Observing recurring “Modify Account passed” events generated by Attribute sync on a daily basis for multiple attributes.

Example event

No provisoning errors but the concern is ISC continues to generate attribute sync events on the same userID /target every day and everytime previous value is null.

Hi @amithkumar1 - this can happen if there is a format difference between the value synced and the target value. Some systems will change the format. Verify the aggregated value (before the sync) and what the sync value is. Make sure the formatting is the same. The application EPIC, for example can truncate dates to m/d/yy so if you pass mm/dd/yyyy it will change it, so when it is aggregated back, ISC sees it as a different value and will try again.

@ryan_toornburg is correct that sometimes there are differences in the format ot cvalue that comes back in. Dates are one common area due to the different formats they can have. Manager is another where some get passed the ID but return the name if you don’t specify.

@amithkumar1

This happens generally due to Case Sensitivity Mismatch or format of the data mismatch.

Please check upcoming data and compare with account data.

Hi @amithkumar1,

In the above screenshot I can see that previousValue is null, which I believe is why ISC is continuously triggering the attribute sync. There could also be a format mismatch or leading/trailing whitespace issues.
Additionally, please verify whether this value is being aggregated correctly and mapped properly during aggregation

Thank you for the responses,
I ran the Account aggregation API through Postman to verify the actual value being returned by the LMS source. The value returned by API is identical to the value currently stored in the corresponding identity attribute

To further validate this behavior, I monitored the account and identity values over the past two days. Throughout this period, the activeDate value remain unchanged and consistently matched between source account and identity attribute.
Despite this, the attribute sync process continues to trigger during each identity refresh cycle.

Hi @amithkumar1,

Hi, are there any other attributes being synced apart from this, and activeDate is being sent along with that ?

By any chance, are you using an update policy?

Hi,
Yes we are using the before provisioning rule (webservice connector) and have update operation in it, but we are not managing any sync from the rule.

This behavior is often seen when the attribute sync value format differs from the account value (for example date/time format, timezone conversion, trailing spaces, null vs empty value, or string formatting differences). ISC detects a change during each sync cycle and triggers a Modify Account operation even though the business value appears unchanged.

Things to check:

  • Compare the exact values returned by the source API and the identity attribute.
  • Verify date/time and timezone formatting (2026-08-05 vs 2026-08-05T00:00:00Z).
  • Check for whitespace, null, or empty-string differences.
  • Review whether transforms are modifying the value on each aggregation.
  • Enable connector/debug logging to identify which attribute is being detected as changed.

If the value sent by Attribute Sync does not exactly match the value returned during aggregation, ISC will continue generating daily “Modify Account passed” events

Hi @amithkumar1 Can you post what the activeDate attribute and attribute value look like on the ISC Account object after an aggregation?