Just as a heads up, EVERY time there is ANY change on the account, it will try to run the OU move. You might want to put a check in there so its only tries to move when there is a difference between where it is and where it should be
Hi @Caio_Nakayama What is the actual error message and/or what is the outcome in AD? Also, have you had any failed attribute syncs which it may be attempting to retry?
I’m not sure there’s an error in your initial post. What you shared is the Provisioning Plan
I believe the fact that the data is multivalued is because it’s multivalued on the identity level (thus it is so on the authoritative source(s) level). If that’s the case, you might need to recheck how you’re aggregating your data and your data quality.
I’m also aligned with @phil_awlings’s perspective about the new parent and new name, the solution he shared is interesting. But if you can deploy a Service Standard Before Provisioning Rule that will be better as it can be reused for any other source.
Sounds odd right ?
I had some cases where the attribute has comma separated values on the identity level (type String not List) and when pushed to the target application, it was parsed as a List.
Had a big issue for a client that was pushing a Json object inside a String but SailPoint kept parsing it as an Object so instead of :
{“data”: “{1:2, 3:4}”}
it was : {“data” : { 1:2 , 3:4} }
Can you now go to the search and write this query : sources:"Active Directory" and find the result of type Account Activity corresponding to that request then click on the source on the left side of the result: Active Directory and share with us the result (it should be the provisioning plan sent to your AD)