IdentityIQ SuccessFactors Connector Not Pulling All Future-Dated Hires Correctly

[brandonmoxley]

Which IIQ version are you inquiring about?

8.1p2

Share all details about your problem, including any error messages you may have received.

We’ve found ourselves in an interesting position with the SuccessFactors OOTB connector, in combination with currently being on an out-of-support version of IdentityIQ (8.1p2; we are working towards an upgrade, but it could be some time still). Due to being out of support, SailPoint has only provided a small amount of assistance for our issue and suggested posting out here.

Recreating the Problem:

• User was previously an Employee, and is currently terminated with a past termination date
• User has been rehired as a Contingent Worker, with a future hire date

The Problem:
For some reason, when there is both this gap in employment, as well as a conversion from Employee to Contingent Worker at the same time, the OOTB SuccessFactors connector seems unable to see (or chooses not to see?) the future record for the user, and instead continues aggregating the past/terminated record. This prevents our re-hire lifecycle event from firing, and as such requires manual intervention to complete the re-hire specific work so that our managers can begin submitting the necessary requests.

Has anyone else seen this same behavior? When we had some time with SailPoint before they sent us to the Developer Community, they provided this article.

Aggregation of Additional Schema Attributes Using SFAPI (sailpoint.com)

They also provided this screenshot, showing an example of how to configure complex regex in order to get a future Manager for a user when there is no currently active record. I rebuilt this query by simply typing it out and cleaned it up a bit. After that, I had a few questions which I sent to SailPoint, but which they have not answered due to our unsupported version.

Here is my “cleaned” / textual version of the XPath in the screenshot:

Attribute:
Manager1

Value Calculation:

if (empty(/person/employment_information[xs:date(start_date) le xs:date(current-dateTime() + xs:dayTimeDuration(‘PT10H’))]))

then /person/employment_information[xs:date(start_date) ge xs:date(current-dateTime() + xs:dayTimeDuration(‘PT10H’)) [1]/job_information[1]/custom_string29

else /person/employment_information[xs:date(start_date) le xs:date(current-dateTime() + xs:dayTimeDuration(‘PT10H’))][last()]/job_information[xs:date(start_date) le xs:date(current-dateTime() + xs:dayTimeDuration(‘PT10H’))][1]/custom_string29

Here is my understanding of this query:

• The IF statement is checking for the LACK OF an ‘employment_information’ block in SuccessFactors, which has a ‘start_date’ listed which is less than or equal to 10 hours in the future
• The THEN statement queries back the first listed future (based on “10 hours from now”) ‘employment_information’ block from SuccessFactors, then grabs the first ‘job_information’ block from that, and then grabs the attribute value for ‘custom_string29’
• The ELSE statement queries back the LAST XML entry from a list (could be a single item too) of past (based on “10 hours from now”) ‘employment_information’ blocks from SuccessFactors, then grabs the first ‘job_information’ block from that which also has a past (based on “10 hours from now”) ‘start_date’, and then grabs the attribute value for ‘custom_string29’

Finally, here are my questions I have related to all of the above - Is anyone able to help shed some light on all of this?

• Can you please review my understanding above and let me know if it is accurate?
• What is the importance of adding 10 hours to each of these time-based queries?
• How can we account for a wide range of time zones for our users in these queries?
• SailPoint told us previously that we’d have to create totally separate attributes to accommodate any use case where we need “future data” (so second attributes for Manager, Title, Department, etc.) – Why can’t we use the existing and have the XPath simply determine the correct value?
• Does ‘custom_string29’ in the provided example tie back to a Manager ID or something that will be picked up by the correlation logic? Mostly curious why this wouldn’t be using an already manager-specific field (such as: ‘manager_id’, ‘manager_person_id’, ‘manager_person_id_external’, etc.)

Thanks for any help anyone is able to provide here!