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.
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.
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,
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
After the investigation indicates that the issue is caused by the account attribute being multi-valued, while the corresponding identity attribute is single-valued.
During the AAA session, we were advised to handle the activeDate attribute through a Before provisioning Rule. Our connector includes both a Before provisioning rule and a Before operation rule. Can I use the existing Before Operation Rule (with the modify operation/function), since we are already handling the modify operation in the Before Operation Rule, instead of creating a function in the provisioning rule? Or should we use only the Before provisioning rule? Would the Before Operation Rule trigger on every identity refresh?
Specifically, can we use the Before Operation Rule to compare the incoming identity/provisioning plan activeDate with the existing account activeDate, and update the applicable account only when the values differ?
Please confirm whether the Before Operation Rule or Before provisioning Rule is recommended for this use case, and please provide example snippet.
In account aggregation sometimes these attributes are not coming, create a transform which will store old value if new value is null get old value so you wont see these many events daily
With multi-valued attributes, when pulling that data you want your endpoint to order data / sort it ascending or decending; as when it is returned for one aggregation it may report one order and for a separate aggregation different order.
My situation is calling an API middleware that is doing SQL calls to various tables.
Hey @amithkumar1, don’t waste time on provisioning rules, the root cause is right in front of you. Attribute Sync only compares single-valued strings. Because activeDate is marked as multi-valued on your account schema, ISC stores it as a list, fails to read a scalar value, evaluates it as null (hence previousValue: null), and needlessly pushes an update every single refresh cycle.
Just change activeDate to single-valued in your LMS Account Schema, verify your JSON response mapping returns a direct string, and run an unoptimized aggregation to clear the cached list. That should stop the daily sync loop completely.
Hi @amithkumar1 , thats one of the common misconseption with account schemas definition.
Multi-valued means a single account holds multiple dates at once (like a list of values: [“2024-01-01”, “2024-06-01”]). If an identity has 2 separate accounts, each account still only holds its own single date, meaning the account attribute must remain single-valued.
When Attribute Sync is enabled on a source, ISC evaluates and syncs to all accounts linked to that identity independently by default. So leaving activeDate as single-valued will naturally update both accounts without breaking the sync engine or causing the daily loop. Change it back to single-valued, run an unoptimized aggregation, and it will work as intended across both accounts.
