Rescinded Hire Automation in SailPoint IIQ and ISC
Published June 12, 2025
Insight summary and table of contents
Summary
Rescinded Hire Automation in SailPoint IIQ and ISC
When using Workday as an authoritative source in SailPoint IdentityIQ or Identity Security Cloud, you may need to automatically terminate new hires when an offer has been rescinded.
Is Rescinded Attribute
At first, this seems straightforward since the Workday connector has the “IS_RESCINDED” attribute that can be added to the application schema to handle this use case. However, before triggering a termination event on this attribute alone, it’s important to know the “IS_RESCINDED” attribute can sometimes be set to true for identities whose records are being corrected instead of rescinded. Understanding this difference is key as you build out an automated rescinded hire workflow.
If a new hire is future-dated and the person’s start date is updated in Workday, it will “rescind” the initial hire date and replace it with a new hire date. In this case, IS_RESCINDED will show “true;” however, the user should not be terminated.
The same goes for future term dates. If an employee has a future term date that’s extended, “IS_RESCINDED” will show as true.
Other Attributes to Use
In this case, you would not want to terminate the user prematurely just because of the Workday rescinded status. The solution is using “IS_RESCINDED” along with other Workday attributes such as FUTURE_DATE, FUTURE_ACTION, and ACTIVE to trigger your workflow.
One example solution is to look at “FUTURE_DATE” and the “ACTIVE” attributes alongside “IS_RESCINDED/” If FUTURE_DATE is not null and ACTIVE is “1” (true), then we know this isn’t a rescinded hire and the user should not be terminated. However, if FUTURE_DATE is not null and ACTIVE is 0 (false), then we know this is a rescinded user and it’s safe to terminate this user.
Bottom Line
While implementing a rescinded hire workflow, it’s crucial to closely work with your HR department and clearly document each possible user state and test each of these use cases thoroughly, as the logic required may be different from environment to environment.
Author: Ben Patrick, IDMWORKS, Identity and Access Management Engineer