SailPoint ISC Greenfield Implementation Field Guide

On this page

• How to use this guide
• The program in numbers
• Rules that would have saved us weeks
• Conventions used in this guide
• Related reading on this site

This guide is the document I wished existed on day one of a greenfield SailPoint Identity Security Cloud (ISC, formerly IdentityNow) program. It is written from a real enterprise rollout: a global professional-services firm with roughly 13,000 people, a legacy identity manager being retired, an HR system as the single authoritative source, and a plan to bring well over a hundred applications under governance in two phases.

It is not a tour of the product. SailPoint's own documentation does that. This guide covers what the documentation does not: the decisions you will be forced to make, the places the platform fails silently, the limits you only find by hitting them, and the workaround that finally worked.

How to use this guide

Read the Rules that would have saved us weeks below once, then jump to the page for whatever phase you are in. Every page ends in concrete actions, and the last pages collect checklists, a limits table and a symptom lookup so the guide works as a reference during build and support.

The program in numbers

All figures are rounded and the client is deliberately not named. They are here so you can calibrate the scale of what follows.

Rules that would have saved us weeks

These are the lessons that cost the most when we learned them late. Each is expanded on its own page.

1. The HR feed is the product. Every automation downstream is only as good as the authoritative data. Budget real time for data quality, mandatory-field enforcement and an HR change process before you build a single workflow.
2. Pick one immutable join key and never key on anything else. An employee ID that is never reused, even across rehires, is worth more than any clever correlation rule. Names, emails and login names all change.
3. Provisioning logic lives in rules, not in source configuration. On a Web Services or JDBC source the endpoint or SQL fields can be empty or dead while a connector rule does all the real work. Review and document rules as first-class deliverables.
4. The dangerous failures are the quiet ones. A status comparison that stops matching makes every account look enabled. A page-size ceiling silently drops accounts. A swallowed exception sends a request with blank fields. Design monitors for counts and freshness, not just for errors.
5. Set the delete threshold deliberately on every source, and verify it. It is the only thing between an empty API response and a mass account deletion.
6. Every source needs an aggregation schedule. Two production sources ran for months with none, so reviews and reports showed a stale view that nobody noticed.
7. Aggregate groups before accounts. Entitlement objects should exist before accounts reference them.
8. Lifecycle actions target an explicit list of sources. Adding a source later does not add it to your leaver disable action. Make "update the lifecycle state source list" a line in your onboarding checklist.
9. Forms cannot cascade the way you expect. Dependent dropdowns driven by a search over entitlement attributes do not work. Plan the request experience around this, not against it.
10. The workflow engine has sharp edges. Secrets can only be created in the UI, an unresolved template path renders as literal text, tier limits count loop bodies, and some approval actions are not licensed. Read the workflow limits before designing a flow.
11. Entitlement value formats are contracts. If a rule parses an identifier out of an entitlement name, changing that format detaches every grant. Treat it like a public API.
12. Never put credentials, or a debug webhook, in a production rule. Both ended up in ours. One makes provisioning fail whenever a diagnostic listener is down.
13. Revocation approval is a decision, not a default. Granting needed manager approval while revoking needed none, on thousands of profiles. Decide that on purpose.
14. Concentrated ownership becomes an outage. Thousands of access profiles owned by one person route every review and escalation through them. Use governance groups.
15. Automate campaign creation, then verify it. Hundreds of campaigns by hand is not credible. A script that creates them staged and compares them to the source data caught real discrepancies before launch.
16. Plan notifications and ITSM routing as carefully as provisioning. Most hypercare tickets were about who did or did not receive an email, not about accounts.
17. Switch attribute sync on a couple of attributes at a time. A staged switch-on with validation between steps is the cheapest rollback you will ever get.
18. Hand over with a documentation pack per integration. Five files per application (reference, tenant context, edge cases, runbook, config evidence) made knowledge transfer routine.

Conventions used in this guide

• Most pages end with a section titled "What SailPoint's documentation adds". Those sections were checked against SailPoint's public documentation and community in October 2026 and link to their sources.
• Observed means it happened on the program. Anything described as a platform limit was measured on a 2026 tenant. SailPoint changes ISC continuously, so re-check a limit before you design around it, especially anything tied to licensing or release level.
• Names of internal applications, hosts, accounts, people and identifiers are removed. Commercial products such as Sage People, OneStream, Enate, Dynamics 365 and BMC Helix are named where the integration pattern matters.
• Code samples are trimmed and generalised. They show the shape of a solution, not a drop-in implementation.
• Dates are expressed as durations. The shape of the timeline matters more than the calendar.

Related reading on this site

• SailPoint ISC vs IIQ for the product-level comparison.
• AI in IAM for where AI fits into an ISC implementation, including why cloud rules cannot call out to a model.