SailPoint architecture, end to end, in plain English
SailPoint is the same eleven layers whichever product you land on, from the tenant your login reaches down to the appliance sitting quietly inside your network. This page walks all eleven, follows a new starter from an HR record to their day-one access, and explains the four-step order that decides why your identities look the way they do. No prior identity governance experience assumed.
The whole platform in sixty seconds
SailPoint reads accounts out of the systems you already run, works out which human or machine each account belongs to, decides what access that identity should have, and then makes the answer true in the target system. Everything else on this page is detail hung off those four sentences. Once that clicks, the architecture stops feeling like a product tour and starts feeling like layers.
Two products, one set of ideas
Identity Security Cloud is multi-tenant SaaS that SailPoint operates. IdentityIQ runs on your own infrastructure. The words differ and the extensibility ceiling differs, but sources, accounts, entitlements and identities mean the same thing in both.
Seven objects explain most of it
Source, Account, Entitlement, Identity, Identity Profile, Access Profile and Role. Almost every confusing behaviour becomes obvious the moment you can say out loud which of those seven you are looking at and how it relates to the others.
The order is fixed
Identity attributes, then manager, then lifecycle state, then roles. Always that order, every time. Most identity problems that look mysterious are really a misunderstanding of that sequence, which is documented below in full.
Click any layer to jump straight into it
Five pictures that explain most of the platform
If you only take five things away from this page, take these. Each diagram is drawn to match how the platform really behaves, not how it is usually drawn in a sales deck, and each one is explained in words underneath so you are never guessing at what a box or an arrow means.
Where the tenant ends and your network begins
The single most useful picture in identity governance. Almost every security question you will be asked about SailPoint is answered by the direction of one arrow.
Scroll the diagram sideways, or tap Enlarge for a bigger view
What is actually running on the Virtual Appliance
People treat the appliance as a black box for years. It is four containers on a minimal Linux image, and knowing which is which turns most support tickets into five-minute diagnoses.
Scroll the diagram sideways, or tap Enlarge for a bigger view
charon looks after the appliance and its updates, ccg is the Cloud Connector Gateway that actually runs connectors and holds the authenticated sessions to your sources, va_agent carries command and control between the appliance and the tenant, and otel_agent ships telemetry out to whatever you already monitor with. You supply a virtual machine of roughly four vCPU, sixteen gigabytes of memory and a hundred and twenty-eight gigabytes of disk, allow outbound 443, 53 and 123, keep the clock on UTC, and stay off the reserved address ranges. The behaviour that catches teams out is the update: appliances patch themselves and reboot, and a rebooting appliance does no work. That, not peak load, is why the minimum is two per cluster.The eleven layers, in order
Identity data enters at the bottom of your estate and works its way up into decisions. Decisions travel back down and become account changes in real systems.
Scroll the diagram sideways, or tap Enlarge for a bigger view
From someone asking, to the access existing
An access request is not one step. It is a chain, and the chain has a branch at the end that decides whether your compliance evidence is worth anything.
Scroll the diagram sideways, or tap Enlarge for a bigger view
IdentityIQ and Identity Security Cloud, side by side
The same governance ideas, two very different operating models. This is the comparison that decides your architecture, your team shape and your budget.
Scroll the diagram sideways, or tap Enlarge for a bigger view
Where to start, depending on who you are
This page is long on purpose, because architecture is not something you can learn from a single diagram. You do not have to read it top to bottom. Pick the path that matches why you are here.
I am new to identity governance
Read the stack from the top and do not skip the data model. Almost every confusing behaviour in SailPoint becomes obvious once you can say out loud what a Source, an Account, an Entitlement and an Identity are and how they relate. Then walk the joiner trace twice, slowly.
- Read layer L2 The Identity Data Model until the seven objects are second nature
- Read L4 Aggregation and Identity Processing and memorise the four-step order
- Walk the joiner trace from HR record to day-one access
- Skim the glossary now and return to it after every section
I administer a tenant already
You know the console. What usually bites experienced administrators is the boundary between what runs in the tenant and what runs on the appliance, and the exact order in which identity processing evaluates things. Both explain most of the incidents you have already had.
- Read L3 Connectivity and the Virtual Appliance including the port and hostname detail
- Read the identity processing order section and compare it to what you assumed
- Read L8 Extensibility and place every customisation you own on the transform-to-rule ladder
- Read the mistakes section and be honest about which two you are currently living with
I come from IdentityIQ
Your mental model mostly transfers, but the words changed and the extensibility ceiling moved. Translate the vocabulary first, then find out where your habits no longer apply: there is no application server you control, no arbitrary Java, and no upgrade you schedule.
- Read the object translation in L2 and the IIQ notes throughout the stack
- Read L8 Extensibility and note what BeanShell and plugins become
- Read L10 Operations and Migration for how a migration programme is actually shaped
- Read the IIQ versus ISC decision card and write down your own one-sentence answer
I am designing a deployment
Start at the edges: tenancy and region, then the appliance topology, then the security model. Those three decisions constrain everything else and are the expensive ones to revisit later.
- Read L0 Deployment and Tenancy and settle region, tenant naming and sandbox strategy
- Read L3 and size the clusters against your network boundaries, not your org chart
- Read L7 Security and Access Control and decide the authentication and API credential model
- Read L9 The Wider Portfolio so today's design does not block next year's capability
I own compliance or audit
You care about evidence and about the gap between a decision and its effect. Read the governance layer, then the parts of the operational layer that determine whether the evidence is trustworthy.
- Read L6 Governance and Compliance including campaign types and reviewer decisions
- Read the revocation-completion versus certification-completion distinction twice
- Read L5 for how a revocation actually reaches a target system, and where it can stall
- Read the mistakes on campaign scope and on treating a campaign as done
All eleven layers, one at a time
Each layer answers four questions: what it actually is, what lives inside it, how it connects to the layers above and below, and what usually goes wrong. The plain-English analogy at the top of each layer is there for anyone new to identity governance. Everything below the analogy is the real detail, including the IdentityIQ equivalent wherever the two products diverge.
Deployment & Tenancy
Where SailPoint actually runs, and who runs it
There are three deployment realities you have to keep straight, because almost every architecture argument in a SailPoint project comes from mixing them up. Identity Security Cloud, formerly IdentityNow and now positioned as SailPoint Human Fabric, is multi-tenant SaaS built on the SailPoint Atlas platform and hosted in AWS regions. IdentityIQ is a Java web application you install on your own application server against your own database, in your own data centre or your own cloud account. The Virtual Appliance is a hardened Linux image you deploy inside your network that gives the cloud tenant a way to reach on-premises systems without you opening a single inbound firewall port. A real enterprise often runs two of the three at once during a migration, which is why the boundary lines matter so much.
Tenant | The ISC unit of isolation. One tenant per organisation, addressed by name and region, with its own data, configuration and API credentials. |
Org | The older ISC term for the same thing, still visible in some API responses and in older documentation. |
VA cluster | A named grouping of virtual appliances. Sources are assigned to a cluster; the cluster decides which VA picks up the work. |
identityiq database schema | Around 300 tables in IdentityIQ, most of them prefixed spt_, for example spt_identity, spt_link, spt_managed_attribute, spt_bundle. |
Region | The AWS region that hosts your tenant. It determines your data residency and the exact set of AWS endpoints your VAs must be allowed to reach. |
Multi-tenant, and what that costs you
Identity Security Cloud is genuinely multi-tenant. Your tenant shares infrastructure with other customers, isolated at the data and identity layer rather than by giving you your own database process. The upside is that you never patch it, never size it, and get new capability continuously. The downside is the one that surprises teams coming from IdentityIQ: you do not control the release, you cannot install arbitrary code into the platform, and you cannot run a long-running custom Java process inside it. Every piece of custom logic has to fit into one of the sanctioned extension points, which is exactly why transforms, cloud rules, connector rules and workflows exist as separate concepts with different privileges.
The regions list is not decoration
SailPoint documents the supported AWS regions for ISC explicitly: us-east-1, us-west-2, us-gov-west-1, ap-south-1, ap-southeast-1, ap-southeast-2, ap-northeast-1, ca-central-1, eu-central-1, eu-west-2, me-central-1 and sa-east-1. Your region determines the S3, SQS, DynamoDB, ECR and Firehose endpoints your virtual appliances must reach outbound, and every one of those regional hostnames has a us-east-1 counterpart that must also be allowed, because some platform control-plane traffic still terminates there. Network teams that allow only the local region get an appliance that registers and then silently fails to pull its container images.
IdentityIQ is not deprecated, but the clock is real
IdentityIQ 8.5 went generally available in July 2025 and is a substantial release: Microsoft Teams approvals, generative-AI entitlement descriptions, self-service entitlement recommendations, protection for sensitive identity attributes, and the long-running move of the user interface from AngularJS to Angular 18. It is supported, it is being invested in, and for organisations with hard data-residency or deep-customisation requirements it remains the right answer. But the strategic centre of gravity has moved: the Atlas platform, the Identity Graph, machine and AI agent identity, and everything announced through 2025 and 2026 lands on the cloud platform first. Plan the migration on your timeline rather than on a vendor deadline, but plan it.
The hybrid reality nobody puts on the slide
Most large SailPoint estates are not one architecture. They are Identity Security Cloud governing the SaaS and cloud-directory estate, IdentityIQ still governing a mainframe and a set of custom legacy applications, a virtual appliance cluster bridging the two worlds, and a period of dual-running where an identity exists in both systems. The architectural discipline that saves these programmes is deciding, per application, which system is authoritative for provisioning, and never letting both write to the same account. Two governance systems both convinced they own an Active Directory group is one of the most expensive failure modes in the field.
What SailPoint operates versus what you operate
For Identity Security Cloud, SailPoint operates the platform, the databases, the search index, the workflow engine, the API gateway and the release process. You operate the virtual appliances, the network path from those appliances to your systems, the service accounts the connectors use, and every piece of configuration and extension logic. That last list is longer than it looks. An outage caused by an expired service-account password on a source is your outage, and the platform will surface it as an aggregation failure rather than as an obvious credential error.
- Assuming Identity Security Cloud can be deployed into your own cloud account. It cannot. It is multi-tenant SaaS, and the only SailPoint software inside your network is the Virtual Appliance.
- Treating the sandbox tenant as optional. Identity profiles, transforms and lifecycle states change behaviour for the entire population the moment they are saved, and there is no undo.
- Choosing a region late. Region affects latency to your sources, data residency commitments and which hostnames your firewall must allow, and it is not something you casually change afterwards.
- Running IdentityIQ and Identity Security Cloud against the same targets during a migration without deciding which one owns provisioning. Two systems both convinced they are authoritative will fight, and the target system will lose.
- Forgetting that the FedRAMP environment is a separate environment with its own hostnames, not a configuration flag on the commercial one.
The Atlas Platform
The shared services every SailPoint capability is built on
SailPoint announced Atlas as its identity security platform to consolidate what had been separate products with separate data models. Six common services make up the platform. The data model holds all identity information and the context needed to manage and automate access. Connectivity is the connector library that consolidates access and identity information from applications and resources into that single model. Machine learning provides the model library behind recommendations, outlier detection and role discovery. Extensibility is the framework that lets customers thread identity into the rest of their security ecosystem. Event-driven orchestration runs custom workflows and forms when things change. Personalised insights and reporting put the relevant subset of identity data in front of administrators, managers and end users. On top of those six, SailPoint has layered the Identity Graph and the Access Intelligence Center.
Identity | The person or non-person the platform governs. Correlated from one or more accounts, with attributes computed by an identity profile. |
Account | One login on one source. Held as a child of both the source and the identity it correlates to. |
Entitlement | One unit of privilege on one source: a group, a role, a permission, a licence. |
Event | An immutable record of something that happened, indexed for search and available to triggers and to Access History. |
Workflow | A definition of what to do when a trigger fires, expressed as a sequence of steps with operators and conditions. |
One data model is the whole argument
Before Atlas, an organisation running SailPoint governance, SailPoint file access security and a non-employee lifecycle tool had three data models, three connector inventories and three sets of identity correlation logic. The strategic bet of Atlas is that all of those become views over one model. That is why Data Access Security can tell you that a specific human identity, not a specific Windows SID, has effective read access to a folder of regulated data, and why Machine Identity Security can attach a human owner to a service account. If you take one design principle away from this layer, it is this: onboard the identity once, and everything else composes.
The Identity Graph, and why a graph and not a table
Access in a real enterprise is not a list, it is a path. A person is in a group, that group is nested inside another group, that group grants a role in an application, that role carries an entitlement that reaches a set of data. A relational answer to 'who can read this?' means an unbounded number of joins. A graph answers it as a traversal. That is the capability behind the questions the platform can now ask that it could not before: where did privilege creep in, which access paths converge on sensitive data, and what changed between two points in time.
Event-driven, not schedule-driven
The older generation of identity governance was fundamentally batch: aggregate overnight, refresh identities, run a certification once a quarter. The event-driven orchestration service is the platform's answer to that, and it changes the design conversation. Instead of 'the nightly job will pick it up', you design for 'the identity attributes changed event fires, the trigger evaluates, the workflow runs'. Schedules still exist and still matter, but treating them as the primary mechanism is now an anti-pattern. It is also the architectural precondition for the continuous, real-time governance SailPoint markets as Human Fabric.
Extensibility is deliberately narrow
Atlas gives you transforms, rules, workflows, forms, triggers and a comprehensive REST API. It does not give you a place to deploy arbitrary code that runs in the platform's own process with the platform's own privileges. That is not an oversight. In a multi-tenant system, one customer's runaway loop cannot be allowed to affect another customer's tenant. The practical consequence is a design rule worth writing on the wall: if your solution needs code that cannot be expressed as a transform, a rule, a workflow or an external service called over the API, the design is probably wrong for the platform rather than the platform being wrong for the design.
- Treating each capability as a separate product with its own integrations. The entire argument for the platform is that a source onboarded once serves whichever capability you switch on later.
- Expecting the machine learning to be an oracle. It surfaces outliers and recommendations from your own data, which means bad role hygiene produces confident, useless suggestions.
- Ignoring the search surface. Most investigations that people run as exports could be answered in seconds by a query, and the same query is what scopes a campaign correctly.
- Assuming a capability shown in a demo is enabled in your tenant. Entitlement to a capability and activation of a capability are different things, and the difference is a commercial one.
The Identity Data Model
The seven objects that explain almost everything
Everything in SailPoint reduces to a small number of objects with well-defined relationships. A source is a connected system. Aggregating a source produces accounts and entitlements. Correlation attaches accounts to identities. An identity profile designates a source as authoritative and defines how raw account attributes become identity attributes. Access profiles bundle entitlements from a single source into something a human can request. Roles bundle access profiles, usually across several sources, into something a business can reason about. Certifications, policies, requests and provisioning all operate over exactly these objects. IdentityIQ has the same shape with different names: Application, Link, ManagedAttribute, Identity Cube and Bundle.
Identity (ISC) / spt_identity (IIQ) | The identity record. In IIQ this is the Identity Cube, holding attributes, links, role assignments, entitlements, risk scores and policy violations. |
Account (ISC) / spt_link (IIQ) | The account. IIQ calls it a Link, which is the more honest name: it links an identity to an application account. |
Entitlement (ISC) / spt_managed_attribute (IIQ) | The entitlement. IIQ calls it a ManagedAttribute, which reflects that it is one value of one managed attribute on one application. |
Access Profile / Role (ISC) / spt_bundle (IIQ) | IIQ stores both business roles and IT roles in spt_bundle, distinguished by their role type. |
Source (ISC) / spt_application (IIQ) | The connected system definition, including connector attributes and schema. |
The hierarchy that matters: entitlement, access profile, role
These three exist at different levels of abstraction on purpose. An entitlement is a technical fact on one system, meaningful only to someone who knows that system. An access profile groups entitlements from one source into something an application owner recognises, for example 'Salesforce sales representative' as a package of a profile, two permission sets and a licence. A role groups access profiles across sources into something the business recognises, for example 'Branch teller' as a package of Active Directory groups, a core banking access profile and a Salesforce access profile. A design that skips the middle layer and lets people request raw entitlements produces a request catalogue nobody can govern. A design that puts everything into roles produces role explosion. The discipline is to model at the level the reviewer of that access can actually judge.
Correlation is the join that everything depends on
Correlation is the rule that decides an account on a source belongs to a particular identity. It is configured per source as a set of attribute comparisons, for example the source's employeeNumber equals the identity's employeeId. When correlation succeeds, the account appears on the identity and its entitlements become that person's access. When it fails, the account becomes uncorrelated: visible, aggregated, but attached to nobody. Uncorrelated accounts are the single largest source of embarrassment in an identity programme, because they are exactly the orphan accounts an auditor asks about. A healthy deployment measures uncorrelated account count as an operational metric, not as a one-off cleanup.
Identity profile priority, and why the lowest number wins
An organisation usually has more than one authoritative source: an HR system for employees, a contractor register for non-employees, sometimes a separate system for a subsidiary. Each gets an identity profile, and each identity profile has a priority. When a person appears in more than one authoritative source, the identity profile with the highest priority, meaning the lowest priority number, wins and determines the identity's attributes. Getting this backwards produces the classic failure where a contractor record overwrites an employee's job title, or where a terminated employee who still exists in a secondary system never leaves the active population.
The identity is computed, not stored by hand
This is the mental model shift that trips up people coming from a directory. In a directory, you edit a user's department. In SailPoint, the department is a computed value: it comes from an authoritative account attribute, possibly passed through a transform, applied by the identity profile during identity processing. If you want the department to change, you change it in the authoritative source, or you change the mapping. Editing it on the identity is either not possible or will be overwritten on the next processing cycle. Every 'my change did not stick' ticket in a SailPoint deployment is this principle asserting itself.
Birthright, requestable, and the space in between
Access arrives at an identity through three doors, and a good design is explicit about which door each item uses. Birthright access is assigned automatically by role membership criteria on identity attributes, granted the moment a person matches. Requestable access is chosen by a human in the request centre and passes through approval. Manually assigned access is granted directly by an administrator, which is the door that should be narrowest and most heavily logged. The most common design failure is birthright roles whose criteria are so broad that everyone qualifies, which produces an access model that looks governed and grants everything to everyone.
IdentityIQ names the same things differently
If you move between the two products, keep a translation table. IIQ's Application is ISC's Source. IIQ's Link is ISC's Account. IIQ's ManagedAttribute is ISC's Entitlement. IIQ's Identity Cube is ISC's Identity, and the word 'cube' is a reminder that it is a multi-dimensional view assembled from many systems rather than a row in a table. IIQ's Bundle covers both business roles and IT roles, where ISC splits the same idea into Role and Access Profile. The concepts survive the migration; the names and the configuration surfaces do not.
- Confusing an entitlement with an access profile. The entitlement is what the target system enforces; the access profile is a bundle you invented so humans can request it sensibly.
- Building roles that contain exactly one access profile from exactly one source. That is a brick wearing a wall's name badge, and it doubles your model for no governance benefit.
- Letting an identity be correlated by two identity profiles without understanding priority. The lowest priority number wins, and the losing profile's mappings quietly stop applying.
- Granting access directly rather than through the model. Direct grants are invisible to role reasoning, survive job changes and turn every certification into archaeology.
- Assuming IdentityIQ terms map one to one. A Bundle does not become a Role; its responsibilities split across roles and access profiles, and pretending otherwise produces a bad model on day one.
Connectivity & the Virtual Appliance
How a cloud service reaches a system behind your firewall
A source needs a runtime that can physically reach the system it governs. If the system is on the public internet with a REST API, SaaS Connectivity runs the connector inside the SailPoint platform and no appliance is needed. If the system is a domain controller, a database, a mainframe or an internal application, the connector has to run inside your network, and that is the Virtual Appliance. The VA is a hardened Flatcar Linux image running SailPoint's connector containers. It registers itself to your tenant, then polls outbound over TLS for work. It never accepts an inbound connection from SailPoint. SailPoint's own documentation is unambiguous: all communications are initiated as outbound only, and no incoming communications from outside your network are requested or required.
Minimum VA sizing | 4 vCPU, 16 GB RAM, 128 GB disk, on a CPU of at least Intel Nehalem or AMD Opteron Generation 4. Cloud equivalents: AWS M5.xlarge, Azure Standard_D8s_v5, GCP n2-standard-4. |
Cluster add-ons | Each additional collector adds resource: Privileged Access Gateway plus 2 vCPU and 4 GB; each Data Access Security collector, whether Resource, Permission, Data Classification or Activity Monitor, plus 2 vCPU and 8 GB. |
Required outbound ports | DNS on 53, NTP on 123 unless you use a local time source, and HTTPS on 443. SSH on 22 inbound is for internal administration only. |
Reserved ranges | 10.255.255.241/28 is reserved, and 172.16.0.0/22 is reserved in network tunnel configurations. Traffic on these will not route correctly. |
Time zone | Virtual appliances run in UTC and this is not configurable. Schedule interpretation and log correlation must account for it. |
Outbound only, and the hostname list you must actually allow
The appliance needs egress on 443 to a specific set of hosts. The constants across all regions are *.flatcar-linux.net and *.flatcar-linux.org for operating system security patches, *.identitynow.com, *.api.identitynow.com and *.sailpoint.com for platform traffic, *.secure-api.infra.identitynow.com and va-access.infra.identitynow.com for the control channel, and *.launchdarkly.com for feature flag delivery. On top of those, a regional set of AWS endpoints is required, and each has a us-east-1 twin that must also be allowed: S3 as *.s3.<region>.amazonaws.com, SQS as sqs.<region>.amazonaws.com, DynamoDB as dynamodb.<region>.amazonaws.com, and the container registry as 874540850173.dkr.ecr.<region>.amazonaws.com. FedRAMP tenants use *.sailpointfedramp.com equivalents instead. A proxy that inspects TLS and cannot be configured with these will produce an appliance that registers and then does nothing, which is the most common day-one failure in the field.
Three network configurations, and when each is right
SailPoint supports three ways to get the appliance out to the internet. Standard configuration is direct outbound HTTPS, which is the simplest and the one to choose if your network allows it. HTTP proxy configuration routes the appliance's traffic through your existing forward proxy, with the caveat that TLS interception must be handled correctly or certificate validation fails. Network tunnel configuration establishes an encrypted tunnel to a fixed set of SailPoint endpoints, used when the security posture requires a known, narrow set of destination IP addresses rather than wildcard hostnames. The tunnel endpoints are published per region, for example the three US East addresses 52.206.133.183, 52.206.132.240 and 52.206.130.59. Choose the tunnel only if you need it; it adds an operational dependency the other two do not have.
Two per cluster is not a suggestion
SailPoint's guidance is to deploy at least two virtual appliances per cluster, and at least one production cluster and one sandbox cluster, so that connectivity survives an update. Sandbox clusters also need two. The reason is mechanical rather than theoretical: appliances update themselves, and an updating appliance is briefly unavailable. With one appliance, an update window is an outage window. The additional guidance is a 1:1 ratio of appliances to virtual machines, distributed across separate physical hosts or separate availability zones, so that a single hypervisor or a single AZ failure does not take out the whole cluster. The single documented exception is IdentityIQ AI implementations, which require only one appliance for connectivity.
The appliance is deliberately not yours to modify
You do not get root. You do not add users. You do not modify the trust store. Flatcar updates soak in a SailPoint sandbox for a week before release, and then the appliance takes them. You cannot migrate an appliance between deployment methods, so a VA deployed as a vSphere OVA cannot become an AWS AMI; you deploy a new one and retire the old one. Teams used to owning every box in the estate find this uncomfortable, and the argument that wins the security review is the right one: an appliance nobody can log into and modify is an appliance whose behaviour is knowable, and its outbound-only posture means it adds no inbound attack surface at all.
Choosing between SaaS Connectivity and a VA connector
SaaS Connectivity moves the connector into the platform and removes the appliance from the path entirely, which removes an operational dependency and a latency hop. It uses the same asymmetric key pair scheme for credential protection, with the key pair held in the cloud rather than on the appliance. The hard constraint is reachability: a SaaS connector cannot see anything that is intranet-only, which excludes JDBC and mainframe applications outright. The rule of thumb is simple. If the target is an internet-reachable SaaS API and a SaaS connector exists for it, use it. If the target is inside your network, or the connector only exists in the VA-hosted form, use the appliance. Do not build a reverse proxy to expose an internal system to the internet purely to avoid deploying an appliance; that trade is a bad one.
Sizing is driven by concurrency, not by identity count
The instinct is to size the appliance by how many identities you have. That is the wrong variable. What consumes appliance resource is concurrent connector work: how many sources aggregate at the same time, how large each aggregation payload is, and how much provisioning traffic runs in parallel. A tenant with 200,000 identities across five sources on a staggered schedule can be comfortable on the minimum specification. A tenant with 20,000 identities across sixty sources that all aggregate at 02:00 will not be. The cheapest performance fix in most deployments is not a bigger appliance, it is a staggered aggregation schedule.
- Running a single appliance. Updates reboot appliances, and a rebooting appliance does no work. Two per cluster is a minimum, not a recommendation.
- Creating a cluster per team or per application owner. Clusters should follow network boundaries; every extra cluster is two more appliances to patch and monitor for no functional gain.
- Undersizing the virtual machine and then blaming the connector when aggregation is slow.
- Missing a hostname in the outbound allowlist and then debugging it as a connector problem for two days. Allow the full documented list, not the one host you saw in a log.
- Letting the appliance clock drift or setting it to local time. It must be UTC, and time problems present as authentication failures rather than as time problems.
- Colliding with the reserved internal address ranges the appliance uses, which produces intermittent failures that look like network flakiness.
Aggregation & Identity Processing
How raw system data becomes a governed identity
Aggregation is a read. It connects to a source, pulls the accounts and entitlements, and updates the data model. It does not by itself decide anything about a person. Identity processing is the decision engine that runs afterwards. Identity Security Cloud triggers it four ways. Event-based processing fires immediately when an aggregation or a provisioning operation modifies an identity. Scheduled processing runs twice a day, at 08:00 and 20:00 in the tenant time zone, covering attribute synchronisation in the morning and the fuller role and periodic refresh pass in the evening. Time-based processing uses the nextProcessing identity attribute, mapped to an ISO 8601 date from account data such as a hire date or a termination date, to schedule an exact refresh moment. Manual processing happens when an administrator selects Apply Changes after editing an identity profile, a role or an access profile.
nextProcessing | The identity attribute that schedules a future processing run. Must be a valid ISO 8601 timestamp. The mechanism behind day-one and day-of-termination automation. |
Identity state | Active, Inactive short-term, or Inactive long-term. Determines whether the identity appears in pick lists, in manager team views and in scheduled processing. |
Lifecycle state | A customer-defined state such as prehire, active, leave of absence, or terminated, which drives access grants and revocations and can set the identity state. |
Aggregation schedule | Per-source cron-like schedule. Staggering these is the single most effective performance control available to an administrator. |
Identity processing | The current SailPoint term. The older term identity refresh is still in wide use in the field and in IdentityIQ, where it is a scheduled task. |
The processing sequence, in order
When identity processing runs for an identity, it performs four things in sequence: it updates identity attributes according to the identity profile mappings, it determines the correct manager through manager correlation, it updates access based on the assigned lifecycle state, and it recalculates role assignments and adjusts access accordingly. That order is the answer to a large class of bugs. A role whose criteria depend on the department attribute cannot evaluate correctly until the department attribute has been computed, which is why attributes come first. A lifecycle state that grants access cannot be applied before the identity knows which state it is in. If your role is not assigning, check whether the attribute it depends on is actually populated at the moment the role evaluates.
Aggregation does not equal processing
This is the distinction that separates people who can debug SailPoint from people who cannot. A successful aggregation means the platform now knows the current state of accounts on that source. It does not mean any identity has been updated, any role recalculated or any access provisioned. Those are identity processing outcomes. When someone says 'I ran the aggregation and nothing happened', the useful next question is whether identity processing ran, whether it ran for the identities in question, and whether the identity profile actually maps the attribute they expected to change.
Delta versus full aggregation
A full aggregation reads every account on the source. A delta aggregation reads only what changed since the last run, using whatever change-tracking mechanism the source supports, for example the Active Directory uSNChanged watermark or a modified-since filter on a REST API. Delta is dramatically faster and is the right default for a large source on a frequent schedule. It has two failure modes worth designing around. First, a delta run will not notice an account that was deleted in a way the source does not report as a change, so schedule a periodic full aggregation to reconcile. Second, if the watermark is lost or the source is rebuilt, the next delta may return everything or nothing, which is exactly what the deletion threshold exists to catch.
The deletion threshold has saved more programmes than any other setting
A source export truncates. A database view breaks. A service account loses read permission on an organisational unit. In each case the connector returns a small fraction of the accounts it returned yesterday, and without a guard the platform concludes that thousands of accounts were deleted and begins revoking. The deletion threshold aborts the aggregation instead and raises an error. Set it deliberately on every source, keep it tight on authoritative sources, and treat a threshold breach as an incident to investigate rather than a setting to raise.
Time-based processing is how joiners and leavers actually work
The elegant pattern for day-one access is not a schedule that runs every hour hoping to catch a start date. It is mapping nextProcessing to the hire date so that the platform wakes that identity up at exactly the right moment, moves it into the active lifecycle state, and provisions birthright access. The same mechanism handles termination: map nextProcessing to the termination date and the identity moves to the terminated state and loses access on the day, not on the next nightly run. The attribute must be a valid ISO 8601 timestamp, which usually means a transform sits between the raw HR date format and the identity attribute.
Identity state and lifecycle state are not the same thing
Lifecycle state is yours: you define the states, you define the access each grants, and you decide how an identity moves between them. Identity state is the platform's, and there are three: Active, Inactive short-term and Inactive long-term. A lifecycle state can set an identity state, which is the bridge between the two. The distinction matters operationally. Active identities appear in request centre pick lists and manager team views. Inactive long-term identities are excluded from scheduled processing and from automatic Apply Changes, though all three states can still be processed manually for selected identities. A leaver design that sets a lifecycle state but never moves the identity state leaves terminated people appearing in every approver picker in the tenant.
IdentityIQ does the same thing with different levers
In IdentityIQ the equivalent of aggregation is the Account Aggregation task, and the equivalent of identity processing is the Identity Refresh task, with a set of checkboxes controlling exactly which parts run: refresh identity attributes, refresh manager status, refresh assigned roles, refresh entitlement correlation, promote managed attributes, refresh risk scores, process events. The granularity is a genuine advantage and a genuine hazard. You can run a very cheap targeted refresh, and you can also spend a week debugging a refresh that never had the one checkbox ticked that would have made it do what you wanted.
- Expecting a configuration change to rewrite existing identities. It does not. Nothing changes until processing runs on an event, on the scheduled cycles, at a set next-processing time, or because you applied changes by hand.
- Writing a transform that reads a role. Roles are evaluated last, so the transform will always read the previous run's value, and the bug will look intermittent because sometimes the previous value is right.
- Bulk-loading identities in an order where reports are processed before their managers, then wondering why the manager field is empty.
- Setting the deletion threshold out of the way because it keeps blocking a run. It is blocking the run because something is wrong with the read, and the alternative to blocking is deprovisioning the company.
- Confusing identity state with lifecycle state. One is the platform's own status, the other is your business definition, and only the second should be driving access.
- Leaving the uncorrelated account queue to grow. Every account in it is access nobody owns and no certification will ever cover.
Access Request & Provisioning
From a request to a real change on a real system
Access reaches an account through three routes. Automatic assignment happens when an identity matches a role's criteria during identity processing. Access request happens when a person selects an item in the request centre, an approval chain completes, and provisioning follows. Direct assignment happens when an administrator grants access explicitly. In all three cases the outcome is a provisioning operation: the platform computes the difference between the access the identity should have and the access it does have, produces a plan, and dispatches each part of that plan to the connector for the relevant source. IdentityIQ formalises this with named components: the provisioning plan, the Provisioning Broker that compiles and partitions it, the partitioned plans that each target a single application, and the handlers, either an integration connector writing directly to the destination or a Work Item routing a manual task to a human.
Access request | The requester, the requestee, the requested items, the justification, the approval history and the resulting provisioning outcome. |
Approval | One decision by one approver or governance group, with a decision, a comment and a timestamp. Reassignment and escalation are recorded here. |
Provisioning transaction | One attempted operation on one account on one source, with its status. The first place to look when access was approved but did not appear. |
Account activity | The ISC view of what happened to an account and why, joining the request, the approval and the provisioning outcome. |
Zero Standing Privilege (ZSP) | The end state JIT-P moves towards: no permanent administrative entitlement exists to be stolen, because it is created on demand and destroyed after use. |
Partitioning is why partial failure is normal
A single request for a business role can touch five systems. The plan is partitioned so each system gets its own operation, executed independently. If Active Directory succeeds and the mainframe connector times out, you do not get a rollback; you get four successes and one failure, and the failure is retried or surfaced as an error. This is the correct behaviour for identity, because the alternative, an all-or-nothing distributed transaction across five systems that do not support one, is not achievable. It does mean your operational process has to include a way of finding and finishing partially provisioned requests, and that the request status a user sees must not claim completion until every partition has reported.
Approvals are not security, they are accountability
An approval chain does not prevent inappropriate access; it records who accepted responsibility for it. This distinction is worth being blunt about in design reviews, because it changes what a good approval scheme looks like. Long chains of approvers who cannot meaningfully evaluate the request produce rubber-stamping, which is worse than no approval because it manufactures false assurance. A short chain of people who actually understand the access, backed by preventive controls such as separation of duties policy evaluated before the approval is even offered, produces better outcomes than five levels of signature.
The account create profile is where identity meets reality
When SailPoint creates a new account on a source, something has to decide the username, the display name, the mailbox settings, the initial password and every other required attribute. That is the account create profile, and it is per source because every system has different rules. It is also where the messiest logic in most deployments lives: uniqueness handling for usernames, character transliteration for names the target system will not accept, and the fallback rules for people whose HR record is incomplete. Design it as a first-class artefact with its own tests, not as an afterthought discovered during user acceptance testing.
Manual work items are a legitimate architecture, not a failure
Some systems have no API, no connector and no realistic path to one. Governing them by generating a manual work item, with the exact change specified and the completion tracked, is dramatically better than leaving them ungoverned. The access is still requested, still approved, still certified and still revoked on termination; only the execution is human. The failure mode to design against is the work item that is marked complete without the change being made, which is why the better implementations pair manual provisioning with a read-only aggregation of that system so the platform can verify.
Just-in-time provisioning and the move to zero standing privilege
The August 2026 Human Fabric positioning made just-in-time provisioning a headline capability, and the reasoning behind it is worth understanding rather than just repeating. A standing administrative entitlement is an asset an attacker can steal at any time, and its risk is proportional to how long it exists rather than to how often it is used. JIT-P inverts the model: the entitlement is created when the need is proven, scoped to the task, and removed when the task ends. Zero standing privilege is the limit of that idea, where no permanent administrative grant exists at all. The architectural prerequisite is a governance system that can provision and deprovision fast and reliably enough that people will accept working that way, which is why this capability arrived after the event-driven orchestration layer rather than before it.
Revocation is harder than granting and gets a tenth of the attention
Granting access is a happy path with a motivated requester who will chase it. Revocation has no advocate. Nobody follows up on a removal that silently failed. This asymmetry is why leaver processes decay, and the countermeasures are structural rather than procedural: make revocation failures raise the same alerts as provisioning failures, reconcile actual account state against expected access on a schedule rather than trusting the transaction log, and measure time-to-revoke as a service level rather than as a report nobody reads.
- Publishing everything to the Request Center. A catalogue nobody can navigate produces requests for the wrong thing, approved by people who assumed somebody else checked.
- Designing approval chains around individuals rather than governance groups, so the process stops the week someone takes leave.
- Treating the manual work item queue as an edge case. It is where revocations go to die, and it needs an owner, an SLA and a report.
- Building an account create profile that produces non-unique or non-conforming values, then discovering it only when the target rejects the tenth account.
- Assuming revocation is the mirror image of provisioning. It is not: granting is forgiving of latency and removing is not, and targets often support creation more completely than deletion.
Governance & Compliance
Certifications, separation of duties, policy and audit
Governance is what distinguishes identity governance and administration from plain provisioning. Certification campaigns present a reviewer with a scope of access and require a decision on each item, and revocations flow back into provisioning automatically. Separation of duties policies define pairs or sets of access that must not be held by the same person, and are evaluated both preventively during a request and detectively across the population. Access history and the event stream provide the record that an auditor needs: not just what access exists now, but what existed at any point in time and how it changed. In IdentityIQ this is the Compliance Manager; in Identity Security Cloud it is the certification and policy configuration plus Access History and the Access Intelligence Center.
Campaign | The container: scope, reviewers, schedule, deadline, escalation and remediation behaviour. |
Certification item | One access item for one identity awaiting one decision. Campaign size is measured in these, and it is the number that determines whether reviewers will engage. |
Policy | The rule definition. Separation of duties, account policy or a custom policy expressed over identity attributes and access. |
Violation | One instance of one policy breached by one identity, with its detection time and its remediation state. |
Attestation | The record that a named human confirmed, on a named date, that named access was appropriate. This is the artefact the auditor is actually asking for. |
Campaign size is the entire game
The mathematics of certification are unforgiving. A manager with eight direct reports, each holding sixty entitlements, receives 480 decisions. Nobody makes 480 considered decisions, so they use the select-all button, and the campaign produces an attestation with no informational content. Every good certification design is an exercise in reducing the number of decisions to a number a human will actually think about: certify roles and access profiles rather than raw entitlements, exclude birthright access that is deterministic from an attribute anyway, use targeted campaigns aimed at privileged or unusual access rather than certifying everything on the same cycle, and put recommendation signals next to each item so the reviewer's attention goes where it matters.
Preventive and detective separation of duties are different controls
Preventive SoD is evaluated when access is requested, and it either blocks the request or forces an exception approval with a recorded justification. Detective SoD scans the existing population and reports violations that already exist. You need both, and they answer different questions. Preventive stops the problem being created but only covers access that flows through the request path, which means direct grants, birthright roles and changes made natively in the target system can still create violations. Detective catches those but only after the fact. A programme that implements only preventive controls and then discovers three thousand pre-existing violations on its first detective scan is the normal experience, not an unusual one.
Revocation is the part of certification that fails quietly
A reviewer clicks revoke. The item is marked revoked in the campaign. The campaign closes with a clean completion rate. Six months later an auditor finds the person still has the entitlement. What happened is that the revocation generated a provisioning operation which failed, or which went to a manual work item nobody completed, or which targeted a source where SailPoint has read-only access. Certification completion and revocation completion are different metrics and must be reported separately. If your campaign reporting shows only the first, it is telling you about clicks rather than about access.
Access History answers the question investigations actually ask
Current-state reporting tells you who has access today. An incident investigation, a legal hold or a regulatory enquiry asks a different question: who had this access on the fourteenth of March, and who granted it. That requires a time-series record of access rather than a snapshot, and it is why Access History exists as a distinct capability rather than as a report over the current model. When you are designing retention and data residency, this is the dataset with the longest legitimate retention requirement and the one most likely to be subject to a regulator's expectations.
Machine learning belongs in the reviewer's field of view, not in the decision
The recommendation and outlier capabilities in the platform are genuinely useful, and the useful framing is that they direct attention rather than make decisions. A signal that says 'only two of the 340 people in this job family hold this entitlement' is exactly the prompt a reviewer needs to actually look. A system that auto-approves everything the model considers normal and only surfaces anomalies has quietly delegated the control to the model, which is a defensible design in some risk contexts and an indefensible one in others. Decide which you are doing deliberately, and be able to explain it to an auditor.
- Launching a campaign that covers everything. Volume produces approval fatigue, approval fatigue produces bulk approve, and bulk approve produces evidence that is worse than none.
- Certifying roles before the role model is trusted. You are then certifying a label, not the access behind it.
- Reporting the campaign as complete when the reviews are complete. Certification completion and revocation completion are different metrics and the gap between them is the audit finding.
- Relying only on detective separation of duties. A preventive policy that blocks the request is always cheaper than finding the violation three months later.
- Choosing reviewers who cannot possibly evaluate the access. A manager asked about a technical entitlement will approve it, and you have manufactured a signature rather than a control.
Security & Access Control
Who can log into SailPoint, and what they can do once inside
There are four distinct security questions at this layer and it is worth keeping them apart. How does a human authenticate to the tenant, which is single sign-on, multi-factor authentication and the strong authentication rules for sensitive actions. How does a machine authenticate to the API, which is personal access tokens and OAuth client credentials with scoped permissions. What can an authenticated principal do inside the tenant, which is the user level and capability model plus governance groups. And how are the credentials for every connected source stored and used, which is the encryption and key management question that determines your blast radius if the platform itself were compromised.
API rate limit | The ISC API gateway applies a default limit of 100 requests per client_id per API version per 10 seconds. The key is the client ID and the API version, not the individual access token. |
429 Too Many Requests | The response when the limit is exceeded, accompanied by a Retry-After header giving the seconds until the window resets. Some individual APIs define their own limits. |
Scopes | The permissions attached to an OAuth client, controlling which API operations it may perform. Grant the narrowest set that works, then test by removing one. |
FedRAMP tenant | A separately authorised environment with its own hostnames on sailpointfedramp.com, its own release cadence and its own control set. |
Data residency | Determined by the AWS region hosting your tenant, which is chosen at provisioning and is not something you change casually afterwards. |
The identity platform is the highest-value target in the estate
It is worth stating plainly because it changes how much rigour this layer deserves. A governance platform holds credentials for, and the ability to grant access on, every system it manages. An attacker who compromises an over-privileged SailPoint API client does not need to attack Active Directory, the HR system and the ERP separately; they can ask SailPoint to grant them access to all three, and the resulting change will look like a legitimate provisioning operation in every downstream log. This is why the over-privileged personal access token is not a minor hygiene issue. It is the most consequential single misconfiguration available in the product.
Personal access tokens carry a person's permissions, and that is the problem
A PAT is bound to a user identity and inherits that user's user level. Created by an org admin, it is an org admin credential. It does not expire when the person changes role, and it survives in scripts, pipelines and someone's laptop long after the project that needed it ended. When the person leaves, if the offboarding process disables the identity but nobody audits the tokens, you have an orphaned credential with administrative reach. The disciplined pattern is: personal access tokens for interactive exploration and short-lived scripts owned by a named human, OAuth clients with explicit narrow scopes for anything that runs unattended, an inventory of both, and a rotation schedule that is enforced rather than documented.
Rate limits are an architecture constraint, not an error condition
The default of 100 requests per client_id per API version per ten seconds is generous for normal use and immediately restrictive for the naive integration pattern of looping over 80,000 identities one API call at a time. Because the limit keys on client ID and API version rather than on token, spinning up more tokens for the same client does not help. Design integrations to use bulk and search endpoints rather than per-object calls, honour the Retry-After header rather than retrying immediately, and back off exponentially. Check the individual API specification for anything unusual, because SailPoint documents that specific APIs may apply different limits.
Least privilege inside the tenant is usually skipped
Almost every deployment starts with everyone on the implementation team holding org admin, because it removes friction during the build. Almost none of them clean it up. The user level and capability model exists precisely so that a helpdesk operator can reset a password without being able to edit a source, and a report consumer can read without being able to change a role. Treat the tenant's own access model as an application you govern, run a certification over it like any other, and hold yourself to the standard you are asking the rest of the organisation to meet. An identity governance team that cannot pass its own access review is not in a strong negotiating position.
Source service accounts are where least privilege actually pays
Every connector authenticates to its target with a service account, and the temptation is always to give it domain admin or the equivalent so that provisioning never fails for a permission reason. The correct scoping is narrower and specific per system: read on the objects you aggregate, write only on the attributes and group memberships you provision, and nothing else. The test that finds the truth is to attempt every operation your design requires with the intended permission set, in a non-production environment, before go-live. Discovering a missing permission in test costs an hour. Discovering it by granting domain admin in production costs an audit finding that will follow the programme for years.
Get the audit stream out of the platform
The tenant holds a rich event stream, and it is searchable inside the product. That is necessary but not sufficient. Identity events belong in the same place as the rest of your security telemetry, correlated with authentication events, endpoint signals and network data, because the interesting patterns are cross-domain: an unusual entitlement grant followed by an unusual login from an unusual location. The 2026 platform direction makes this explicit with real-time identity context delivered into security operations workflows and support for the Shared Signals Framework, but the fundamental design decision is older and simpler: export the events, retain them under your own retention policy, and alert on them.
- Using a personal access token for an unattended integration. It carries that person's rights and dies with their account.
- Handing out broad user levels because it is quicker than working out which capabilities are needed, which makes the administrative model decorative.
- Assigning approval and ownership to named individuals instead of governance groups, so responsibility evaporates on the first resignation.
- Writing an API client with no backoff, then discovering the rate limit under production load rather than in testing.
- Storing source credentials outside the platform's own credential handling because a script was easier, which reintroduces exactly the problem the platform exists to solve.
Extensibility & APIs
The sanctioned ways to make it do something it does not do
Extensibility in Identity Security Cloud is deliberately tiered, and SailPoint's own guidance is explicit: consider rule usage a last resort and use platform features instead wherever you can. Transforms are configurable JSON objects that manipulate attribute data without code, evaluated during aggregation and during provisioning. Rules are code, and split into two families with genuinely different capabilities. Cloud rules execute inside the multi-tenant platform, can read the data model, and cannot commit transactions or save objects. Connector rules execute on your virtual appliance, cannot reach the data model at all, and instead operate on contextual information passed to them along with the managed connection to the target system. Workflows and forms provide event-driven orchestration without code. Event triggers push notifications of change to your own services. And underneath all of it, a versioned REST API exposes essentially everything.
Transform evaluation points | Aggregation, when raw account data becomes identity attributes, and provisioning, when identity data becomes account attributes on create or update. |
Rule submission | Cloud rules are submitted to SailPoint for review before they are deployed into a tenant. Plan for that turnaround in your project schedule. |
Search syntax | Lucene-style query over identities, access, events and account activity. The foundation of reporting, campaign scoping and workflow conditions. |
Search-based operations | Use search endpoints and bulk operations rather than per-object calls; this is the single most effective way to stay inside the rate limit. |
IdentityIQ extensibility | BeanShell rules, workflows built on the workflow engine, custom Java connectors, plugins, task and report definitions, and the full object model through the API and the console. |
Where the code runs decides what the code can do
This is the single most useful fact about SailPoint extensibility and it explains most of the confusion. A cloud rule runs in the multi-tenant platform. It can query the ISC data model in read-only mode, which is why it can make a correlation decision. It cannot commit a transaction, cannot save an object and cannot open an outbound connection to your network, because the platform will not let one tenant's code do those things. A connector rule runs on your appliance, inside the connector's own process, which is why it has the managed connection to the target system and can manipulate a provisioning plan just before it executes. It has no route back to the ISC data model, because the appliance is not the platform. When someone asks 'why can my rule not just look that up?', the answer is always which side of the boundary the rule is on.
Transform first, rule last
The escalation ladder is worth memorising. Can the platform do it with configuration? Do that. Can a transform express it? Write the transform. Can a chain of composed transforms express it? Compose them, because transforms nest. Does it need orchestration over time or an external call? Use a workflow. Only when all of those genuinely fail should a rule be written, and then only in the family that has the access it needs. Every rule you write is code that requires review, must be maintained, cannot be edited in the UI by the next person, and becomes an obstacle at every upgrade and every migration. SailPoint's own documentation puts this in writing, and the deployments that ignore it are the ones that are hardest to hand over.
Workflows are how you avoid writing an integration
A large share of the custom code in older identity deployments existed to send a notification, call a ticketing system, or wait for something and then act. Workflows cover all three declaratively, with an HTTP action that can call any external service and conditions that can branch on the event payload or on a search result. The design advantage over code is not that it is faster to write, because it often is not. It is that the next person can read it, that it is visible in the tenant configuration rather than in a repository nobody remembers, and that it moves between environments as configuration.
Event triggers invert the integration
The traditional pattern is to poll: an external system asks SailPoint every fifteen minutes whether anything changed. Event triggers reverse it, so SailPoint tells the external system the moment something happens. Two flavours exist and the difference is architectural. Fire-and-forget notifies and does not wait, which is right for downstream systems that need to know. Request-response waits for your service to answer, which means your service can influence what happens next, and which also means your service is now on the critical path of an identity operation and must be available and fast. Choose request-response only when you actually need to affect the outcome.
Version the API you call, deliberately
The ISC API is versioned, with v3 alongside dated versions such as v2024 and v2025. The rate limit is applied per client ID per API version, which has a subtle consequence: an integration split across two versions gets two separate buckets. That is not a licence to shard your traffic across versions to evade the limit, but it does mean a migration between versions does not halve your throughput. More importantly, pin the version your integration targets and test explicitly when you move, rather than tracking whatever the documentation shows today.
The IdentityIQ equivalent is far more powerful and far more dangerous
IdentityIQ lets you write BeanShell anywhere, deploy custom Java connectors, build plugins that add pages to the product, and manipulate the object model directly. That flexibility is genuinely the reason some organisations stay on it. It is also the reason IIQ migrations are hard: a decade of accumulated rules, workflows and customisations, written by people who have moved on, with no clear record of which are still needed. If you are running IIQ today and expect to move to the cloud platform eventually, the highest-value thing you can do now is inventory your customisations and start retiring the ones that exist only because nobody knew about a product feature.
- Reaching for a rule before exhausting transforms. Every rule is reviewed before deployment and edited slowly forever after, which is a permanent tax on your own change cycle.
- Writing a cloud rule that needs to reach your network, or a connector rule that needs the identity data model. Each can do exactly one of those things and not the other.
- Building a fire-and-forget trigger where you needed request-response, then wondering why your external system's answer had no effect on the outcome.
- Not pinning an API version, so behaviour changes underneath a working integration.
- Porting IdentityIQ BeanShell logic conceptually into a workflow without asking whether the process it encodes was ever a good idea.
The Wider Portfolio
Everything SailPoint sells that is not core access governance
SailPoint's portfolio has grown well beyond joiner-mover-leaver, and because everything sits on the Atlas data model, each product reasons about the same identities rather than maintaining its own. The most consequential recent change is the August 2026 launch of a unified identity security solution with two components, both powered by Atlas: SailPoint Human Fabric, the evolution of Identity Security Cloud into continuous real-time human identity governance, and SailPoint Agentic Fabric, a centralised control plane for machine and AI agent identity that became generally available at the same time. They are sold through the SailPoint Agentic Business and Agentic Business Plus suites, with Agentic Fabric also available standalone.
Machine account sub-types | Service account, bot, shared account. The distinction matters because the governance controls differ: a service account needs an owner and a rotation policy, a shared account needs attribution. |
Ownership and succession | Multiple owners can be assigned to a machine identity, with succession planning, so the account does not become ungoverned when one owner leaves. |
MCP server discovery | Model Context Protocol servers are how many AI agents reach tools and data. Discovering the ones running in your estate is a prerequisite to governing them. |
Agent Identity Security connectors | Connectors for AI platforms including Microsoft 365 Copilot, Databricks, Amazon Bedrock, Google Vertex AI, Microsoft Foundry, Salesforce Agentforce, ServiceNow AI Platform and Snowflake Cortex AI. |
Data Access Security collectors | Each collector added to a VA cluster requires an additional 2 vCPU and 8 GB of RAM on top of the base appliance specification. |
Why non-human identity became the headline
The numbers SailPoint publishes are the argument: 97 percent of AI agents have access to sensitive data, and only 21 percent of organisations are highly confident in their ability to manage AI agent security risk. Machine identities already outnumber human identities in most enterprises by a wide margin, and agentic AI accelerates that sharply, because an agent can create credentials, call tools and reach data at machine speed with no joiner process, no manager and no leaver event. The governance primitives that work for humans, a periodic certification and an approval chain, do not fit something that may exist for four minutes. That is the architectural problem Agentic Fabric is aimed at, and it is why the answers are discovery, ownership attribution, inline control and a kill switch rather than a quarterly review.
Data Access Security changes what governance means
Access governance traditionally stops at the entitlement: this person is in this group. Data Access Security continues past it: this group has effective permissions on this file share, that share contains data classified as regulated, and therefore this person can read regulated data. The join is what makes it valuable, and it is only possible because both products share the Atlas data model and the same notion of identity. It is also a materially heavier deployment than core governance, because the collectors have to crawl file systems and classify content, which is why each one adds its own compute and memory requirement to the appliance cluster.
Non-employee identity is a lifecycle problem, not a directory problem
The reason contractors are consistently the worst-governed population is not technical. It is that there is no authoritative source for them. An employee has an HR record with a start date, a manager and a termination date. A contractor is often created by an email to the service desk and remembered by nobody. Non-Employee Risk Management supplies the missing authoritative source: a record with a sponsor, an end date, a risk assessment and an owner who is accountable for renewal. Once that exists, everything the identity platform already knows how to do for employees works for non-employees. Identity proofing through verified credentials and biometrics closes the remaining gap, which is proving the person on the other end is who the sponsor says they are.
Everything on one cluster, and what that costs
SailPoint has consolidated so that multiple products can run on a single virtual appliance cluster, which is operationally welcome. It also means capacity planning is now additive and explicit. A base appliance is 4 vCPU and 16 GB. Add the Privileged Access Gateway and it is 6 vCPU and 20 GB. Add all four Data Access Security collectors and you are at 14 vCPU and 52 GB before you have aggregated anything. Size for the products you are actually deploying, revisit the sizing when you add one, and remember that this multiplies across the two appliances per cluster that high availability requires.
A caution about roadmap-driven design
This layer moves faster than any other in the product. Capabilities announced in March 2026 as forthcoming, such as the next-generation access certification engine and the separation of duties revamp scheduled for the second half of 2026, will change how parts of the platform behave. That is good, and it also means an architecture that depends on an unreleased capability is a risk rather than a plan. Design against what is generally available, keep the seam where the future capability will land, and revisit the decision when it ships.
- Buying capability before the foundation works. Data access security over an estate where identities do not correlate cleanly produces noise, not insight.
- Treating agents and service accounts as a future problem. They already outnumber your humans, and the ones without owners are the ones that will appear in an incident report.
- Assuming a capability is a product you install. Most of the portfolio is switched on in a tenant that already has the sources and the identity model in place.
- Confusing non-employee risk management with adding contractors to the HR feed. It exists precisely for the population no HR system owns.
- Letting SAP access risk be governed separately from everything else, so you end up with two answers to the question of who has too much access.
Operations & Migration
Running it in production, and moving between the two products
Once a SailPoint deployment is live, its health is measured by a small number of unglamorous signals, and its future is shaped by the release cadence of a platform you do not control. For Identity Security Cloud, SailPoint ships continuously and you do not choose when. Your sandbox tenant exists so that you can see change before it reaches production, which only works if you actually use it. Virtual appliances update themselves, which only works without an outage if you run at least two per cluster. And for the substantial part of the installed base still running IdentityIQ, there is a migration to plan, which is far more a data and process exercise than a technical one.
IdentityIQ 8.5 | Generally available July 2025. Runs on Java 17 or 21, on Tomcat 9.0, WebLogic 14c, JBoss EAP 7.4 or WebSphere Liberty 24.0 or 25.0, against MySQL 8.0 or 8.4, SQL Server 2019 or 2022, Oracle 19c, or PostgreSQL 16 or 17. |
IdentityIQ platforms | Supported on Windows Server 2022 and 2025, Red Hat 8.10 and 9.5, Oracle Linux 8.10 and 9.5, SUSE 12.5 and 15.6, Solaris 11.4, and AIX 7.2 and 7.3, and on AWS, Azure and Google Cloud compute and managed database services. |
Appliance time zone | UTC, not configurable. Every schedule and every log timestamp on the appliance is in UTC regardless of where the appliance physically sits. |
Deletion threshold breach | Treat as an incident. It almost always means the source returned incomplete data, not that thousands of accounts genuinely disappeared. |
Dual-run rule | During migration, exactly one system is authoritative for provisioning to any given application. Two governance systems writing to the same target is the most expensive mistake available. |
The four numbers that tell you whether it is healthy
Aggregation success rate per source, because a source that has not aggregated for eleven days is governing a fiction. Uncorrelated account count and its trend, because that is the orphan account population an auditor will find. Provisioning failure count and, more importantly, the age of the oldest unresolved failure, because failures that nobody clears become permanent divergence between what the platform believes and what is true. And revocation completion as distinct from certification completion, because a campaign that closed cleanly while its revocations silently failed is worse than no campaign. Put those four on a dashboard someone looks at daily, and most of the ways an identity programme decays become visible early enough to fix.
Continuous delivery means your sandbox is not optional
You do not choose your ISC release. Changes arrive, and the sandbox tenant is the only place you will see them before your users do. The failure pattern is universal and predictable: the sandbox is created during implementation, drifts out of alignment within six months, and by the time a platform change causes a production surprise the sandbox has not been representative for a year. Keeping it aligned is dull, unrewarded work, and it is the difference between a platform change being something you noticed and something that happened to you.
Plan the IIQ migration as a data and process programme
The technical migration is the easy part. What actually consumes the time is that a mature IdentityIQ deployment carries a decade of accumulated rules, workflows, custom connectors and business logic, much of which exists because a product feature was missing at the time, and most of which nobody currently employed can fully explain. The productive sequence is: inventory the customisations, classify each as still needed, replaceable by a platform feature, or dead, and delete aggressively. Then migrate source by source, starting with the ones with the cleanest data, keeping one system authoritative per application at all times, and running the two in parallel only long enough to build confidence.
Roles are the hardest thing to migrate and the easiest to get wrong
Everything else in a migration has a mechanical equivalent: an Application becomes a Source, a Link becomes an Account, a ManagedAttribute becomes an Entitlement. Roles do not, because IdentityIQ's Bundle covers both business and IT roles while the cloud platform splits the idea into Roles and Access Profiles. That is not a rename, it is a remodelling, and it is an opportunity. Most mature IIQ role models have accumulated roles that are used by three people, roles that duplicate each other, and roles whose assignment rules nobody dares change. Migration is the only moment when there is organisational appetite to rationalise them. Take it.
The programme fails at handover more often than at go-live
The pattern is consistent enough to plan against. A systems integrator builds the deployment, it goes live successfully, the integrator leaves, and the internal team inherits a system whose transforms, rules and workflows they did not write and whose design decisions were never recorded. Six months later small changes are avoided because nobody is sure what will break. The countermeasures are unglamorous and they work: insist on documented design decisions rather than just configuration exports, have the internal team build a meaningful share of the sources themselves during the project, keep the customisation count low precisely so that handover is possible, and treat the ability of the receiving team to make a change unaided as an explicit exit criterion.
- Not knowing that appliances update themselves, then investigating the resulting aggregation gap as an outage.
- Leaving telemetry unexported, so every appliance question becomes a support ticket rather than a dashboard.
- Promoting from sandbox by hand and by memory, which works until the day somebody forgets one transform.
- Running IdentityIQ on a platform combination outside the supported matrix and discovering it at upgrade time.
- Planning an IdentityIQ migration as a technical exercise. The hard parts are the role remodelling and the process decisions, and both need the business in the room.
- Treating handover as documentation. If the only person who understands the identity profiles is a departing consultant, you have bought a system you cannot operate.
What actually happens, step by step
The fastest way to understand an architecture is to follow one thing all the way through it. These six traces each follow a different journey across the same stack, from a new starter appearing in an HR feed to an API client hitting a rate limit. Colours mark where each step actually happens.
Almost every 'why did this person not get their access' question is answered by knowing exactly where in this sequence the process stopped.
Understanding where approval sits relative to policy evaluation explains why some requests are blocked before an approver ever sees them.
The distinction between what aggregation does and what identity processing does is the single most useful thing to understand when debugging.
Knowing where revocations actually execute explains why a campaign can complete perfectly while the access it revoked is still in place.
Time to revoke is a real security metric, and this trace shows every place it can stall.
Nearly every custom integration problem in SailPoint is an authentication scope problem or a rate limit problem.
The sequence that explains most of your identity problems
When identity processing runs for an identity, it does four things in a fixed order. That order is not arbitrary, and knowing it answers a whole class of questions that otherwise look like the platform behaving randomly.
Aggregation and identity processing at a glance
The same sequence runs whether processing was triggered by an event, by the scheduled cycles, by a next-processing time or by an administrator clicking apply.
Scroll the diagram sideways, or tap Enlarge for a bigger view
Before anything: the source must have been read
Source system- Aggregation has pulled the account from the source into the data model
- The account has been correlated to an identity, or it has not, in which case nothing below happens for that person
- Aggregation on its own changes no identity attributes, assigns no roles and provisions nothing
Step 1: identity attributes are computed
Tenant- The identity profile maps each authoritative account attribute to an identity attribute
- Transforms run here, converting raw source values into the form the model needs
- If more than one identity profile applies, the one with the highest priority, meaning the lowest priority number, wins
- Nothing below this step can see an attribute that has not been computed yet
Step 2: the manager is resolved
Tenant- Manager correlation turns a manager identifier on the account into a link to another identity
- If the manager identity does not exist yet, the link is not made and the identity has no manager
- Every manager-based approval and every manager certification downstream depends on this having worked
Step 3: the lifecycle state is applied
Tenant- The identity's current lifecycle state determines what access it should have and should not have
- The lifecycle state can also set the identity state to active, inactive short-term or inactive long-term
- This is where a prehire becomes active, and where a leaver stops being active
Step 4: roles are recalculated
Tenant- Every role whose assignment criteria could match this identity is re-evaluated
- Criteria are evaluated against the attributes computed in step 1, which is why the order matters
- Newly matching roles add their access profiles; roles that stopped matching remove theirs
After: provisioning acts on the difference
Provisioning- The platform compares the access the identity should have against the access it does have
- The difference becomes a provisioning plan, partitioned one partition per source
- Each partition succeeds or fails independently; there is no rollback across sources
- The next aggregation of each source reads the result back and reconciles intent against reality
The part of the model everything else depends on
Almost every design conversation in SailPoint eventually lands on the same small set of objects and how they nest. This is that set, laid out in the order that makes it stick.
The seven objects, and how they hang together
Learn this one diagram properly and most of the rest of the platform stops needing to be memorised, because it can be worked out.
Scroll the diagram sideways, or tap Enlarge for a bigger view
Source to account to identity
A source is a connected system. Aggregating it produces accounts, one per login on that system. Correlation attaches each account to an identity using the source's correlation configuration, typically comparing something like the account's employeeNumber to the identity's employeeId. An account that matches nothing becomes an uncorrelated account: still visible, still reportable, belonging to nobody. That population is exactly what an auditor means by orphan accounts, and its size and trend is one of the four numbers worth watching daily.
Entitlement to access profile to role
These three exist at deliberately different levels of abstraction. An entitlement is a technical fact on one system: a group, a permission, a licence. An access profile bundles entitlements from a single source into something an application owner recognises. A role bundles access profiles across sources into something the business recognises. The design discipline is to model at the level at which the person reviewing that access can actually judge it. Exposing raw entitlements in a request catalogue produces something nobody can govern; forcing everything into roles produces role explosion.
The identity profile is a rule set, not a record
An identity profile makes a source authoritative, defines how each raw account attribute becomes an identity attribute, specifies the correlation criteria, and carries a priority. When a person appears in more than one authoritative source, the profile with the highest priority, meaning the lowest priority number, determines their attributes. Getting priority backwards is how a contractor record ends up overwriting an employee's job title.
Identity attributes are computed, never edited
This is the mental model shift that catches everyone coming from a directory. The department on an identity is not stored by hand; it is derived from an authoritative account attribute, optionally through a transform, applied during identity processing. Change it on the identity and it will be overwritten. Change it in the source, or change the mapping. Every 'my edit did not stick' ticket in a SailPoint deployment is this principle asserting itself.
Three doors into access, and a design should name them
Birthright access arrives automatically when an identity matches a role's criteria. Requestable access is chosen in the request centre and passes approval. Direct assignment is granted by an administrator. Each has a different control posture, and the door that should be narrowest and most logged is the third. The most common failure is a birthright role whose criteria are so broad that everyone qualifies, producing an access model that looks governed and grants everything to everyone.
Governance groups instead of named people
A control that depends on one named individual is a control that breaks when that person changes role. Governance groups are named sets of identities used as approvers, reviewers and scopes. Using them everywhere an approver or reviewer is configured means the control survives organisational change without a configuration project.
IdentityIQ names the same things differently
Application is Source. Link is Account, and Link is the more honest name because it links an identity to an account on an application. ManagedAttribute is Entitlement. Identity Cube is Identity, and 'cube' is a reminder that it is assembled from many systems rather than stored as one row. Bundle covers both business roles and IT roles, where the cloud platform splits that idea into Role and Access Profile. The concepts survive a migration; the configuration surfaces do not.
Where the physical tables live in IdentityIQ
If you are debugging IIQ directly, the schema is roughly 300 tables prefixed spt_. The ones you will actually query are spt_identity for the identity cube, spt_link for accounts, spt_managed_attribute for entitlements, spt_bundle for roles, spt_application for applications, and spt_identity_entitlement for the flattened view of who holds what. Knowing those six names turns most 'the UI says something odd' investigations into a single query.
The wider portfolio, and why it is one platform
The Atlas platform is what lets these products reason about the same identities rather than each keeping their own. This is the portfolio as it stands after the August 2026 unified launch, left to right by how far it sits from classic access governance.
Six problems, one foundation
Scroll the diagram sideways, or tap Enlarge for a bigger view
Thirteen arguments you will have, settled
Architecture is mostly choosing between two reasonable options. These are the choices that come up on nearly every SailPoint programme, with the rule of thumb that usually decides them.
Identity Security Cloud or IdentityIQ?
Identity Security Cloud
- You are starting fresh and have no large body of custom Java or BeanShell
- You want SailPoint to own upgrades, capacity and the connector runtime
- Your roadmap includes Data Access Security, Machine Identity Security or the agentic capabilities, which are ISC only
- Your governance model can be expressed in transforms, workflows and cloud rules
IdentityIQ
- A regulator or contract requires the platform to run inside your own data centre
- You have deeply customised workflows that encode a process the business will not change
- You need synchronous, in-process control over the provisioning broker at a level the SaaS APIs do not expose
- You are mid-programme and a migration would stall a compliance commitment
Transform or rule?
Transform
- You are shaping a string: concatenate, substring, lookup, upper, lower, date format
- The logic can be expressed as nested operations on account or identity attributes
- You want the change to be self-service, versioned in the tenant and visible to another admin
- You want it to survive a platform upgrade without review
Rule
- You need to call out to something the transform language cannot reach
- The logic requires iteration, branching that is genuinely complex, or a managed connection to a source
- You are generating a value that must be checked for uniqueness against a live directory
- You have exhausted the transform catalogue and can say precisely which operation is missing
Cloud rule or connector rule?
Cloud rule
- The logic only needs identity or account attributes that ISC already holds
- You are calculating a value during identity refresh or provisioning
- No network call to the source system is required
Connector rule
- The logic must run next to the source, inside the Virtual Appliance
- You need the connector's live, authenticated connection to the target
- You are transforming data on the way in or out of a specific connector
Role or access profile?
Role
- The grant is described in business language: a job, a department, a location
- It should be assigned automatically by criteria or by identity attributes
- It bundles access across more than one source
Access profile
- The grant is a coherent unit of access inside one source
- You want it requestable on its own in the Request Center
- It is a building block that several roles will reuse
Birthright or requestable?
Birthright
- Everyone in a defined population needs it to do their job on day one
- Denying it would generate a ticket every single time
- The access carries low risk and no separation-of-duties weight
Requestable
- Only some people in the population need it
- Someone accountable should say yes before it is granted
- The access is privileged, regulated or expensive to license
Aggregate on a schedule or aggregate on an event?
Schedule
- The source has no reliable change notification
- You need a known-good full picture for certification and reporting
- Drift detection matters more than latency
Event
- The source can push or expose changes as they happen
- Joiner and leaver latency is a business commitment, not a nice-to-have
- The population is large enough that full reads are expensive
Lifecycle state or identity attribute?
Lifecycle state
- The value should drive access automatically
- There are a small number of well-understood values such as active, leave, terminated
- You want a state change to trigger provisioning and deprovisioning
Identity attribute
- The value is descriptive and used for search, reporting or role criteria
- It has many possible values
- Changing it should not, on its own, move access
Certify entitlements or certify roles?
Entitlements
- You are early in the programme and the role model is not trusted yet
- A regulator wants evidence at the level the target system enforces
- You are hunting for outliers and direct grants
Roles
- The role model is mature and the business understands what each role means
- You want review volume that a human can actually think about
- You are certifying job function rather than technical access
One Virtual Appliance cluster or several?
One cluster
- All sources sit in the same network zone and are reachable from one place
- You want the smallest number of moving parts to patch and monitor
- Traffic volume is comfortably inside the cluster's capacity
Several clusters
- Sources live in separate networks, regions or clouds that cannot reach each other
- A regulated or high-security zone must not share a runtime with the rest
- You need to isolate a heavy source so its aggregation does not starve the others
Personal access token or OAuth client credentials?
Personal access token
- You are exploring the API, scripting a one-off or building a proof of concept
- The action should be attributable to a named human
- The lifetime is short and you will delete it afterwards
OAuth client credentials
- A system, pipeline or integration calls the API on a schedule
- The credential must outlive any individual's employment
- You need scoped rights that do not inherit a person's user level
Model machine identities as identities or as accounts?
As identities
- The object needs an owner, a lifecycle and a certification of its own
- It holds access that a human could otherwise misuse
- Auditors ask who is accountable for it
As accounts
- It is a service account tightly bound to one application and one owner already governed
- It carries no standing privilege beyond its own application
- Promoting it would create governance overhead with no reviewer who could act on it
Migrate IdentityIQ to ISC as a lift or as a rebuild?
Rebuild
- Your IIQ implementation accumulated custom workflows nobody fully understands
- The role model has grown organically and needs pruning anyway
- You want to land on transforms and configuration rather than code
Lift
- The existing model is clean, documented and genuinely fits the target
- You are under a hard deadline and can accept carrying the debt forward
- You have people who wrote the original and will be there for the cutover
Approve access with a manager or with an entitlement owner?
Manager
- The question is whether this person should have access at all
- The reviewer needs to know the person, not the system
- Volume is high and you need a reviewer who is always identifiable
Owner
- The question is whether this particular entitlement is the right one
- The access is privileged, licensed or technically subtle
- The manager would rubber-stamp because they cannot evaluate it
Fourteen mistakes that create technical debt
Every one of these looks reasonable at the moment somebody does it. Each entry explains why it hurts later and what to do instead.
Onboarding every source at once
Why it hurtsEach source brings its own data quality problems, its own account correlation puzzle and its own owner who is slow to answer questions. Ten sources in parallel means ten unresolved problems and no working end-to-end flow to show for it.
Do this insteadOnboard the authoritative source first and get identities correlating cleanly. Then add one target and prove joiner, mover and leaver against it. Only then open the queue.
Treating the HR feed as clean
Why it hurtsAuthoritative sources carry duplicate records, blank manager fields, contractors recorded as employees and termination dates in the future. Identity processing will faithfully reproduce every one of those problems as an access decision.
Do this insteadProfile the source before you point ISC at it. Count the nulls in every attribute you plan to use in an identity profile, and agree with the HR owner who fixes what.
Running one Virtual Appliance
Why it hurtsA single appliance is a single point of failure and it also blocks maintenance, because automatic updates take an appliance out of service while it reboots. Aggregation and provisioning stop when it does.
Do this insteadDeploy at least two appliances per cluster. That is not a resilience nicety, it is what makes the update process invisible to the business.
Skipping the sandbox tenant
Why it hurtsTransforms, identity profiles and lifecycle states change behaviour for every identity the moment they are saved. A wrong identity profile mapping does not fail loudly; it quietly reassigns roles across the population.
Do this insteadUse the sandbox tenant for every change to identity profiles, transforms, roles and campaigns, and promote deliberately. Test with a representative sample, not with one obliging test user.
Setting the deletion threshold to zero or ignoring it
Why it hurtsThe threshold exists because a source that returns an empty or truncated account list looks exactly like a source where everyone was deleted. Without it, one bad read deprovisions the company.
Do this insteadSet a threshold that reflects normal churn for that source, then treat a threshold breach as an incident to investigate rather than an obstacle to override.
Granting access directly instead of through the model
Why it hurtsDirect grants are invisible to the role model and to anyone reasoning about why someone has access. They accumulate, they survive job changes, and they turn every certification into an archaeology exercise.
Do this insteadRoute everything through access profiles and roles. Use direct assignment as a deliberate exception with an expiry, and report on it monthly so it stays visible.
Building a role per person
Why it hurtsRole explosion is the classic IGA failure. Roles that match one individual defeat the point: they carry no meaning, they cannot be certified sensibly, and the model grows faster than the population.
Do this insteadStart from job families and locations, aim for roles that cover a meaningful population, and accept that some access will always be requestable rather than modelled.
Launching a campaign covering everything
Why it hurtsA campaign with tens of thousands of items produces approval fatigue, and approval fatigue produces bulk approve. The evidence you generate is worse than no evidence because it looks like diligence.
Do this insteadScope campaigns by risk and by population. Certify privileged and regulated access more often and in smaller slices, and measure how long reviewers actually spend per item.
Calling the campaign done when the reviews are done
Why it hurtsCertification completion means decisions were recorded. Revocation completion means access was actually removed from the target system. The gap between them is where the audit finding lives.
Do this insteadTrack revocations to completion as a separate metric, and investigate every revocation that fails or stalls in a manual work item queue.
Writing a rule because the transform looked awkward
Why it hurtsEvery cloud rule needs a SailPoint review before deployment, cannot be edited freely, and becomes a piece of code your team must understand years later. Awkward configuration is cheaper than convenient code.
Do this insteadExhaust the transform catalogue first, including nesting and account attribute lookups. If you still need a rule, write down which specific operation was missing so the decision is defensible.
Giving the integration a powerful user level
Why it hurtsA personal access token inherits every capability of the person who created it. Point an integration at an org admin's token and every API call runs with total authority, and it stops working the day that person leaves.
Do this insteadCreate a dedicated client with the narrowest rights that make the integration work, and check the rate-limit behaviour under load rather than discovering it in production.
Ignoring the rate limit until production
Why it hurtsThe ISC API limits requests per client and per API version over a short window and answers with 429 plus Retry-After. Integrations written without backoff work perfectly against a small tenant and collapse against a large one.
Do this insteadHonour Retry-After, add exponential backoff and jitter, and prefer bulk and search endpoints over looping single-record calls.
Ignoring the appliance update window
Why it hurtsAppliances update themselves automatically, and the underlying Flatcar operating system soaks for about a week before the reboot. Teams that do not know this see unexplained aggregation gaps and open support tickets.
Do this insteadDocument the update behaviour, size clusters so one appliance can be out at any time, and export appliance telemetry so you can correlate a gap with a reboot in seconds.
Treating the leaver flow as the same problem as the joiner flow
Why it hurtsJoiner is forgiving: if access arrives late, someone complains. Leaver is not: if access lingers, that is the finding. They are asymmetric, and building them with the same urgency and the same testing is how orphaned access survives.
Do this insteadTest the leaver path harder than the joiner path. Verify that every target actually disables or deletes the account, and put the exceptions into a monitored manual queue rather than trusting them to a person's memory.
Every term on this page, defined
Search it, or filter by the layer a term belongs to.
Practice challenge
3 questionsQ1IdentityIQ is fundamentally a?
Java web application. IdentityIQ is a Java web app on an application server with a relational database.
Java web application. IdentityIQ is a Java web app on an application server with a relational database.
Q2One account on one application, attached to an identity, is a?
Link. A Link represents a single account correlated to an identity.
Link. A Link represents a single account correlated to an identity.
Q3The process that recomputes attributes and role assignments is?
Identity refresh. Identity refresh recalculates attributes, roles and policy on the cube.
Identity refresh. Identity refresh recalculates attributes, roles and policy on the cube.
Frequently asked questions
Is Identity Security Cloud multi-tenant?
What actually runs inside my network?
Do I have to open inbound firewall ports for SailPoint?
How many Virtual Appliances do I need?
What is the difference between an identity profile and an identity?
What is the order of identity processing?
Why did nothing happen after I changed a transform?
What is the difference between an entitlement, an access profile and a role?
Can I move from IdentityIQ to Identity Security Cloud automatically?
What is the Atlas platform?
What is the Human Fabric and the Agentic Fabric?
Do I need a rule to generate unique usernames?
Why is access still there after the certification finished?
What is the ISC API rate limit?
Which API version should I use?
How is Non-Employee Risk Management different from just onboarding contractors?
Want this taught live, with job support?
SailPoint Training is delivered live by working practitioners, with certification prep and placement support.
See SailPoint Training →