Share all details about your problem, including any error messages you may have received.
Hi,
We are on 8.3p3 and observed a strange behavior when we switched our identity mapping manager from a global rule to an application-based rule.
After this switch, SailPoint no longer gives preference to whatever is returned from the rule. Instead, it just sees which authoritative source is listed first in the identity cube and maps the manager based on the first found authoritative link in the cube. Even if the authoritative source is disabled, SailPoint picks the manager from the first authoritative source it sees in the application accounts of the identity.
The identity mapping rules are not updating the manager correctly if one rule per application is used. Only when we use the global rule is the manager updated based on the output of the rule.
Anyone faced similar issue or any pointers would be helpful
Hi @abhishek_chowdhury - For the application based rules, first in wins. The global rule is the way to go. It may be a more complex rule, but it can handle your specific scenario. Also make sure you don’t have any conflicting Manager Correlation rules.
Hi @abhishek_chowdhury That is expected behavior if the 1st source in the attribute mapping returns a value. If looking at multiple sources a Global Rule is your best bet. You can use individual application rules, but the 1st one to return a value is the one that is set and the others are not processed. If you want to skip disabled users, then your application rule should check for that user state and return a null so it processes the next rule and so on.
So you are saying it is not setting the manager based on the 1st mapping in the identity attribute, but the 1st authoritative application link on the identity? I have never had luck with multiple auth sources using individual app rules to set the manager, there were always problems. A global rule did a much better job dealing with that scenario. What is the reason you switched over?