My understanding is that for any change in the identity attribute ‘proxy’, then the rule should push out the value of identity.proxy to Active Directory field ‘department’.
This is not working though. What am I missing?
Thanks
The rule is in place:
EDIT:
It is working (ish). Sailpoint is occasionally trying to push the attribute out. This doesn’t work on every change to the Identity attribute, but even when it does, it is not being written to AD:
PS I know I’m setting the smpt to the department field, juts trying to get it to work as I don’t think that I can update the proxyAddress field using this method
The Identity Attribute Triggers are not actually triggers. They are just filters to limit the triggering of the event to users with specific Identity attributes.
As per your configuration, the event will apply for every modify operation in the source for users with a value in the proxy Identity attribute.
You may need an Account Attribute Update Trigger to achieve your case by making use of the attribute that is syncing your AD source.
Hi @jesvin90,
The identity.proxy attribute has a transform on it that only delivers a change in value under specific circumstances, and it is that change that I need to propagate into AD.
Specifically I am trying to update proxyAddresses, which cannot be done via Attribute sync as its a multi-value, and cannot be done by Account Update (in the provisioning plan) for a complicate reason for my specific use case.
If my configuration is set to apply on every change to identity.proxy attribute, the question is, why is it not working for every change? The follow up question, is when it does work, why is nothing being written to AD even though there is a ‘set’ event log.
I cannot use Account Attribute Update trigger as the attribute has not been updated, and, as per the above, you can’t sync a multi-value attribute
The configuration does not trigger events for Identity attribute changes. It triggers only when there is a modify operation (attribute sync, AD group add/remove etc.) on your AD source.
For the follow up question - yes, I would expect the update to happen in AD when there is a set operation in your plan. Probably because department is a multi-valued attribute in AD and your normal set operation may not work.