Support for Filtering Using Eligibility Criteria

Feedback Documentation Feedback Connectivity Documentation Feedback
1

If the eligibility criteria filter is added based on certain calculations that will change the worker lifecycle, then the added filter will act as a super set.

This is the companion discussion topic for the documentation at https://documentation.sailpoint.com/connectors/identityiq/workday/help/integrating_workday/support_for_filtering_us.html
2

Continuing the discussion from Support for Filtering Using Eligibility Criteria:

Hi SailPoint Team,
The documentation for “workday -support for filtering criteria” is not so helpful. Particularly, the examples provided are not very clear on:

  1. What would be the sample values for integration fields?
  2. what would be sample values of actual filters being enforced on aggregation data?
  3. where the aggregation filters have to configured, whether at Workday or IIQ?
  4. what would be the sequence of events/process flow during the filtered aggregation process, and at what point in the flow the filters will be evaluated?

Workday being a very common Infrastructure, I would request you to please provide more details, and this will help a lot of folks/teams out there.
Thank you very Much!

4

Hi Mandeep! Thank you for your input. We’ve created a Jira issue to track the effort and we’ll update the comment thread when it’s been addressed: CONDOCS-4104

5

Thanks Ryan, Since we are facing stringent timelines in project, please also let me know what would be the expected ETA for getting the documentation issue addressed.

6

Hi Mandeep, we’re expecting to have these updates completed in the next couple of weeks.

7

Hi @mandeepsingh,

Thank you for mentioning the details and providing feedback. We are checking into all the aspects for improving the documentation if there is any confusion. Meanwhile, please find the following answers,

  1. These filed can be used to apply filter based on custom attribute in the Workday system. We can’t provide a sample value as it varies depending on which custom attribute you are configuring in your Workday system. From connector point of view, the XPath used is, "Worker_Data/Integration_Field_Override_Data[Field_Reference[ID[@type='Integration_Document_Field_Name']='<customAttr>']]/Value"
  2. Similarly, for the sample values of actual filters. Is there any specific filter criteria that you are looking for?
  3. The aggregation filter options or configuration parameters are for the connector. It should be configured as per the documentation in the IdentityIQ - application definition for Workday. Please note that, the configuration of such fields are should be present in the Workday, then only connector can fetches the details.
  4. For this question, is there any specific scenario that you are looking for? There are different filter options available in the connector that provides flexibility to you for aggregation operation. For example, Aggregate Rescinded Future Hires - This configuration retain information for canceled future hires to support leaver workflows. For more information, refer to Aggregation of Rescinded Future Hire Records

Similarly, there are other filter conditions that you can refer from Configuration Parameters, Additional Configuration Parameters and Configuration to Fetch the Custom Attributes in Workday.

If there is any other queries or concern on this connector, I would suggest to raise a support ticket.

Thanks!

8

Hi Dinesh,

Please find my responses in Blue below**.**

To be honest, the documentation is still not updated, and the responses have been reviewed by both SailPoint or Workday developers, but we are not able to get any clarity.

Very clearly, we had articulated that what is expected from the updated documentation which will benefit not only us, but many other customers. After waiting for more than 3 weeks on a highly urgent issue, we have still not received what we were initially promised.

Thanks & Kind Regards,

Mandeep

9

Hi @mandeepsingh, we acknowledge your concern and understand the importance of documentation updates. However, this is something that is not common and values of integration fields varies from customer to customer. While this overall process is currently underway as we need to understand what all things are causing confusion here, we aim to address all your queries promptly without delay. It appears that there was a missing response in your previous message.

Could you please share the response again. In addition to that, please consider raising a support ticket by including all your questions. This will enable us to provide you with more comprehensive and timely answers.

Meanwhile, I do like to mention that the Eligibility criteria are filters (Workday calculated fields) configured on the Workday system which are used to aggregate specific data in the Workday connector. Eligibility criteria configuration in the Workday connector requires values of the following fields for configuration:

  • Integration Field (s) must be mapped with the Calculated Field (On the managed system)
  • Integration System ID
  • Integration Field Override Service

For more detail on it, you can refer to the same page that you referred earlier, Support for Filtering Using Eligibility Criteria.

I am also sharing this Workday document that you can refer or share with your Workday team for more details on the calculated fields - POST data.

Workday Admin Documentation -
Admin-Guide-Manage-Workday.pdf (3.6 MB)

Example of a calculated field and how it looks like in the Workday System -

image
image3272×910 206 KB

Thanks!

10

Hi Dinesh,

Pasting the responses below. Also, kindly let us know how much more time will it take for documentation to be updated ?

28 days ago, we raised this issue which is urgent for us but not have received any traction till now with SailPoint Support.

11

Hi @mandeepsingh, unfortunately I am not able to see any response with your above comments for my questions. Can you please share whether you raised a support case already? Please check and share the support ID so that I can also check internally?

For documentation, as I mentioned in my above comment, we checked on it but the sample values that you are asking for, varies from system to system and from customer to customer. This is a custom field defined and configured by the customer. That is reason, I shared all the above information so that you can share these details with your Workday team who are configuring these fields on the Workday system and accordingly the value can be provided/configured in the connector.

I completely understand the issue but in this case, it is not a specific ask which can be documented as this configuration is completely depends on how it is configured in the Workday system.

There are other filter scenarios and examples which are already present in the documentation as followings,

  • Example A: Connector having multiple eligibility criteria filters (Filter1 and Filter2)
    • Condition for Filter1: Workers having a name starting with character A, the result is 50 records.
    • Condition for Filter2: Workers having a name starting with character S, the result is 30 records.
    • When both the filters are set, aggregation will retrieve the data of all workers having a name starting with A or S, that is, 80 worker records will be aggregated [Filter1 UNION Filter2].
  • Example B: For eligibility criteria filter when configured with other filters (Organization reference ID filters)
    • The aggregation result will be an INTERSECTION for the eligibility criteria filter when configured with other filters (Organization reference ID filters).
    • In addition to the above filters (Filter1 and Filter2 used in Example A above), when the organization level filter (IT_DEPT_ORG_REF_ID) is added in the connector configuration then IT_DEPT_ORG_REF_ID will have 100 records out of which the number of workers having A as initials is 15 and having S as initials is 15.
    • When the organization reference filter is used in Example A, then aggregation will fetch 30 records [IT_DEPT_ORG_REF_ID intersection (Filter1 union Filter2)].
  • Example C: If the eligibility criteria filter is added based on certain calculations
    • If the eligibility criteria filter is added based on certain calculations that will change the worker lifecycle, then the added filter will act as a super set.
    • Condition: Eligibility criteria filter is written on Job code = CSTA so only those records will be aggregated that have the job code as CSTA. With additional conditions, you can retrieve terminated employees within 60 days, where 60 defines the offset.
    • In such cases if any of the terminated records do not have the Job Code, then the records will be excluded from aggregation.
    • Example: JIM is an active worker with Job Code = CSTA. If you have defined eligibility criteria using JOB CODE the record would be aggregated, however after the termination of JIM the connector will not aggregate JIM even if the configuration in the connector supports aggregation of terminated workers. After termination, the Job Code gets removed from the worker record and your eligibility criteria filter is written on ‘Job code’ = CSTA. This will take precedence with other filters and configurations to retrieve additional data. That is, the terminated records (based on the past termination offset provided in the connector).

I understand the urgency here and that is the reason I shared all the required information based on the Workday system behaviour and connector configurations. If there is a need for adding more scenarios and examples in the documentation, that will be done as well. But to do that, please work with our support team and share all your use cases. With respect to your previous questions, I replied with some additional references and Workday documentation, hopefully that will help you to understand the significance of integration fields and filters, and how it is used.

Please let me know if there is any additional questions for it.

Thanks!

12

Hi Mandeep, first and foremost I want to thank you for leaving a doc feedback comment. As Dinesh has mentioned we have decided not to make documentation changes based on your feedback and have close out the associated Jira issue. If you need more help with this issue please reach out to your Customer Success Manager, SailPoint Professional Services, or the wider devloper community.

If you need more rapid responses for information those would be the best channels to use. The documentation feedback system and there are times when it will take us some time to triage and research an issue.

Thanks,
Ryan