HRIS integration is not where identity governance projects fail loudly. It is where they fail quietly. The connector shows green. Aggregations run on schedule. Dashboards look healthy. And somewhere downstream, a new employee arrives and their account is not created, or a departed contractor still has access three months after their end date.
The HR source is the authoritative source for identity in any well-designed SailPoint ISC deployment. When it is wrong, everything built on top of it is wrong. Based on implementation experience, here are the five failure patterns that appear most consistently — and what to do about them.
1. Credentials That Expire Without Warning
The scenario: the HRIS connector has been running smoothly for months. Then it stops aggregating. No new identities are created. No leaver accounts are deactivated. The source status in ISC might still show green, or it might show a vague error that does not clearly indicate authentication failure.
The cause is almost always expired credentials. HR system APIs — whether REST endpoints, SOAP services, or file-drop mechanisms — frequently use credentials that have a defined lifetime: API keys, passwords, certificates. The HRIS vendor rotates them on a schedule and may or may not send advance notice. ISC does not always surface an authentication failure with a clear error message. The aggregation fails silently.
What to do:
At project start, ask the HRIS vendor for the credential expiry policy and record the date. Set a calendar alert at J-30 before expiry. Before go-live, validate credentials directly from the Virtual Appliance — not from a developer laptop — because network isolation means a successful test from outside the VA proves nothing about VA connectivity.
Build a simple alert: if the HRIS source has not completed a successful aggregation in 24 hours, someone needs to know. A governance program with a silent aggregation failure is no governance program at all.
2. Testing Connectivity From the Wrong Place
This failure mode appears early in projects and wastes significant time if not caught immediately. A developer validates that the HRIS API is reachable, the credentials work, the endpoint returns data. Everything looks good. The source is configured in ISC. The aggregation fails.
The Virtual Appliance is a hardened, network-isolated component. It sits in its own network segment, with its own firewall rules, and it cannot reach everything that a developer workstation can reach. If the HRIS API is not explicitly allowed from the VA’s network address, aggregation will fail at the network layer — often without a meaningful error in the ISC logs.
What to do:
Before configuring any source in ISC, test connectivity directly from the VA console. Use curl or the equivalent tool from the VA shell to reach the HRIS endpoint. Validate the full stack: network reachability, TLS certificate validity, authentication, and a sample data response. If any of these fails from the VA, resolve it before touching ISC configuration.
This also applies to every source, not just HRIS. Every API-based source has the same exposure.
3. Lifecycle States That Reflect Technical State Instead of Business State
Identity governance works when the people responsible for access understand what the governance model means. Lifecycle states are a critical part of that model, and they are frequently designed in a way that makes the model opaque to the business.
A lifecycle state like AUTH_PENDING or STATUS_3 means something to the developer who built it. It means nothing to the HR manager approving access certifications or the CIO signing off on compliance reports. When reviewers cannot understand the model, they cannot meaningfully participate in it.
The second failure here is timing. A common mistake is computing lifecycle state purely from employment status flags without accounting for the actual dates. An employee flagged as “terminated” in the HRIS on Friday afternoon should not have their account disabled immediately if they are still physically on-site until end-of-day. Equally, a new hire should not have an account created the moment they appear in the HRIS if their start date is four weeks away.
What to do:
Design lifecycle states to reflect business realities: active, preHire, activePendingTermination, terminated, inactive. Each state should be explainable in one sentence to a non-technical stakeholder. The naming convention should encode the business meaning, not the technical implementation.
For timing, compute states from dates, not flags. A date-based model handles edge cases — early exits, delayed start dates, overlapping contracts — that a flag-based model cannot. Define the transition windows explicitly: how many days before start date does preHire begin? How many days before end date does activePendingTermination start? Document these as business decisions, not technical choices.
4. Correlation Rules That Create Duplicate Identities
The correlation rule tells ISC how to match an account in a source to an existing identity. Get it wrong and ISC creates a new identity for every account it cannot match, producing a growing population of uncorrelated accounts that nobody owns and nobody reviews.
The most common mistake is correlating on attributes that are not stable or unique. Email addresses change when people get married or when the organization changes its naming convention. Display names have collisions and change over time. Department codes vary between systems. Using any of these as the primary correlation key is asking for eventual problems.
A related failure: the correlation attribute exists in both systems but is formatted differently. The HRIS sends employeeId as 00123456. Active Directory stores it as 123456. The correlation fails. Two identities exist for the same person.
What to do:
Correlate on a stable, unique business identifier — employee ID, typically — that is present in every source that represents a human identity. Validate that the format is consistent across sources before go-live. If it is not, normalize it with a Transform before correlation runs.
Run a correlation health check before go-live: launch a Source Owner campaign targeting uncorrelated accounts. If there are many, the correlation rule has problems. Resolving uncorrelated accounts after go-live is significantly more expensive than getting correlation right during Build.
5. Aggregation Schedules That Cause Operational Problems
Aggregation frequency is a calibration problem with two failure modes. Aggregate too rarely and the identity data in ISC is stale — a new employee arrives on Monday morning and their account does not exist yet. Aggregate too frequently and you may trigger throttling on the source system.
The throttling case is subtle. A cloud HRIS or directory service like Microsoft Entra ID has rate limits on its API. Two aggregations scheduled close together — or scheduled at peak load times — may succeed individually but trigger throttling that causes one to return an empty result set. ISC processes the empty result, interprets it as a tenant with no accounts, and may begin deprovisioning. This is a serious incident in production.
What to do:
For HRIS sources, two aggregations per day is usually sufficient — morning and afternoon, scheduled for off-peak hours. Avoid scheduling aggregations at times that coincide with HRIS batch processing windows; many HR systems run payroll and reporting jobs overnight or at month-end that make the API slow or unavailable.
For cloud directory sources, check the API documentation for rate limits and enable delta aggregation where supported. Delta aggregation fetches only changed records, dramatically reducing API load and reducing throttling risk.
Document the aggregation schedule as a business decision. The schedule determines how quickly identity changes propagate through the governance system. A Leaver event that takes 24 hours to propagate because of a poorly timed aggregation schedule is a compliance gap that will appear in audits.
The Common Thread
Each of these pitfalls is a consequence of the same underlying problem: treating HRIS integration as a technical task rather than a governance-critical system. The HR source is not a data feed. It is the foundation on which joiner, mover, and leaver processes run. When it is unreliable — whether from expired credentials, bad correlation, or silent aggregation failures — every downstream governance control is compromised.
The organizations that run clean SailPoint ISC deployments are not the ones that had more time or bigger budgets. They are the ones that treated HRIS integration as a risk item, validated it systematically during Build, and monitored it continuously after go-live.
That discipline is not complicated. It just requires knowing where to look.
TrustIn delivers SailPoint ISC implementations and identity governance programs for mid-market organizations. If you are scoping an ISC deployment or troubleshooting an existing one, get in touch.