Workday Delta Aggregation Event not picking up new Hire and "Leave"

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Which IIQ version are you inquiring about?

8.5p1

Please share any images or screenshots, if relevant.

image
image483×274 5.37 KB

Delta aggregation Event and Future Events, does contain:
“Hire Employee” and “Contract Contingent Worker”

image
image488×742 17.2 KB

From the other post I also checked the HIREDATE I haven’t change

When I run Full Aggregation I can see the new hire is populated

image
image497×113 6.28 KB

Also, I have observed, if I do a get API call using bruno, in response there is no “HIRE_DATE” tag, so not sure how even the hiredate is being populated with same value as Original Hire Date when we run full aggregation

image
image725×303 11.7 KB

2

@Krank For delta aggregation to work, you need to allow the transactions/events at Workday end as well? Have you already made those changes?

3

@Krank Regarding HireDate, check your app xml, there should be SOAP XML attribute mapping must be defined. Could you please share your workday xml for review?

4

Hello Kranti. Since full aggregation finds the worker but delta does not, I would first check the delta-specific Workday Business Process Security Policy permissions. The Integration System Security Group used by the connector needs View Completed Only on the related business process:

  • Hire Employee → Hire
  • Terminate Employee → Termination

After updating it, run Activate Pending Security Policy Change and test delta again. Permissions to Business Processes for Delta Aggregation

Your EffectiveDateOffset=18 and Future_Hire_Events look fine for the 10/05 future hire. SailPoint’s troubleshooting guide also notes that the connector adds the core Hire/Terminate events internally, so their absence from your custom Delta_Aggregation_Events list would not by itself explain this. Troubleshooting

Since you are already testing in Bruno, I would send the delta-style Get_Workers request using Transaction_Log_Criteria_Data for the same time window. If the Hire transaction is not returned there, that points more toward Workday permission or event visibility than later IIQ processing.

For HIREDATE, I would leave the mapping unchanged. The documented default is Worker_Data/Employment_Data/Worker_Status_Data/Hire_Date.

Also verify that the IdentityIQ server time is synchronized with the configured Workday Effective Time Zone, since delta uses the last aggregation time when building its window. Troubleshooting

I would start with the Hire/Termination Business Process permissions.

5

I forgot to mention, we do have “Hire” and “Termination” assigned to ISU.
I checked the get_worker API call with Transaction_Date_Range_Data and I’m able to get the worker.

SailPoint’s troubleshooting guide also notes that the connector adds the core Hire/Terminate events internally, so their absence from your custom Delta_Aggregation_Events list would not by itself explain this.

I did include this in “Delta_Aggregation_Events”
Hire Employee
Contract Contingent Worker

I even added PST as mentioned in the troubleshooting document.
“CustomServerTimeZone” to “PST”

No luck yet.

6

It is OOTB .

7

Do you mean the permission mentioned here: https://documentation.sailpoint.com/connectors/workday/help/integrating_workday/permissions_to_business\_.html
I believe we do have correct permission in Workday tenant, as I’m using same ISU in bruno that we have in workday app, and I’m able to get the response in bruno.

8

Hello Kranti. Thanks. Getting the worker with Transaction_Date_Range_Data confirms Workday can return it, but the open question is whether your Bruno request used the same transaction criteria and Updated_From / Updated_Through window IIQ generated. I would now capture the exact Get_Workers request IIQ sends during delta aggregation and replay it unchanged in Bruno.

If that exact request does not return the worker, compare the transaction criteria and Updated_From / Updated_Through window. pastEffectiveDateOffset can include updates dated before the last aggregation.

If the exact request does return the worker but IIQ still skips it, I would then focus on connector-side response/XPath processing rather than Workday permissions.

Also, since you added CustomServerTimeZone=PST, check the application Debug page for a legacy Server Time Zone entry. SailPoint notes that if both Server Time Zone and Effective Time Zone exist, Server Time Zone takes precedence. Upgrade Considerations

9

I have enabled these loggers:
logger.workday.name=sailpoint.connector.OpenConnectorAdapter
logger.workday.level=all

logger.workdayPriv.name=openconnector.connector.WorkDay
logger.workdayPriv.level=all

Also what tag/words should I be looking for in the logs after I run the delta aggregation ?
After running the delta aggregation I searched for “Transaction_Log_Criteria_Data”, “Transaction_Date_Range_Data” , “Updated_From” , I didn’t get any hits.

<< Harish>> check the application Debug page for a legacy Server Time Zone entry.
<> You mean the about page? I checked the timezone is “America/Toronto”

10

Hello Kranti. Thanks, this helps. Your current loggers may just not be printing the SOAP body. For one test run, I would also enable these classes. The Workday logger casing matters, and these can generate a lot of logging:

connector.common.http.client
connector.sdk.webservices
openconnector.connector.workday
openconnector.connector.WorkDay

These same classes were recommended in an IIQ Workday troubleshooting thread for deeper connector logging. Community thread. After the delta run, search around that task time for Get_Workers, Hire Employee, the worker Employee ID, Updated_From, and Updated_Through.

The key thing I would check is which Get_Workers request actually returns this worker. Future-dated workers can also be picked up during delta, so I would focus on the actual request criteria and response rather than assuming one path. Future Dated Workers.

On the timezone, I meant the application config, not the About page: Debug > Object Browser > Application > your Workday app. Also check the Effective Time Zone on the application UI. If both a legacy Server Time Zone and Effective Time Zone exist, SailPoint says Server Time Zone takes precedence. The America/Toronto value on the About page does not tell us what the Workday application is actually using. Upgrade Considerations

11

@Krank There are few more things could you please check:

  1. SKIP_FUTURE_TERMINATION_RECORDS: Check if <entry key="SKIP_FUTURE_TERMINATION_RECORDS" value="true"/> exists in your Application XML. If this is set to true, the connector explicitly bypasses future terminations. Ensure it is false (or removed, as false is the default).

  2. Also in your screenshot I don’t see * Terminate Employee or * End Contingent Worker Contract. Could you please check and if missing please add it to Delta_Aggregation_Events entry in your application xml.

  3. Also, can you please add pastEffectiveDataOffset entry in the app xml. Could be wrong, but if you don;t have past offset and due to time zone difference if end/hire date is today, you may miss the record. Here it means connector going to include account updates up to 30 days old in delta aggregation.

<entry key="pastEffectiveDataOffset" value="30"/>

In case this doesn’t work, please enable below logs and also share your app xml.

logger.workdayLog.name=openconnector.connector.WorkDay
logger.workdayLog.level=trace
12

I did add the loggers, fortunately the issue is resolved by itself. I did not do any configuration/code changes. Maybe the workday team created new hire differently this time. This has happened to me before, enabling logs has resolved issues without any code changes. This is quite strange behavior.

Effective Time Zone was already PST (I think this what they called in debug CustomServerTimeZone)

Anyway, thanks for your time.

13

Thanks for taking time to respond. We only want to ingest future hires. Yes, I did add the pastEffectiveDataOffset in debug and also checked if it is reflecting properly in UI.