Preventing cyclic syncs

Hello All,

We have a requirement to generate mail from SailPoint. On authoritative aggregation, we create AD account for joiners that generates unique mail in AD (Account attribute generator rule). In the IP mappings, we use a transform like this to populate the AD generated mail in the email identity attribute:

{
        "type": "firstValid",
        "attributes": {
            "values": [
                {
                    "attributes": {
                        "sourceName": "Active Directory",
                        "attributeName": "mail"
                    },
                    "type": "accountAttribute"
                },
                "[email protected]"
            ]
        }
    }

However, we notice that for all the users upon creation, the AD account is created with the expected generated mail (correct mail generated in create plan request) but then, the modify account is triggered where the mail is reverted back to the fallback mail (as given in transform) and this mail is set in AD. This not just happens a single time, but again the modify account is triggered to the generated mail and some kind of syncs happen in loop.

This happens something like this when looked on event activities:

  1. Modify acc passed -
    Previous value: AD Generated mail
    Current value: [email protected]
  2. Modify acc passed -
    Previous value: [email protected]
    Current value: AD Generated mail
  3. Modify acc passed -
    Previous value: AD Generated mail
    Current value: [email protected]
    And so on.

Luckily, few users have the sync stopped with the correct generated mail set in identity attribute and AD account attribute. While few users have the fallback mail set both as identity attribute and AD account attribute.

What and why exactly happens here though I observe some random order of execution? How to avoid this kind of unpredictable syncs?

Any inputs are most welcome.

Hi @varshini303 ,

Do you have any provisioning policy with MODIFY operation define for AD source? Is that changing the values?

Hi @JackSparrow , we have not defined any other than the CREATE provisioning policy.

A conditional transform may work better here

You could actually test for the presence of an email value and only set it to the default value if no email is present.

Hope this helps

Hi @sk8er23 ,

But the same comparison is done via the firstValid transform, that is deployed right.

Yes it that should work, without more information about your configuration it will be hard to comment. Your transform should only write the default value if no value is present.

What is the source and attributeName here?
Have you set attribute sync for any other attribute in AD from the Identity Attribute that gets updated from the FV transform you shared?

If there is no attribute sync set, then such updates should not be triggered. But, if there is a cyclic reference involving a third attribute then you need to eliminate the same

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.