SailPoint ISC Administrator Exam Study Guide

SailPoint Human Fabric is SailPoint’s next-generation identity security solution. It builds on IdentityNow, and the documentation covers both. Identity governance means enforcing least privilege: every identity has the access it needs, when it is needed.

• Register a device. A user who signs in through an identity provider (IdP) for the first time must configure an external authenticator (TOTP). This is a one-time step. It guarantees access if SSO has to be bypassed, as with emergency admin accounts.
• Add initial administrators. You need one or more emergency access administrators. They can sign in even if connectivity (SSO) is interrupted, so they can troubleshoot. SailPoint creates one for you when the tenant is provisioned. You use it to sign in and add more admins.
• Load data. Connect sources, then link accounts that belong to the same person into an identity.
• Create identities. Create initial sources first (HR or directory sources), then create identity profiles, then load initial accounts (aggregate).
• Load other account and access data. Create additional sources, correlate accounts to identities, and load entitlement data.
• Configure security settings. Strong authentication (MFA), network and location restrictions, lockout settings, session lengths.
• Configure cloud services. Access Requests, Certifications, Password Management, Separation of Duties.
• Invite users.

Product Licenses page shows: Identities (total permissible, all lifecycle states), Org Name (unique to the tenant), Region, Active Licenses (enabled and disabled features), Inactive Licenses (available but not licensed).

The Resource Center icon (top right) gives you documentation, in-app product tours, the support portal, product announcements (a badge shows when there are new ones), and training and health status.

Definition. A VA is a Linux-based virtual machine, provided as a virtual disk image, that connects your tenant to on-premises systems (private cloud apps count as on-premises). You host it on your infrastructure, and SailPoint manages and patches the software.

Connectivity model. SailPoint does not connect into the VA. The VA makes continuous outbound-only calls to the cloud to poll the cluster queue for work such as aggregation and provisioning, install patches, and update images. VAs allow the tenant to reach your sources without compromising your firewall.

Your responsibilities: procure the hardware or hypervisor, ensure connectivity to the cloud, and monitor VA health.

Deployment options:

• Local: vSphere 8.0+ (download, unzip, copy to the platform) or Microsoft Hyper-V (use the sailpoint-va.vhd file, Generation 1, External V-Switch, “use an existing virtual hard disk”).
• Cloud: AWS, Azure, GCP. Minimum sizes quoted: AWS M5.xlarge or equivalent, Azure Standard_D8s_v5, GCP n2-standard-4. Local minimum starts at 4 processors.
• Cluster component additions raise the minimum size: for example, the Privileged Action Gateway adds 2 processors and 4 GB memory; each Data Access Security collector adds 2 processors and 8 GB.

Cluster rules:

• Deploy at least 2 VAs per cluster (also in sandbox). This keeps connectivity during rolling updates and provides high availability. A load balancer is not required.
• 1 VA per virtual machine host.
• DMZ deployment is not recommended.
• For organizations using AI-Driven Identity Security with IdentityIQ, only 1 VA is needed.
• VAs must reach your internal DNS and NTP servers (both required). An HTTP proxy is optional.

Updates:

• SailPoint pushes VA updates. They cannot be skipped or delayed, and there is no advance notice.
• Updates reach sandbox about a week before production.
• A cluster performs rolling updates, one VA at a time.
• If any VA in a cluster is not connected, no VA in that cluster receives updates.
• SailPoint supports only N-2 major releases.
• Long-running aggregations can be interrupted by an update.
• If a VA does not reboot after an update, restart the VA cluster manually.

Monitoring VA health: email notifications, the Clusters tile on the Admin Dashboard, Admin > Connections > Virtual Appliances (cluster cards with status badges), cluster details (Virtual Appliances tab), the VA component status page, and export of metrics and logs to third-party tools (VA Observability). Example badges: VA Update in Progress (at least 1 VA configuring) and Empty Cluster (no VAs, unusable until VAs are added).

VA keys: a VA key is generated when you create a VA. You cannot create or delete it on the API Management page. Delete the VA to remove its key.

Path: Admin > Connections > Sources > Create New.

Three setup routes:

• Standard Setup: full configuration.
• Express Setup: minimal read-only connection (supports credential providers). Quick Compliance sources can use it.
• Connectivity Agent: generative-AI assisted setup (currently for the Web Services SaaS connector). You can switch to standard, but you cannot switch back. Always verify AI recommendations.

Standard setup fields: unique name and description, source owner, direct or file-based, VA cluster (for direct connect), optional governance group (grants source or role sub-admin oversight), and the Authoritative Source checkbox for primary personnel systems.

Key defaults and rules:

• New sources are read-only by default. Provisioning (a deep governance capability) must be turned on with the Enable Provisioning toggle in Base Configuration.
• You need identity profiles for an authoritative source in order to create identities from it.
• Every source must have a source owner, who handles manual provisioning tasks and certifications. The owner of the internal IdentityNow source can only be set through the Update Source (Partial) API.
• Create HR or directory sources first so their data has the highest priority.

Viewing accounts on a source: account list shows correlated identity. Accounts marked (Uncorrelated) have a shadow identity but no authoritative match. Actions: Disable Account, Aggregate Account (single), Remove Account (re-aggregated next time unless removed at the source). Export is not available for sources with more than 100,000 accounts.

Best practices: aggregate only needed accounts (filter at the connector), as infrequently as business needs allow (rarely more than daily for non-authoritative sources), outside business hours, and use delta when available.

Scheduling:

• Path: Source > Account Management > Account Aggregation > Enable Schedule.
• Frequencies: Daily (Reoccurs Every plus Start Time; recurrences end at midnight), Weekly, Monthly (dates 1 to 28 only).
• The schedule’s time zone comes from the VA cluster (a GMT offset) and does not shift for daylight saving.
• Quick Compliance sources: up to 3 aggregations per day, minimum 8 hours apart, and manual aggregation once per day. These limits do not apply to Org Admins.
• Queued or in-progress jobs can delay the start.

Account deletion on aggregation: optionally Enable Account Deletion so accounts missing from an aggregation are removed. Percentage of Deleted Accounts Allowed is a safety limit. If an aggregation would delete more than that percentage, it is canceled and a warning generated. For small sources the percentage rounds to whole accounts. Example: a source with 10 accounts needs at least 5% to round to 1 account. Settings apply to manual and scheduled runs.

Canceling: use Menu > Cancel on the Latest Account Aggregation card or the Aggregation History page.

Entitlement aggregation: manual or scheduled for direct connect sources. Flat file sources can only be aggregated manually, with one entitlement type. All entitlement types are aggregated by default (or choose Specific Types). Up to 2 million new or changed entitlements per aggregation.

• The account schema is the set of attributes a source stores. Each schema has one Account Name and one Account ID. Editing them after aggregation is strongly discouraged. Account attributes cannot exceed 128 characters.
• Discover Schema imports the schema from the source (not all sources support it).
• Schema changes are audited. Search type:source_management.
• An entitlement type needs a name that exactly matches the native object type. Never create a type called permission in any capitalization, because permission-type entitlements are direct permissions and are handled differently.
• Include permissions in aggregations brings indirect permissions in for certification context. Cloud Enabled marks types that grant cloud access for SailPoint CIEM.

Definition: matching source accounts to identities by comparing an account attribute with an identity attribute. The operation is always Equals, and it is not editable.

• Configure it before the first aggregation. If you change correlation on an already-aggregated source, run an aggregation with optimization disabled so unchanged accounts are re-examined.
• Criteria are evaluated one at a time in the listed order. The first match correlates the account. Drag to reorder, or use Optimize Order (recommendations).
• Correlation is case-insensitive by default. Change it per source with ignoreCase in the Update Correlation Config API.
• Recommendations (with application onboarding): suggestions under 50% match are filtered out by default. You can dismiss a recommendation and give feedback. Use Test to estimate the correlation percentage on a sample.
• Custom identity attributes must be searchable to appear in correlation. You can add up to 6 additional searchable attributes through the API. Run manual processing for all identities before aggregation so they apply.
• Accounts SailPoint creates have manuallyCorrelated=true.

Uncorrelated accounts: common causes are former employees, bad or incomplete data, or identities that were never created. Resolve them before the identity can be granted access. Use the Uncorrelated Accounts report (Admin > Global > Reports) to find them, then fix attribute values on the source and re-aggregate.

Links an employee to a manager. It is used in certifications and approvals. It needs both: (1) the Manager Name attribute mapped in each identity profile, and (2) a Manager Correlation Configuration on a source (usually the authoritative one). Example: match the source manager attribute to the manager’s identificationNumber. Identity profiles are evaluated in priority order. Download the Identities Without Managers report to find gaps.

Detects accounts created, updated or deleted out of band (outside SailPoint) during aggregation, so you can remediate. Path: Source > Account Management > Native Change Detection. Selected operations and attributes combine with AND (for example, creations plus memberOf detects only new accounts that have memberOf).

You can set approval processes for deletion of human and uncorrelated accounts. Approval is enabled by default and the source owner is the default reviewer.

An identity stores all of a user’s account and access data in one place. Identities are created when you aggregate accounts from authoritative sources. Types you may govern:

• Human identities (employees, contractors, vendors).
• Robotic process (bot) and service-account identities.
• Machine identities created through Machine Identity Security and Agent Identity Security (application identities and AI agent identities).

A source becomes authoritative when you create an identity profile for it. Every account aggregated from that source becomes an identity, and other accounts for those users can then be correlated to them. The identity profile determines:

• Security settings (sign-in method, invitation options, blocks, reset methods).
• Mappings that populate identity attributes.
• Access granted or removed when lifecycle states change (with Provisioning).

Priority rules:

• Each identity belongs to only one identity profile.
• An identity is assigned to the highest-priority profile where it has an account on that profile’s authoritative source.
• Default priority is creation order (earlier means higher). Change it with the Update Identity Profile API (priority attribute).
• An identity profile cannot be created while an account aggregation is running.

Creating a profile: Admin > Identity Management > Identity Profiles > Create New. Choose a name, the source, a description, then the security settings.

• Mappings define how each identity attribute is populated, per identity profile. Values can come from any source’s account attributes. Example: email from Active Directory but everything else from HR.
• Required attributes: User Name (uid), Work Email (email) and Last Name (lastname). They need a mapping in each profile and cannot be null. User Name must be unique across all identities from every profile. Work Email is not validated as an email address.
• Forbidden characters in the source attribute mapped to username or an alternative sign-in attribute: * ( ) & ! . (the user may not be able to sign in).
• Default attributes include city, costCenter, country, department, displayName, email, endDate, firstname, identificationNumber, inactive, initials, lastname, licenseStatus, location, locationCode, middleName, nextProcessing, organization, personalEmail, phone, postalCode, preferredName, startDate, state, streetAddress, timezone, title, uid, workPhone. Do not delete defaults.
• Special attributes: map Lifecycle State to use lifecycle-based provisioning. Map Manager Name (plus manager correlation) for manager-dependent features. personalEmail and phone set by users on their Preferences page are not changed by aggregation.
• Custom attributes: Add New Attribute on the Mappings page. The Name accepts letters, numbers and spaces, and the Technical Name auto-generates in camel case. A custom attribute appears in all identity profiles, though you need not map it everywhere. Deleting one removes it from all profiles.
• Preview lets you verify mappings against a chosen identity. Then Apply Changes pushes them to the profile’s identities.

Transforms and rules:

• Simple transforms: E.164 Phone Format, ISO3166 Country Format, Remove Diacritical Marks, ToLower, ToUpper. For tenants onboarded after 7 Feb 2024: RFC5646 and User Preferred Name.
• Complex transforms combine simple ones (for example, computing lifecycle state from a start date).
• Use E.164 on Work Phone to allow international numbers.
• A multi-value attribute in a mapping transform keeps only the first value.
• Rules (select Complex Data Source) are more flexible but must be reviewed by SailPoint Services before use. Transforms do not need this.

Processing recalculates attributes, manager, lifecycle-driven access and role-driven access when identity data or access model configuration changes.

What event-based processing does (in order):

• Updates identity attributes per profile mappings.
• Determines the manager through manager correlation.
• Updates access per the assigned lifecycle state.
• Updates roles by criteria and adjusts access for roles added or removed.

Processing does not verify that access was successfully provisioned after the provisioning starts.

Scheduled run details:

• 8:00 AM: Active and Inactive (short-term) identities with an account on a source configured with attribute sync.
• 8:00 PM: If roles exist, Active and Inactive (short-term) identities are processed. With no roles, identities are processed only if an attribute is flagged for periodic refresh.
• Only identities with changes are updated.

Time-based processing (nextProcessing): map it to an account attribute holding the date. It must be in the future, in ISO 8601 format, and set at least one hour after the attribute was last updated. It is configured per identity profile and can use a transform to choose the earliest future start or end date.

Manual processing:

• Apply Changes on an identity profile processes that profile’s identities. Apply Changes on the roles, access profiles or applications pages processes Active and Inactive (short-term) identities.
• Best practice: finish all role, access profile and application edits before pressing Apply Changes, and preview identity profile changes first.
• Review recent configuration changes shows changes since the last manual processing.
• Per identity: Admin > Identity Management > Identities > Actions > Process Identity (or Process Identities for several).
• Monitor in Admin > Dashboard > Monitor (Active Jobs). In Search use: name:“Manual Identity Processing Started” OR name:“Manual Identity Processing Passed”.

A lifecycle state carries an identity state, which controls where the identity appears:

The Non-Employee Lifecycle Manager lets you track contractors, interns and consultants who are not in any HR system. To use it you must define a non-employee source, define an identity profile for it, and create accounts. You must regularly download the list of non-employee accounts as your own system of record. Advanced needs belong to Non-Employee Risk Management.

Admins and Access Revokers can submit requests to remove entitlements, roles and access profiles from any user.

Path: Admin > Access Model > Entitlements. They can be configured for requests, grouped into access profiles, added directly to roles, and reviewed in certifications.

Key attributes:

• Permissions: units of read, write or other access. Direct permissions are aggregated as entitlements and shown on the directPermissions attribute. You cannot modify a permission inside SailPoint.
• Type: some sources support several entitlement types, each with its own schema.
• Direct privilege level: set manually or by a privilege classification method (Manual Override, Applied custom criteria, Applied recommendation, Same level applied to all entitlements).
• Effective privilege level: the highest of the entitlement’s own direct level or the highest effective level inherited from parent entitlements (derived by Inheritance or Direct).
• Assignment type for new assignments: Standing (continuous provisioned access until revoked) or Just-In-Time (user must activate it from MySailPoint > Launchpad > Just-In-Time Access before each use).
• GenAI entitlement descriptions can be generated for selected entitlements.
• Entitlements from the internal IdentityNow source (including launcher-generated entitlements for Privileged Task Automation, which can take up to an hour to appear) cannot be deleted or overwritten on import.

Purpose: bundle related access from a single source (for example, one profile for transaction entry and reporting, another for vendor management).

How they are granted:

• Automated provisioning through lifecycle states or role criteria.
• Access requests (directly or via a role).
• Detection: during identity processing, if a user holds all entitlements of a profile, the profile is granted automatically. They then hold the profile and no longer hold those entitlements individually.

Creating one: Admin > Access Model > Access Profiles > Create New (or from within a source: Aggregation History and Connections > Access Profiles). Tabs: Configuration, Manage Entitlements, Metadata Attributes, Access Requests, Multiple Account Options. Then Enable Access Profile.

Limits and rules:

• Name up to 128 characters. Description up to 2,000 characters.
• Up to 10 additional owners (identities) or 1 governance group, plus a primary owner.
• Must contain at least one entitlement.
• Entitlement Source cannot be changed after saving.
• A disabled access profile cannot be used in access requests.
• Multiple Account Options decide which account gets the access when the user has several accounts on the source.
• New or changed profiles take effect only through identity processing (Apply Changes).

You need Provisioning to use roles. Org admins, Role Admins (all roles) and Role Sub-admins (only roles for their authorized sources) can manage them.

Role types:

• Standard: groups standing entitlements and access profiles and provisions them by assignment criteria.
• Dynamic: grants birthright access through role dimensions. Different dimensions give different access within one role, instead of many near-duplicate roles.

Role settings:

• Name up to 128 characters, description up to 2,000, primary owner plus up to 10 identities or one governance group.
• Common Access (with AI-Driven Identity Security): marks a role as broad access granted by automation. Such roles are omitted from access request recommendations.
• Should contain at least one entitlement or access profile.
• Tabs: Manage Access, Define Assignment, Access Requests, Metadata Attributes.
• Enable Role when assignment criteria are configured or requests are allowed.
• Role changes apply through identity processing.

Role assignment (automatic): Define Assignment offers Standard Criteria (rules) or Identity List (manually chosen identities). Criteria types are Identity Attribute, Account Attribute and Entitlement. Only string and boolean attributes are supported. The account description, account ID and account name attributes cannot be used. Operators include Equals, Does Not Equal, Contains, Does Not Contain, Starts With, Ends With, Greater Than (or Equals), Less Than (or Equals). Multiple values on Equals are compared as OR.

Key behavior: when an identity stops meeting criteria, SailPoint deprovisions the role and its access profiles. Revoking roles and entitlements does not remove source accounts, even if the accounts were created by the role.

• Access is authorized ahead of time but provisioned only when the user activates it. It is removed when the activation period ends, the user deactivates, or it is revoked.
• JIT is configured on entitlements (Admin > System Settings > Just-In-Time > Entitlement Assignments). Access profiles, roles and role dimensions can contain JIT entitlements.
• When a profile or role with mixed entitlements is assigned, standing entitlements are provisioned, and JIT entitlements wait for activation.
• Within an access profile, role or dimension, an entitlement cannot be switched between JIT and standing. A user who already had standing access keeps it if the entitlement is later made JIT.
• Supporting features: JIT activation policies, duration policies, configurable notifications, and ServiceNow ticket validation.

• Access request segments (Admin > Access Model > Segments) make access items visible only to users in the segment. Details in Module 6.
• Metadata attributes add context to access items (default and custom). They can be attached to access profiles and roles.

Provisioning changes user access on systems. It can be initiated by users (access requests, certifications, manager requests) or by automation (role assignment, lifecycle states, attribute sync).

• Direct connection: provisioning is automatic.
• Flat file source: SailPoint cannot write to the system, so a manual work item goes to the source owner in the Task Manager (Admin > Dashboard > Tasks).
• Check whether provisioning is enabled with the Get Source API: PROVISIONING appears in the source’s features. Remove PROVISIONING (and ENABLE) via Update Source API to force manual work items.
• Best practice: test new provisioning configuration in sandbox first.

Errors and retries: retryable errors such as ConnectException and NoRouteToHostException are retried once per hour, up to 3 times.

When a user is granted access on a source where they have no account, SailPoint creates the account using the source’s Create Account definition (Source > Account Management > Create Account). Each attribute has a mapping type:

The built-in Manager identity attribute can be used in Create Account but not in attribute sync. Use a custom identity attribute (for example managerToSync) instead. The BeforeProvisioning rule is generally preferred over editing the provisioning policy by API.

Keeps source account attributes aligned with identity attributes. An attribute is eligible only if it is in the Create Account definition and mapped directly from an identity attribute.

• Applies only to existing, correlated accounts. It never creates accounts.
• If an identity has several accounts on a source, all are updated.
• Applies only where the identity profile has a mapping for the attribute. A null identity value is propagated (null values count as not synchronized).
• Sync button (bulk): only when the source is healthy, and at most 3 times per 24 hours per source. Needed mainly when the configuration is first defined. Afterwards enforcement is real-time per account.
• Triggered automatically by an authoritative aggregation changing an identity attribute, an aggregation detecting a native account change, or an account being moved to another identity.
• On failure, the request is requeued and retried up to 10 times. Admins can resync individuals or the whole source.
• Do not sync attributes changed by rules or other logic, or you can create endless loops. Safeguards exist for values that are logically equal but textually different (spaces, nulls, boolean forms).
• Multi-value sync needs custom rules.

Defined per identity profile. New profiles automatically include pre-hire, active, leave of absence, terminated and archived. Lifecycle states are disabled by default and must be enabled before identities can enter them. The Lifecycle State attribute must be mapped to use them, and the technical name is the value the attribute must contain.

A state can:

• Remove all access (enabled by default for the out-of-the-box Terminated and Archived states).
• Enable, disable or delete source accounts (Settings for Previous Accounts): No sources, All sources (new sources are included automatically, and delete is not available), or Specific sources. A source can be used for only one operation per state. Delete is only configurable when the identity state is Inactive (long-term), and deleted accounts cannot be restored.
• Grant access profiles. These are excluded from “Remove all access”, are enforced while the identity stays in the state (removed ones are re-provisioned), and are revoked when the identity leaves the state unless the new state also grants them.
• Send email notifications to the manager, all admins, or specific users.

A source is not disabled or deleted if it contains an access profile listed on the state’s Access Profiles tab. Birthright role access also survives “Remove all access”.

Display order of states is controlled with the Update lifecycle state API (priority). Recalculation happens in event-driven and scheduled processing.

• Tasks page (Admin > Dashboard > Tasks): manual tasks. Actions include Reassign and Mark as Complete.
• Provisioning Activity report (Search > Reports).
• Account Activity tab (Admin > Identity Management > Activities): last 60 days.

Uses workflows to let non-privileged users run privileged tasks safely.

• Needs a Privileged Action Gateway cluster component on a VA cluster, privileged credentials stored in Parameter Storage or a Credential Provider, and the target application.
• Credentials are encrypted and never visible to the workflow admin or the user.
• Workflows can run without interaction (any normal trigger) or with interaction (must start with the Interactive Trigger).
• The Interactive Trigger creates a launcher (same name and description as the workflow) and an entitlement is created automatically. Assign it, or let users request it, and the user runs it from the Launchpad.
• The workflow must be enabled for the launcher to work. Interactive Form collects input. Interactive Message shows progress.

Admin tasks to configure requests:

• Choose which roles, access profiles and entitlements are requestable.
• Optionally require a form for an item.
• Set each item’s approval process. Roles and access profiles are set individually. Entitlements use a global configuration with optional per-entitlement overrides.
• Define segments to restrict who can request which items.
• Decide whether users can request for others.
• Decide whether users can request for machine identities (needs Machine Identity Security and Agent Identity Security).
• Set global reminders and escalations.

Flow:

• Users submit requests. Everyone can request for themselves. Some can request for others or for machine identities.
• Reviewers approve or deny (if approval is required).
• If approved, the item is provisioned. For a JIT request it is only assigned and the user activates it from Launchpad > Just-In-Time Access. If a start date was set (non-JIT), provisioning happens on that date, otherwise immediately.
• If an expiration date was set, revocation starts on schedule. A connected source deprovisions automatically. A non-connected source gets a manual task for the source owner.

Details worth memorizing:

• The expiration date is not sent to the source as an account attribute.
• API requests (Submit an Access Request) can include a time component in removeDate.
• Requests not fully approved after 90 days are automatically denied and expired by default. You can shorten this and can make expired requests auto-approve with the timeoutConfig attribute (Update approvals configuration endpoint).
• On the Approvals page, reviewers see the identity’s name, email, manager and identity state. You can add up to 5 more attributes with the Update Public Identity Config endpoint (the same applies to certifications).
• Items in a request can be individually provisioned or canceled without affecting other items.

Roles and access profiles (item > Access Requests tab): Allow Access Requests, Require Access Request Form (a form automatically includes start date, end date and comments), Require End Date (optional maximum duration in hours, days, weeks or months, counted from the request time and therefore including approval time), Require Approval with Reviewer (individual or governance group) or Workflow. Without Require Approval, the global approval configuration still applies.

Role reviewer options include: All Owners (primary or any additional owner can approve), Primary Owner, and others such as manager, identity, governance group.

Entitlements: enable globally at Admin > Global > System Settings > Feature Settings > Access Request > Enable Entitlement Requests. Entitlement reviewer types are Entitlement Owner, Source Owner, Manager, Governance Group (only one member of a governance group must approve). Multiple reviewers form an ordered chain. If entitlement requests are disabled, removal requests are also disabled. To allow revocation without requests, enable the feature but make no entitlement requestable. Enable Machine Identity Access Requests is on by default.

Requests for others: Feature Settings > Access Requests > Enable Requests on Behalf of others, then By Managers for their Team (direct reports only) or By Everyone for Anyone.

Path: Admin > Global > System Settings > Feature Settings > Approval Settings. Tabs: Global, Access Requests, Entitlement Descriptions, Agent Requests.

Precedence (important):

• Settings on an individual access item override global settings. Workflows override global settings as well.
• If you turn off reminders, escalations or timeouts on an individual item, none occur, even if configured globally.
• Changes apply only to requests created after the change. Pending requests keep the old configuration.
• After timeout, no reminders or escalations happen.

• Access request policies: Admin > Policy Center > Administration > Access Request. Admins and Access Request Administrators can create them.
• Every submitted request is evaluated. If several policies match, all are evaluated and the most restrictive decision is returned.
• Policy decisions generally override static configuration, unless a matching policy is set to honor the existing configuration.
• Not applied to bundled provisioning requests, dynamic role requests, tenants with approvals globally disabled, or ServiceNow plugin requests.

• A segment is a group of identities defined by identity attributes. Add access items to it so only members can see and request them.
• Users see items in their segment plus items in no segment (requestable by anyone).
• An identity can be in up to 100 segments. Changes can take about 20 minutes to apply.
• Segments use identity attributes mapped in identity profiles. For other data, create an attribute mapped to the value you need.

Path: Admin > Dashboard > Approval Management. Manage Access Requests, Entitlement Descriptions, Privilege Classification, Account Requests and Other Approvals. Admin actions: View Details, Reassign, Remind User, Cancel Request.

• Statuses: Pending, Partial Provisioning, Failed, Error, Canceled, Denied, Completed.
• Search by Access Request IDs (comma-separated allowed, 350 character limit). This is the only search bar that accepts comma-separated values.
• If an approval requires reauthentication, you reauthenticate through your SSO provider.

A certification campaign is a set of reviews. Each assigned review is a certification. Certifiers approve or revoke, then sign off. SailPoint remediates revoked access and an admin completes the campaign.

What is certifiable:

• Roles: all can appear. Roles obtained by request can be approved or revoked. Roles assigned by automatic criteria can only be acknowledged. To remove one, change the criteria or the identity data.
• Access profiles: certifiable if obtained by request or detection. Profiles granted by a lifecycle state do not appear at all. Profiles granted through a role are encapsulated in the role.
• Entitlements: certified individually only if not inside the user’s access profiles or roles.
• User levels granted to identities appear in certifications as entitlements.

Self-certification prevention: a user’s own access is split into a separate certification. It goes to the manager, else the campaign owner, else a random administrator. Manual reassignment is blocked if the certification contains the new owner’s access.

Remediation:

• Automated: direct connection that can provision. Immediate.
• Manual: otherwise a task goes to the source owner.
• Revocations not signed off are not applied. At completion, unsigned items are treated as undecided.

Next-generation vs legacy campaigns: the new certification engine is being rolled out. Use legacy campaigns for campaigns started before migration and for role composition campaigns.

Manager or source owner campaign: Admin > Certifications > Campaigns > Create New. Who: Cert Admin or Org Admin.

Preview then start: after Preview Campaign, check reviewers and counts. Start within a day of generating the preview or delete and recreate. If the due date has passed, you cannot start it. Empty campaigns produce no preview. A “could not be generated” error means delete and restart.

Campaigns from Search can certify identities, access items and role compositions.

Completing: after the deadline, options are Complete (maintain), Complete and Revoke (if configured), or wait for reviewers. If a manager made decisions but did not sign off, decisions are preserved. Maintaining access is strongly recommended because revoked access is hard to reinstate. After completion, verify remediation: it is always required if a campaign is complete or overdue and at least one revoke was selected, or the admin revoked undecided items. Aggregate or re-import the flat file to confirm.

Reassigning: possible only before the reviewer signs off. The system validates that nobody reviews their own access. Use Search > Certification Campaigns > Cards view, or work reassignment (Module 7).

SoD finds and prevents conflicting access held by one human identity.

Policy structure: two lists of access (List A and List B). A violation occurs when an identity has access in both lists. Lists hold entitlements, roles and access profiles.

Limits: up to 500 total policies per org and up to 50 access items per list (at least 1 per list).

Policy fields: name, description, optional external reference and tags, enable toggle, Policy Owner (individual or governance group, plus up to 10 co-owners), Violation Owner (individual, manager, governance group or none; with none, the Violation Admin handles it), optional mitigating controls, mitigation and remediation advice, Access Requests setting, and Level (Critical, High, Medium, Low).

• Block submission: conflicting access requests are automatically canceled.
• Allow submission: conflicting requests go to configured approvers.
• Global prevention (Feature Settings > Access Requests > SoD Conflicts): block all ISC requests with SoD conflicts, and optionally all SAP ARM requests, regardless of individual policy settings.

Handling violations: Admin > SoD Policies > Policy Violations. Viewable by Admins, SoD Violations Admins and SoD Compliance Officers. Violations inherit the policy’s risk level. Filters: policy, identity, owner, level, plus quick filters All, Open, Mitigated. Admins and SoD Violations Admins mitigate violations. Admins and SoD Policy Admins manage policies. Audit events record SoD policy create, update and delete. The SoD Violation Opened event trigger can drive custom notifications.

Provides consistent password policy enforcement and simultaneous password changes across sources and apps.

• Prerequisite: access applications for the systems whose passwords users may reset.
• Password policies: Admin > Password Mgmt > Policies. Contains requirements, optional password dictionary, AD-only expiration and reminders, and when to require MFA before changing a password. If the MFA setting is left empty, users can reset passwords without extra authentication.
• Sources use the default policy unless explicitly associated with another. Flat file sources are not compatible with password management. A policy must not conflict with the source’s own password requirements.
• Sync groups: Admin > Password Mgmt > Sync Groups. Need at least two direct connect sources configured for password management, each with at least one access application, and at least one policy. The policy must suit all member sources. Exceptions cannot be used for sources in a sync group.
• Users change passwords as: password groups (admin-defined sync groups), multi-application sources (changing one changes all access apps on that source), or standalone access applications.

User levels grant permissions within SailPoint. Users can hold several and get the combined access. Only Admins grant or remove them, unless you enable Enable Non-Org Admins to Manage ISC User-Level Entitlements (Feature Settings > Other Features) for Role Admins and Source Admins. The setting is off by default and adds risk. Granted user levels appear in certifications as entitlements.

Other families exist for Access Intelligence, Data Access Security, CIEM, Configuration Hub (Config Hub Administrator, Backup Administrator, Reader) and Access Request Administration.

Combinations that cannot be assigned together: Role Admin + Source Sub-Admin, Role Sub-Admin + Source Admin, Role Sub-Admin + Role Admin, Source Sub-Admin + Source Admin, Source Admin + Source Configuration Assignee. Best practice: do not combine Org Admin with other elevated levels. Custom user levels and custom user level matrices are also available.

• Governance group: Admin > Identities > Governance Groups. Has a name, description and owner. Can review requests and certifications, own access items, and oversee sources. When it is the group’s turn, every member sees the task, and one decision completes it for access request reviews.
• Work reassignment: must be enabled (Feature Settings > Other Features > Enable Work Reassignment). Redirects access request reviews, certifications and manual provisioning tasks, temporarily (out of office) or permanently (executives, service identities). Users can set their own, managers can set them for team members, and admins for anyone. Applies automatically when work is created.

• Record-level security that scopes non-Org Admin users to specific entitlements, roles and identities, enabling delegated administration with least privilege.
• Pair with user levels: user levels govern permissions, segments govern records.
• Transitive property: a user may see that an object outside their segment exists (referenced by an object inside) but not its details.
• With segmentation on, identity reports can only be run, viewed or downloaded by Org Admins. Not supported in the Access Intelligence Center or event search.
• API keys fail for searching roles, entitlements or identities when segmentation is on, because they are not tied to a person. Use personal access tokens instead.

• API keys: Admin > Global > Security Settings > API Management. A client ID and secret with an OAuth 2.0 grant type. Set as Public clients have no secret and cannot use Client Credentials. VA keys are system-generated.
• Personal access tokens tie access to a person.
• Parameter Storage: a SailPoint-managed secure repository for secrets (Admin > Global > Parameter Storage). Categories include Authentication (Credential, Azure Entra ID Client, HTTP Custom Authorization, OAuth 2.0 Client Credentials Grant), among others. It reduces repeated entry and human error.

• Search finds identities, entitlements, roles, access profiles, events and more. It also hosts saved searches, certification campaigns, policies and audit reports.
• Syntax: field:term. No spaces in the field part or after the colon. Searches are case-insensitive. Use .exact for case-sensitive matches.
• Quotes: double quotes keep a phrase together. Unquoted spaces and single quotes are treated as OR. A query without a field searches all categories.
• Second-level fields: secondLevelField.firstLevelField:term, for example attributes.location:“sao paulo”.
• Examples: displayName:john.smith, created:2018-06-01, status:ACTIVE.
• Saved searches: visible only to the creator. Each unique query can be saved once.
• Natural language search: Admin > Global > System Settings > Feature Settings > GenAI. English only, experimental, and unavailable in certain regions (us-gov-west-1, sa-east-1, me-central-1). Always verify the generated query.
• Harbor Pilot can also help start queries.
• Customizable identity attributes can be used as query filters automatically (this is separate from the correlation “searchable” setting).

• Nearly all activity is audited. Audit data is kept 1 year plus the current month. Older data (up to 5 years) requires the Audit History Request Form with a support ticket.
• Default audit reports in Search: All Events, Access Request Activity, Authentication Activity, Password Changes, Provisioning Activity, All Source Activity (Non-Provisioning).
• Other reports live at Admin > Global > Reports (for example Uncorrelated Accounts and Identities Without Managers).
• Admin Dashboard: Monitor (active jobs), Tasks, Approval Management, system components (Clusters tile).
• System health notifications and source health, VA health emails can be configured.

• A workflow performs a series of steps whenever a trigger fires. It is stored as JSON but mostly built in the UI (visual builder or JSON editor).
• Required: exactly one trigger and at least one action. Operators direct flow (choice and comparison steps such as Compare Strings, Compare Numbers, and the Success and Failure end steps).
• Data flow: the trigger supplies the initial JSON input. Steps add JSON. Reference values with JSONPath (use the Variable Selector).
• Permissions: configuring workflows requires Org Admin. Workflows Read Only can view configurations only. Workflow Audit Read Only can view configurations and execution history.
• Limits: after first enabling, allow up to 2 hours before the feature is fully working. Fastest rate is 400,000 executions per day, after which executions continue at 5 per second. The quota resets every 24 hours.
• Examples: triggers (Account Aggregation Completed, Identity Created, Source Deleted), actions (Create Campaign, Get Identity, Send Email).
• Interactive process: starts with the Interactive Trigger, uses Interactive Form and Interactive Message actions, and is launched from Launchpad (see Module 5.6).
• Workflows can serve as approval processes for access items and override global approval settings.

Event triggers send event payloads to webhooks or custom apps (example: notify a third-party system when an identity is removed). Path: Admin > Event Triggers. Early Access triggers must be requested before they appear.

Trigger details shown: Trigger Name, Trigger ID, Description, Type, Input Schema (what SailPoint sends, with example), Output Schema (what SailPoint expects back for Response Required triggers, with example).

Types: Fire and Forget (no response needed) and Response Required.

Subscription limits: up to 50 subscriptions per Fire and Forget trigger and only 1 per Response Required trigger.

Creating a subscription: Admin > Event Triggers > + Subscribe. Enter a unique Subscription Name and description, then:

Optional Filter: a JSON XPath expression limiting when the trigger fires. Use the Enabled/Disabled toggle, then Save. Configure the webhook side first.

Subscriptions page: toggle enable, Edit, Delete, Activity Log (per trigger), Test Subscription (mock data). The global Activity Log keeps successful executions at least 24 hours and failed ones at least 48 hours, showing a maximum of 2,000 executions.

• Backs up and deploys configuration objects (sources, identity profiles and others) between tenants or restores after errors. It is not a full system backup.
• Source tenant = where the backup comes from. Target tenant = where you deploy or compare (often production).
• Backups: up to 10 manual backups per tenant. Backups and drafts hold up to 5,000 objects (Support can raise this). Case-sensitive object names can limit scope. Secrets and credentials are not backed up, so re-enter them after deploying sources.
• Components: Backups, Drafts, Uploads, Activity Log, Tenant Connections, Advanced Settings, Cloud Storage, Mapping Objects, Scheduled Jobs.
• User levels: Config Hub Administrator (everything including cloud storage), Backup Administrator (backups and tenant connections), Reader (read-only).

• Email templates exist for nearly every event (access requests, approvals, certifications, JIT, lifecycle changes, password events, VA health, SoD, work reassignment and more). You can use and customize them, and set a custom From address. Test templates before starting campaigns.
• Certification Due emails repeat weekly until completion.
• Customizing the UI and Time Zone Settings are tenant-level settings (the tenant time zone drives scheduled processing at 8 AM and 8 PM).
• Secure Data Sharing, Slack, Gov for Slack and Microsoft Teams integrations let people act on governance tasks from collaboration tools.

• Reserved IP ranges: 10.255.255.241/28 breaks routing for any source inside it, in every configuration. 172.16.0.0/22 breaks routing for network tunnel configurations only.
• With the HTTP proxy option in a cloud environment, allow the required URLs but avoid connectivity to the cloud metadata API (typically 169.254.169.254).
• TLS: select Use Transport Layer Security (TLS) in the source setup and the certificate is copied to the VA cluster automatically. Active Directory has TLS checkboxes for Forest, Domain, IQ Service and Exchange.
• FIPS (FedRAMP): configured on each VA at the Linux kernel level. It cannot be reversed or disabled. To leave FIPS mode you must create new VAs from a fresh image.
• hosts.yaml: lives in /home/sailpoint/. Spacing must be exact (2 spaces before the IP address, 4 spaces then a dash and a space before each host name: fully qualified name first, then short name). Restart the charon service afterwards.

• Start the VA image and sign in as the default sailpoint user. Change the default password immediately.
• Set the key passphrase (va-bootstrap set-passphrase). It must be identical on every VA in the cluster, cannot start with a special character, and cannot contain spaces, ! or /. It is stored encrypted (shown with leading colons).
• Request a pairing code (va-bootstrap pair). Enter it in the UI within 4 hours and select Pair.
• Wait about 30 minutes. The VA Status changes to Connected when configuration finishes.

For proxy deployments, the same two commands take the http-proxy and https-proxy options. A new VA can be saved to the cluster without pairing, but it is not operational until paired.

• Target systems have their own port requirements. VAs must be allowed to reach them.
• Local NTP: edit /etc/systemd/timesyncd.conf, remove the # before the NTP line and add server names (several allowed, space separated), restart systemd-timesyncd, then check with timedatectl status. Each VA is configured individually.
• VAs can be configured to trust a private root CA for deep packet inspection environments.

If a VA misses an update you agree to cooperate with SailPoint to bring it current. Falling behind risks loss of support (only N-2 major releases are supported).

• Opting out of automatic updates requires your organization to sign an addendum accepting increased liability. Contact your Customer Success Manager. SailPoint still recommends automatic updates.
• Set it per cluster: cluster card Menu > Update Settings > Manual, then use Apply Updates on the card.
• Status labels: Critical Update (apply immediately) and Out of Support (fallen behind more than 2 update versions).
• Support covers N-2 major releases using {Major}.{Minor} numbering. Example: if the current release is 4.5, versions 4.0 to 4.5, 3.x and 2.x are supported and anything in version 1 is not.
• Any update labeled a security fix must be applied immediately. If not, you lose eligibility for support, warranty and indemnity for a preventable incident.
• Email templates exist for Virtual Appliance Updates Available and Updates Failed.

• Default VA OS is Flatcar Linux. Installing your own OS also requires a legal addendum.
• Supported families: RHEL, CentOS and Rocky Linux 8.x, 9.x, 10.x; Ubuntu 22.04, 24.04, 26.04 LTS; Amazon Linux AL2 and AL2023; SUSE Linux Enterprise Server 15 and 16; Oracle Linux 9 (CIS Level 1).
• Custom partitions must be at least: /var/lib/docker 40 GB, /opt/sailpoint 20 GB, /home/sailpoint 60 GB.
• The installer is a bash script, sp-va-install, with the bootstrap docker images appended (charon, va_agent, canal, toolbox). After bootstrap, the VA pulls remaining images and updates from ECR just as on Flatcar.
• You own OS setup, maintenance and patching. A VA rebuild is the usual troubleshooting answer. Recommended: CIS hardening, patch at least weekly (or on critical patches), vulnerability scans at least daily.

• Metrics: an OpenTelemetry agent (otel_agent) exports to any OTLP-compatible tool. Set the endpoint and API key in otel.env (in /home/sailpoint), start with systemctl, and check /home/sailpoint/log/otel_agent.log. If you set no values, metrics go to your SailPoint tenant instead.
• Available metrics include CPU load averages (1, 5, 15 minutes), file system usage (free, reserved, used) and an uptime gauge.
• Logs: create host-logging.yaml in /home/sailpoint. Supported destinations include Splunk HEC, CloudWatch Logs and Datadog.
• In otel.env the API key line must hold only the key. Extra text such as an Authorization header prefix breaks the export.

• Some connectors ship with default datasets and resources (examples listed: Microsoft Entra SaaS, n8n SaaS, n8n VA). Use the default schemas unless you must change an attribute.
• Scheduled dataset aggregation runs every 12 hours. A manual run is also available.
• Remove Objects removes aggregated objects only from SailPoint. They are not removed from the source, so they come back on the next aggregation unless you also remove them there. Removal and aggregation cannot run at the same time.
• Delete a dataset’s resources before deleting the dataset to avoid orphaned resources.
• Add all attributes before the first aggregation. Editing Resource ID or Resource Name afterward can create duplicate non-human identities. Attribute names are limited to 128 characters.
• Owner correlation: if it is not configured or matches nothing, no owner is assigned. Optionally sync the primary owner mapping to machine accounts.

• Supported examples include Microsoft Dynamics 365 (Business Central Online, CRM, Finance and Operations) and SAP S/4HANA Cloud. You need the Admin or Source Admin user level.
• You work on a draft copy while the live source keeps running. Settings and the account schema carry over, but you re-enter secrets (client secret, password, refresh token, certificates).
• Do not edit the live source during migration. Those changes are overwritten when you publish the draft.
• Account and entitlement previews do not affect the live source. Apply Migration is permanent and cannot be reverted.

• Discovered apps show a risk score out of 100. You can schedule recurring discovery aggregations under Additional Settings > Discovery Settings.
• Manual discovery limits per day, per source: Org Admins get 3 (cumulative across all org admins). Regular users get 1.
• Source recommendations use AI for account correlation, account provisioning and app discovery. You must first connect and aggregate an authoritative source. Recommendations depend on data quality.
• New identities take 12 to 24 hours to be considered for correlation recommendations. New accounts take 12 to 24 hours for provisioning recommendations. The attribute sync preview data lake can lag the real system by 3 to 6 hours.
• You can dismiss recommendations and give feedback. A flat file source lets you Review and Import Accounts (a CSV) so recommendations work, without aggregating them yet.

Assigned applications: an admin can assign a source configuration to a Source Configuration Assignee.

• The assignee configures the source setup, account schema and entitlement types (when available), then selects Submit for Review. The assigning admin or an org admin reviews before the source is enabled.
• The due date is informational only. Passing it does not remove access.
• Assignees see Attribute Sync as read-only (only admins edit it) and Entitlements as read-only. Reassigning a source removes your access, and the user level too if no other sources remain.
• You cannot assign a source type like Web Services to an assignee.

• An access application is a logical grouping inside SailPoint that gives access familiar names (for example Expense, backed by Active Directory groups). It is required for password management. Name limit: 128 characters.
• Set App Accounts Created By to Admin (IT). The Users option applied only to legacy single sign-on.
• Account Source: Specific Users from Source (based on access profiles assigned) or All Users from Source. The primary application for a source normally uses All Users.
• For requests: select Visible in Request Center and Allow Access Requests, then add access profiles. Hiding an app overrides those two settings.
• Icon: PNG, JPG or SVG, under 5 MB, 1:1 ratio.
• Adding or removing an access profile triggers an identity refresh that cannot be stopped or delayed.
• If access profiles limit who can reset passwords, update the users’ password management applications after changing the list.

• Create or edit the app in the SSO provider and assign it to an entitlement or group. (The Okta integration needs a SailPoint Human Fabric for Okta license.)
• In SailPoint, create a source for the SSO provider, aggregate accounts at least once, and resolve uncorrelated accounts (uncorrelated accounts cannot be governed).
• Import entitlements and run a full entitlement aggregation.
• Create access profiles so every app entitlement belongs to at least one. Do not enable lifecycle states or roles at this stage.
• Create the access application (Admin (IT), Specific Users from Source, choose the SSO source and the access profile), then Enable For Users.
• Afterward you can enable lifecycle states and roles. Governance changes are enforced on the SSO provider.
• Revoking an SSO-app access profile or entitlement in a certification removes the app from the user in the SSO provider.
• Password policies in SailPoint must not be more complex than the SSO provider’s, or users could succeed in the SSO provider and fail in SailPoint.
• If the SSO source does not create the app account, make a second requestable access profile and access application for the account source.

• A launcher starts an interactive process manually. It is created on the Launchers page or by the Interactive Trigger in a workflow.
• One launcher triggers one workflow, but one workflow can have several launchers. Only workflows with an Interactive Trigger can be attached.
• Renaming a launcher does not rename the workflow or entitlement. The workflow must be enabled for the launcher to run (applies to Privileged Task Automation).

• Under Additional Settings you can generate connector logs for a range of 24 hours or less within the last 90 days (presets: last 1, 6 or 24 hours).
• After a failed test, aggregation or provisioning, search near the failure time for ERROR, Exception and HTTP or LDAP codes. Use the inner message, not the generic UI error, to find the fix.

• Prerequisite: every user from the IdP needs an identity with matching data, unless you configure just-in-time account creation.
• Leave Enable Remote Identity Provider unchecked until the IdP settings and signing certificate are correct. The Entity ID must exactly match the IdP’s SAML metadata EntityID. The certificate must be PEM format. If you choose a custom identity attribute for the SAML request it must be searchable.
• Sessions authenticated through an IdP expire after 90 days. SAML Single Logout (SLO) is not supported. FedRAMP organizations must encrypt SAML assertions.
• Bypass: by default users can launch the product only after signing in at the IdP. Admins use emergency access accounts to bypass SSO.
• JIT account creation (SAML Just-in-Time Provisioning source) creates an account the first time an unknown user authenticates. This is different from Privilege on Demand (JIT access).
• JIT source: attributes email, firstName, lastName are always required, and id is automatically mapped to the SAML nameId. Those default attributes (id, firstName, lastName, email) cannot be deleted. Custom attribute names must be camel case, and Multi-Valued and Entitlement options are not supported.
• In the identity profile, only uid to id is mapped by default. Map other attributes yourself. The account is usually ready within about 15 seconds.
• If an IdP attribute used in correlation changes, SailPoint may treat the user as a new identity instead of updating the existing one.

• Two-factor rules: enable at least two reset and unlock methods. Default methods come first and MFA integrations (RSA, SafeNet, Duo) come second. If security questions are among the defaults they are the first step.
• SailPoint recommends using two-factor authentication and phone masking together.

• Answers must be at least 4 characters. Enable 2 to 8 questions. You may require users to answer correctly up to 6 (only if 6 or more are enabled).
• Questions cannot be edited. Delete and re-add. Deleting a deployed question forces affected users to answer a replacement, and old answers are not remembered even if you re-add the same question.
• PIN option: set both required counts to 1. It removes security questions. A PIN is 4 to 255 alphanumeric characters. Notify users first.

• Set as Public disables the Client Credentials grant type and gives the client no secret.
• With no scopes selected, the default scope grants only endpoints that need no authorization. Use least privilege. If an endpoint lists no scope, select sp:scopes:all.
• SailPoint Support and Services accounts cannot create API clients through the UI. VA keys are system-generated and removed only by deleting the VA.

• Every tenant starts at CST/CDT. The tenant time zone is the default for many timestamped features and is changed through the API.
• The VA cluster time zone is a GMT offset used for aggregation scheduling and it does not observe daylight saving. Other scheduled items on a DST time zone adjust automatically.

Who can discover, classify and manage machine accounts: Org Admin, Source Admin, or a Source Sub-Admin who is a member of the source’s governance group.

If your organization keeps application data in a database:

• Configure sources that contain machine accounts and aggregate them.
• Create application identities.
• Create account subtypes.
• Set classification criteria.
• Map account attributes (owner, machine identity and so on).
• Process classification and mappings.
• Review and update accounts, then create a machine account certification campaign and certify.

If you do not keep application data: skip application identities at first, map and classify, certify the uncorrelated machine identities, and create application identities afterward.

• Classification is configured per source. Choose Classify all accounts if the source holds only machine accounts, or define custom criteria for mixed sources. Matching is case insensitive by default, with a Case Sensitive checkbox.
• Mappings: Machine Account Owner (if unmapped, no owner), Machine Identity (links to an application identity), Account Subtype (value must match the subtype’s Technical Name), Environment (for example staging or production) and Description.
• SailPoint recommends manual processing only during initial setup or when policies change, because automatic processing handles the rest.
• Declassify by disabling Enable Classification. Accounts return to their original type and correlation.
• The Discovered as Machine filter finds likely machine accounts the policy missed. You can correlate up to 100 accounts at a time to application identities.
• Machine accounts can be correlated only to machine identity types. To delete an application identity whose app was decommissioned, delete its machine accounts first. Account deletion needs a direct connect source that supports it and is not supported on the IdentityNow source.

• Create an application identity: unique Native Identity, a primary owner (human), up to 10 additional owners who take over if the primary becomes inactive, and up to 10 user entitlements (from multiple sources) that grant access to it.
• The same ownership pattern applies to AI agents: primary owner, up to 10 additional owners, up to 10 user entitlements. Access requests for machine identities and agents are enabled by default.
• AI agents can be activated and deactivated (supported for sources such as n8n SaaS). If approval is required, the requester gives a business justification.
• Approval settings for agent requests are under Admin > Global > System Settings > Feature Settings > Approval Settings (activate and deactivate sections). Default reviewer is the source owner. Other reviewers: governance group (only one member must approve), additional owners, all owners. With several reviewers all must approve. One denial denies the request.

• Enabling machine account creation for a subtype creates an entitlement named Create Machine Account - {Source} / {Subtype}. Users must request that entitlement to see the Create Machine Account option. The person who enables creation becomes entitlement owner and must make it requestable.
• Configure approvals and attribute mappings before enabling creation. Generator patterns still cannot reference other Create Account attributes. If no password policy is set, the source’s default policy is used.
• Enable Machine Identity Access Requests (Feature Settings > Access Requests) controls whether users can pick entitlements during account creation. Disabling it still allows account requests, but without entitlement selection.
• Deletion approvals are enabled by default with the source owner as reviewer.

• Agentic Fabric onboarding: connect an identity provider, deploy sensors (endpoint agent and browser extension), connect sources, connect EDR or SIEM platforms, sanction business apps, then review and activate.
• The Non-Human Identity Registry lists agents, applications, accounts, MCP clients, credentials, endpoints and business apps. The Agent Registry has quick filters for recently discovered, unsanctioned and ownerless agents.
• The SailPoint MCP Server is a bridge that lets third-party AI agents use SailPoint tools. It turns agent requests into API calls. For example, an agent can initiate an access request for a user, and for another user only if requests for others are enabled.
• Audit and compliance reports show only data in SailPoint’s platform and are one part of a compliance package.

• Up to 50 non-employee sources per org. Each source defines its own account approval process, so separate populations that need different approvals into separate sources.
• Up to 10 account managers (non-admins) and up to 3 account reviewers per source. Administrators bypass the review when they create accounts on the source’s Accounts page and need not be listed as managers.
• Non-employee sources do not support provisioning. Attribute names cannot contain periods.
• Add every required attribute before creating accounts. If you add required attributes later, you must supply values whenever you edit existing accounts. A required attribute mapped to a correlation identity attribute should be marked required.
• Only store attributes needed for business operations. SailPoint is not responsible for storing sensitive data.

• Features: application onboarding recommendations, Access Insights (Access Intelligence and Identity Outliers), Access Modeling (common access, Role Discovery, Role Insights), Access Recommendations (request and certification), Activity Insights, and GenAI entitlement descriptions.
• Access History is enabled by default. If you use application onboarding no extra setup is needed. Other features need setup by Professional Services.
• AI core attributes: select your 4 most impactful identity attributes from the banner. It can take up to 48 hours to take effect. They drive Access Request and Certification Recommendations.

• Dashboards and sheets built in an embedded analytics tool (served from qlikcloud.com). Standard user levels need Admin or Report Admin to read, create or modify data. Custom user levels can grant AIC Reader or AIC Author separately.
• The AIC Audit dashboard holds the last 3 months or 5 million events. Data changes can take up to 24 hours to appear. There is a 5 GB total size limit in the application.
• Browser needs third-party cookies enabled. Safari is not supported. Strict firewalls must allow cdn.qlikcloud.com on port 443. Unlicensed apps appear disabled.
• The Non-Employee Risk Management dashboard needs the person and assignment account attributes synchronized to AIC. Data segmentation is not supported in AIC.

• Requires Access Insights. Launching certifications from outliers also needs Certifications. Account data must be onboarded into AI-Driven Identity Security. Available only in AWS regions that support the SageMaker LLM SailPoint uses (me-central-1 is among the unsupported ones).
• Path: Admin > Identity Management > Outliers. Each outlier has a score from 0 to 100 (higher is riskier). The dashboard shows 30-day trends.
• Score factors: Standalone Entitlements (not in an access profile or role), Rare Access (share of entitlements held by under 1% of identities), and Roles with a Single Entitlement. Extremely Rare means the 10 rarest entitlements (ties can push the count above 10).
• Ignore an outlier and it will not return unless its entitlements change significantly.
• Remediate by starting a certification campaign for outliers. Limit: 1,000 outliers per campaign.

• Uses peer group analysis and identity attributes. Request recommendations show each user their top 15 items in the Request Center Recommended tab and on a login banner.
• It filters out access that is too common, too rare, or not requestable. Joiners (new to the organization) see broader role and access profile suggestions. Dismissed recommendations do not return.
• Recommendation attributes are changed by Professional Services. Without AI core attributes, recommendations are restricted by the location identity attribute. With AI core attributes that restriction is disabled by default.
• Changing an item to non-requestable may leave it recommended until overnight processing. Requesting it meanwhile is blocked with an error.
• Roles marked Common Access are omitted from request recommendations. Certification recommendations help certifiers approve or revoke.

• Connector-based usage data (examples: Atlassian, Box, Delinea Secret Server Cloud, Dropbox, Duo, Microsoft Entra ID, MongoDB Atlas, Okta, Oracle Fusion HCM, Salesforce, ServiceNow, SharePoint Online, Slack, Snowflake, Zendesk, Zoom).
• Uses a 90-day window: Access Modeling shows the percentage of identities that used a source in 90 days, and Certifications show days active in 90 days to inform keep or revoke decisions.
• It supports analysis of access usage. It is not a proxy for employee performance.

• Privilege on Demand (JIT access): access is authorized ahead of time and provisioned only when the user activates it from Launchpad > Just-In-Time Access. Removal happens on expiry, deactivation or revocation.
• Only entitlements on direct-connect sources can be configured for JIT.
• Global settings: Maximum Activation Duration (initial limit, extendable), Default Activation Duration, Maximum Extension Duration, Default Extension Duration. New limits affect future activations only.
• Policies: activation policies and duration policies evaluate identity context and entitlement metadata to allow or deny, add friction and set durations. ServiceNow integration is available.
• Notification: 15 minutes before an activation ends. The monitoring page shows activations from the last 13 months (use Search for older).

The Identity Graph widget ignores data segmentation. Anyone who can see it can see all access objects and identities.

• Email configuration error: the profile invites only to an alternate email but the user has none.
• Authentication source mismatch: the profile uses pass-through authentication but the identity has no account on that directory source. Correlate an account or change the sign-in method.
• Provisioning issue: if an identity has more than one account on a source where provisioning triggers, an error occurs and nothing is provisioned because SailPoint cannot tell which account to change.
• The identity list search matches values that begin with your term across account ID, username, display name, email, first name and last name.

• The control panel lets you pin attributes (default ones cannot be unpinned), see access, view the Events tab (logins, password changes, where the identity is actor or target) and the Ownership tab (machine accounts, AI agents and application identities the person is responsible for).
• A role can be revoked from the panel only if it was provisioned through an access request.

• Shows a timeline of access changes for active and deleted identities, useful for audit. Blue timeline nodes mean changes occurred. You can compare access between two dates.
• A governance event links to an access change only if the change happened within 30 days. If several access changes match, the closest in date is linked. Generic approval events are not shown because they are task-based.
• Recently created tenants may lack governance timeline history. Access History is enabled by default.

• Visualizes identities, access items and relationships to support audit and compliance. Needs Org Admin, Identity Graph Admin or Identity Graph Read Only.
• Changes to access objects can take up to 6 hours to appear.
• Tools: drag, expand (plus icon, Expand All, Expand Next Layer), lock nodes, minimap, and a data table view. Snapshots can be private or shared with all users. Export the graph as JSON (visible objects) or filtered data as CSV.
• The Accounts view flags dormant accounts: never used, or no activity in the past 30 days. You can enable or disable an account from there.

• Once segmentation is enabled, objects and users in a segment are invisible to people not assigned to it. Org Admins remain the exception and see everything.
• Define three things: users, objects and identities. Users can be All Users, Select Users (static list, maximum 50), or Build Criteria (dynamic, maximum 10 criteria, And/Or logic).
• Objects: select up to 50 roles or entitlements. Include Unsegmented adds entitlements that belong to no other segment.
• Do not confuse data segments (what administrators can see) with access request segments (what requesters can see).

• A generative AI assistant. You must opt in. Admins first, and a separate setting (Feature Settings > GenAI) enables it for end users as well.
• It can help search documentation, build queries, create and manage access requests (forms must be completed in the canvas) and create new workflows, but it does not edit existing workflows. Always review generated workflows before enabling.
• Tested for English only. Unavailable in AWS regions that do not support the Bedrock LLM (me-central-1 is listed). It can make mistakes.

• A form is made of sections and fields. Every form must start with a section and all fields sit inside sections. Field types: date, select, text, text area, toggle, plus email, phone, image, description and column set elements.
• Used as a workflow action (suspends the workflow until submitted or timed out), as the Form Submitted trigger, and in access requests (a form can be required for a role, access profile or entitlement).
• Every field has a label (max 255 characters) and a technical key (autogenerated camel case). Keep the same technical key across fields that serve the same purpose so the workflow reads one variable.
• Limits: form size including responses 400 KB. Image fields: .jpg, .jpeg or .png under 2 MB, one image each, 10 image fields per form. Up to 20 form inputs. Text area up to 20 rows. Select lists show 250 results at a time. The Forms widget holds up to 10 forms.
• Conditions: a rule (comparison) and an effect (change to a form element). Up to 20 rules and 20 effects per condition. If effects contradict, the last listed wins. If a rule is not met, the contrary effect applies. Any/All toggle decides when effects apply.
• An Interactive Form action works only in a workflow that starts with the Interactive Trigger, or validation fails and the workflow cannot be enabled.
• You cannot delete a form that a workflow uses. A form assigned to a user is reachable only through the emailed link (after sign-in).

• Two policy types: the Approval Policy (for access objects, using the Access Request Submitted trigger and the Approval Policy action, then choose the workflow as the Approval Type on the item) and the Generic Approval Policy (task-based, any trigger, using the Generic Approval Policy action with a name and description shown on the reviewer’s card).
• Policies can send reminders and time out. On timeout you choose Approve or Expire.
• Pre-built workflow templates exist but must be configured. A workflow-based approval overrides global approval settings.

• Requires approvers of sensitive access to provide a comment and reauthenticate through SSO. The decision is recorded as an authenticated approval.
• Prerequisites: SSO enabled on the tenant, and reauthorizationEnabled turned on through the Update Access Request Configuration API. Then enable it per access item.

• Definition limits: workflow definition 400 KB, definition plus input 1.5 MB, payload 10 MB. Trigger filters allow at most 5 conditions. Build with an admin account that will not expire.
• Edit rules: a workflow must be disabled before editing. The owner cannot change while enabled. Executions are visible for 90 days.
• Rate limits: tenant-wide about 400K executions per day at full speed (loop executions excluded), then 5 per second. Per workflow: a warning at 100K total executions, and at 150K an email is sent and remaining executions are blocked.
• Step wiring: every step must connect to another. Each branch must merge back or end in a Success or Failure step.
• Duplicating a workflow: download the script and delete any secret references before uploading. A template creates a workflow independent of the template.
• Trigger categories (examples): Access Request Decision and Submitted, Account Aggregation Completed, Account Inactivity Detected, Certification, Form Submitted, Identity, Interactive, Outlier Detected, Provisioning Completed, Scheduled Search, Scheduled, External, Source, VA Cluster Status Change, Native Change Account, Machine Identity, CIEM, CAEP and Intel Response Actions triggers.
• Operators: Compare Boolean, Numbers, Strings and Timestamps; Define Variable and Update Variable; Loop, Serial Loop and Break Loop; Verify Data Type; Success and Failure end steps.

• Connect your cloud providers (AWS, Azure, GCP and Okta are supported) and mark cloud-enabled entitlement types. SailPoint then shows the effective access that accounts of human identities have to cloud resources.
• Non-admin users need the Cloud Gov User permission to view and approve CIEM entitlements.
• In the effective access view you can see resources, privileges, access level, history and cloud tags. For AWS you can inspect Assumable Roles (including role chaining) and View Access Paths.
• Yes in the Cloud Enabled column with a “no effective access” message means the entitlement grants cloud access but the user has no cloud resources.
• If a cloud-enabled entitlement appears in a certification, certifiers can see the cloud details when deciding.

• Lets SailPoint exchange security events in near real time with other security components. A transmitter broadcasts events, a receiver receives and acts on them, and a stream carries them. Events follow CAEP.
• The receiver configured in SailPoint correlates events with identity data. Admins build workflows that trigger on received signals (CAEP Event Triggers and templates are provided).
• SailPoint can act as a receiver (Managing Receivers) and a transmitter (Managing Transmitter Streams).

• Gives security analysts identity context during triage: the identity behind an alert, its correlated accounts (including disabled and locked state) and its access.
• Response actions (disable an identity or an account) are submitted through the response actions API with a source context such as CrowdStrike, Microsoft Sentinel, Splunk or a custom integration. Status moves Submitted > In Progress > Completed or Failed.
• The pre-built workflow template uses the Intel Response Actions trigger. It disables the selected accounts, or all accounts of the selected human identity.
• SIEM and SOAR tools call the Intelligence API to enrich alerts. A CrowdStrike Foundry integration is documented.

Exams love near-synonyms. Keep these apart.