api-specs/idn/sailpoint-api.beta.yaml

openapi: 3.0.1
info:
  title: Identity Security Cloud Beta API
  description: "Use these APIs to interact with the Identity Security Cloud platform to achieve repeatable, automated processes with greater scalability. These APIs are in beta and are subject to change. We encourage you to join the SailPoint Developer Community forum at https://developer.sailpoint.com/discuss to connect with other developers using our APIs."
  termsOfService: https://developer.sailpoint.com/discuss/tos
  contact:
    name: Developer Relations
    url: https://developer.sailpoint.com/discuss/api-help
  license:
    name: MIT
    url: https://opensource.org/licenses/MIT
  version: 3.1.0-beta
servers:
  - url: https://{tenant}.api.identitynow.com/beta
    description: This is the beta API server.
    variables:
      tenant:
        default: sailpoint
        description: This is the name of your tenant, typically your company's name.
  - url: https://{apiUrl}/beta
    description: This is the beta API server.
    variables:
      apiUrl:
        default: sailpoint.api.identitynow.com
        description: This is the api url of your tenant
tags:
  - name: Access Profiles
    description: |
      Use this API to implement and customize access profile functionality.
      With this functionality in place, administrators can create access profiles and configure them for use throughout Identity Security Cloud, enabling users to get the access they need quickly and securely.

      Access profiles group entitlements, which represent access rights on sources.

      For example, an Active Directory source in Identity Security Cloud can have multiple entitlements: the first, 'Employees,' may represent the access all employees have at the organization, and a second, 'Developers,' may represent the access all developers have at the organization.

      An administrator can then create a broader set of access in the form of an access profile, 'AD Developers' grouping the 'Employees' entitlement with the 'Developers' entitlement.

      When users only need Active Directory employee access, they can request access to the 'Employees' entitlement.

      When users need both Active Directory employee and developer access, they can request access to the 'AD Developers' access profile.

      Access profiles are the most important units of access in Identity Security Cloud. Identity Security Cloud uses access profiles in many features, including the following:

      - Provisioning: When you use the Provisioning Service, lifecycle states and roles both grant access to users in the form of access profiles.

      - Certifications: You can approve or revoke access profiles in certification campaigns, just like entitlements.

      - Access Requests: You can assign access profiles to applications, and when a user requests access to the app associated with an access profile and someone approves the request, access is granted to both the application and its associated access profile.

      - Roles: You can group one or more access profiles into a role to quickly assign access items based on an identity's role.

      In Identity Security Cloud, administrators can use the Access drop-down menu and select Access Profiles to view, configure, and delete existing access profiles, as well as create new ones.
      Administrators can enable and disable an access profile, and they can also make the following configurations:

      - Manage Entitlements: Manage the profile's access by adding and removing entitlements.

      - Access Requests: Configure access profiles to be requestable and establish an approval process for any requests that the access profile be granted or revoked.
      Do not configure an access profile to be requestable without first establishing a secure access request approval process for the access profile.

      - Multiple Account Options: Define the logic Identity Security Cloud uses to provision access to an identity with multiple accounts on the source.

      Refer to [Managing Access Profiles](https://documentation.sailpoint.com/saas/help/access/access-profiles.html) for more information about access profiles.
  - name: Access Requests
    description: |
      Use this API to implement and customize access request functionality.
      With this functionality in place, users can request access to applications, entitlements, or roles, and managers can request that team members' access be revoked.
      This allows users to get access to the tools they need quickly and securely, and it allows managers to take away access to those tools.

      Identity Security Cloud's Access Request service allows end users to request access that requires approval before it can be granted to users and enables qualified users to review those requests and approve or deny them.

      In the Request Center in Identity Security Cloud, users can view available applications, roles, and entitlements and request access to them.
      If the requested tools requires approval, the requests appear as 'Pending' under the My Requests tab until the required approver approves, rejects, or cancels them.

      Users can use My Requests to track and/or cancel the requests.

      In My Team on the Identity Security Cloud Home, managers can submit requests to revoke their team members' access.
      They can use the My Requests tab under Request Center to track and/or cancel the requests.

      Refer to [Requesting Access](https://documentation.sailpoint.com/saas/user-help/requests/requesting_access.html) for more information about access requests.
  - name: Access Request Approvals
    description: |
      Use this API to implement and customize access request approval functionality.
      With this functionality in place, administrators can delegate qualified users to review users' requests for access or managers' requests to revoke team members' access to applications, entitlements, or roles.
      This enables more qualified users to review access requests and the others to spend their time on other tasks.

      In Identity Security Cloud, users can request access to applications, entitlements, and roles, and managers can request that team members' access be revoked.
      For applications and entitlements, administrators can set access profiles to require approval from the access profile owner, the application owner, the source owner, the requesting user's manager, or a governance group for access to be granted or revoked.
      For roles, administrators can also set roles to allow access requests and require approval from the role owner, the requesting user's manager, or a governance group for access to be granted or revoked.
      If the administrator designates a governance group as the required approver, any governance group member can approve the requests.

      When a user submits an access request, Identity Security Cloud sends the first required approver in the queue an email notification, based on the access request configuration's approval and reminder escalation configuration.

      In Approvals in Identity Security Cloud, required approvers can view pending access requests under the Requested tab and approve or deny them, or the approvers can reassign the requests to different reviewers for approval.
      If the required approver approves the request and is the only reviewer required, Identity Security Cloud grants or revokes access, based on the request.
      If multiple reviewers are required, Identity Security Cloud sends the request to the next reviewer in the queue, based on the access request configuration's approval reminder and escalation configuration.
      The required approver can then view any completed access requests under the Reviewed tab.

      Refer to [Access Requests](https://documentation.sailpoint.com/saas/help/requests/index.html) for more information about access request approvals.
  - name: Access Request Identity Metrics
    description: |
      Use this API to implement access request identity metrics functionality.
      With this functionality in place, access request reviewers can see relevant details about the requested access item and associated source activity. 
      This allows reviewers to see how many of the identities who share a manager with the access requester have this same type of access and how many of them have had activity in the related source. 
      This additional context about whether the access has been granted before and how often it has been used can help those approving access requests make more informed decisions.
  - name: Accounts
    description: |
      Use this API to implement and customize account functionality.
      With this functionality in place, administrators can manage users' access across sources in Identity Security Cloud.

      In Identity Security Cloud, an account refers to a user's account on a supported source.
      This typically includes a unique identifier for the user, a unique password, a set of permissions associated with the source and a set of attributes. Identity Security Cloud loads accounts through the creation of sources in Identity Security Cloud.

      Administrators can correlate users' identities with the users' accounts on the different sources they use.
      This allows Identity Security Cloud to govern the access of identities and all their correlated accounts securely and cohesively.

      To view the accounts on a source and their correlated identities, administrators can use the Connections drop-down menu, select Sources, select the relevant source, and select its Account tab.

      To view and edit source account statuses for an identity in Identity Security Cloud, administrators can use the Identities drop-down menu, select Identity List, select the relevant identity, and select its Accounts tab.
      Administrators can toggle an account's Actions to aggregate the account, enable/disable it, unlock it, or remove it from the identity.

      Accounts can have the following statuses:

      - Enabled: The account is enabled. The user can access it.

      - Disabled: The account is disabled, and the user cannot access it, but the identity is not disabled in Identity Security Cloud. This can occur when an administrator disables the account or when the user's lifecycle state changes.

      - Locked: The account is locked. This may occur when someone has entered an incorrect password for the account too many times.

      - Pending: The account is currently updating. This status typically lasts seconds.

      Administrators can select the source account to view its attributes, entitlements, and the last time the account's password was changed.

      Refer to [Managing User Accounts](https://documentation.sailpoint.com/saas/help/common/users/user_access.html#managing-user-accounts) for more information about accounts.
  - name: Account Activities
    description: |
      Use this API to implement account activity tracking functionality.
      With this functionality in place, users can track source account activity in Identity Security Cloud, which greatly improves traceability in the system.

      An account activity refers to a log of each action performed on a source account. This is useful for auditing the changes that occur on an account throughout its life.
      In Identity Security Cloud's Search, users can search for account activities and select the activity's row to get an overview of the activity's account action and view its progress, its involved sources, and its most basic metadata, such as the identity requesting the option and the recipient.

      Account activity includes most actions Identity Security Cloud completes on source accounts. Users can search in Identity Security Cloud for the following account action types:

      - Access Request: These include any access requests the source account is involved in.

      - Account Attribute Updates: These include updates to a single attribute on an account on a source.

      - Account State Update: These include locking or unlocking actions on an account on a source.

      - Certification: These include actions removing an entitlement from an account on a source as a result of the entitlement's revocation during a certification.

      - Cloud Automated `Lifecyclestate`: These include automated lifecycle state changes that result in a source account's correlated identity being assigned to a different lifecycle state.
      Identity Security Cloud replaces the `Lifecyclestate` variable with the name of the lifecycle state it has moved the account's identity to.

      - Identity Attribute Update: These include updates to a source account's correlated identity attributes as the result of a provisioning action.
      When you update an identity attribute that also updates an identity's lifecycle state, the cloud automated `Lifecyclestate` event also displays.
      Account Activity does not include attribute updates that occur as a result of aggregation.

      - Identity Refresh: These include correlated identity refreshes that occur for an account on a source whenever the account's correlated identity profile gets a new role or updates.
      These also include refreshes that occur whenever Identity Security Cloud assigns an application to the account's correlated identity based on the application's being assigned to All Users From Source or Specific Users From Source.

      - Lifecycle State Refresh: These include the actions that took place when a lifecycle state changed. This event only occurs after a cloud automated `Lifecyclestate` change or a lifecycle state change.

      - Lifecycle State Change: These include the account activities that result from an identity's manual assignment to a null lifecycle state.

      - Password Change: These include password changes on sources.

      Refer to [Account Activity](https://documentation.sailpoint.com/saas/help/search/index.html#account-activity) for more information about account activities.
  - name: Account Aggregations
    description: |
      Use this API to implement account aggregation progress tracking functionality.
      With this functionality in place, administrators can view in-progress account aggregations, their statuses, and their relevant details.

      An account aggregation refers to the process Identity Security Cloud uses to gather and load account data from a source into Identity Security Cloud.

      Whenever Identity Security Cloud is in the process of aggregating a source, it adds an entry to the Aggregation Activity Log, along with its relevant details.
      To view aggregation activity, administrators can select the Connections drop-down menu, select Sources, and select the relevant source, select its Import Data tab, and select Account Aggregation.
      In Account Aggregation, administrators can view the account aggregations' statuses and details in the Account Activity Log.

      Refer to [Loading Account Data](https://documentation.sailpoint.com/saas/help/accounts/loading_data.html) for more information about account aggregations.
  - name: Account Usages
    description: |
      Use this API to implement account usage insight functionality.
      With this functionality in place, administrators can gather information and insights about how their tenants' source accounts are being used.
      This allows organizations to get the information they need to start optimizing and securing source account usage.
  - name: Auth Profile
    description: |
      Auth Profile - Represents authentication configuration for an Identity Profile. This object gets created when an Identity Profile is created.

      APIs can be used to retrieve and update Auth Profiles.
  - name: Certifications
    description: |
      Use this API to implement certification functionality.
      This API provides specific functionality that improves an organization's ability to manage its certification process.

      A certification refers to Identity Security Cloud's mechanism for reviewing a user's access to entitlements (sets of permissions) and approving or removing that access.
      These certifications serve as a way of showing that a user's access has been reviewed and approved.
      Multiple certifications by different reviewers are often required to approve a user's access.
      A set of multiple certifications is called a certification campaign.

      For example, an organization may use a Manager Certification as a way of showing that a user's access has been reviewed and approved by their manager, or if the certification is part of a campaign, that the user's access has been reviewed and approved by multiple managers.
      Once this certification has been completed, Identity Security Cloud  would provision all the access the user needs, nothing more.

      This API enables administrators and reviewers to get useful information about certifications at a high level, such as the reviewers involved, and at a more granular level, such as the permissions affected by changes to entitlements within those certifications.
      It also provides the useful ability to reassign identities and items within certifications to other reviewers, rather than [reassigning the entire certifications themselves](https://developer.sailpoint.com/idn/api/beta/submit-reassign-certs-async/).

      Refer to [Managing User Accounts](https://documentation.sailpoint.com/saas/help/common/users/user_access.html#managing-user-accounts) for more information about accounts.
  - name: Certification Campaigns
    description: |
      Use this API to implement certification campaign functionality.
      With this functionality in place, administrators can create, customize, and manage certification campaigns for their organizations' use.
      Certification campaigns provide Identity Security Cloud users with an interactive review process they can use to identify and verify access to systems.
      Campaigns help organizations reduce risk of inappropriate access and satisfy audit requirements.

      A certification refers to Identity Security Cloud's mechanism for reviewing a user's access to entitlements (sets of permissions) and approving or removing that access.
      These certifications serve as a way of showing that a user's access has been reviewed and approved.
      Multiple certifications by different reviewers are often required to approve a user's access.
      A set of multiple certifications is called a certification campaign.

      For example, an organization may use a Manager Certification campaign as a way of showing that a user's access has been reviewed and approved by multiple managers.
      Once this campaign has been completed, Identity Security Cloud would provision all the access the user needs, nothing more.

      Identity Security Cloud provides two simple campaign types users can create without using search queries, Manager and Source Owner campaigns:

      You can create these types of campaigns without using any search queries in Identity Security Cloud:

      - ManagerCampaign: Identity Security Cloud provides this campaign type as a way to ensure that an identity's access is certified by their managers.
      You only need to provide a name and description to create one.

      - Source Owner Campaign: Identity Security Cloud provides this campaign type as a way to ensure that an identity's access to a source is certified by its source owners.
      You only need to provide a name and description to create one.
      You can specify the sources whose owners you want involved or just run it across all sources.

      For more information about these campaign types, refer to [Starting a Manager or Source Owner Campaign](https://documentation.sailpoint.com/saas/help/certs/starting_campaign.html).

      One useful way to create certification campaigns in Identity Security Cloud is to use a specific search and then run a campaign on the results returned by that search.
      This allows you to be much more specific about whom you are certifying in your campaigns and what access you are certifying in your campaigns.
      For example, you can search for all identities who are managed by "Amanda.Ross" and also have the access to the "Accounting" role and then run a certification campaign based on that search to ensure that the returned identities are appropriately certified.

      You can use Identity Security Cloud search queries to create these types of campaigns:

      - Identities: Use this campaign type to review and revoke access items for specific identities.
      You can either build a search query and create a campaign certifying all identities returned by that query, or you can search for individual identities and add those identities to the certification campaign.

      - Access Items: Use this campaign type to review and revoke a set of roles, access profiles, or entitlements from the identities that have them.
      You can either build a search query and create a campaign certifying all access items returned by that query, or you can search for individual access items and add those items to the certification campaign.

      - Role Composition: Use this campaign type to review a role's composition, including its title, description, and membership criteria.
      You can either build a search query and create a campaign certifying all roles returned by that query, or you can search for individual roles and add those roles to the certification campaign.

      - Uncorrelated Accounts: Use this campaign type to certify source accounts that aren't linked to an authoritative identity in Identity Security Cloud.
      You can use this campaign type to view all the uncorrelated accounts for a source and certify them.

      For more information about search-based campaigns, refer to [Starting a Campaign from Search](https://documentation.sailpoint.com/saas/help/certs/starting_search_campaign.html).

      Once you have generated your campaign, it becomes available for preview.
      An administrator can review the campaign and make changes, or if it's ready and accurate, activate it.

      Once the campaign is active, organization administrators or certification administrators can designate other Identity Security Cloud users as certification reviewers.
      Those reviewers can view any of the certifications they either need to review (active) or have already reviewed (completed).

      When a certification campaign is in progress, certification reviewers see the listed active certifications whose involved identities they can review.
      Reviewers can then make decisions to grant or revoke access, as well as reassign the ceritifcation to another reviewer. If the reviewer chooses this option, they must provide a reason for reassignment in the form of a comment.

      Once a reviewer has made decisions on all the certification's involved access items, he or she must "Sign Off" to complete the review process.
      Doing so converts the certification into read-only status, preventing any further changes to the review decisions and deleting the work item (task) from the reviewer's list of work items.

      Once all the reviewers have signed off, the certification campaign either completes or, if any reviewers decided to revoke access for any of the involved identities, it moves into a remediation phase.
      In the remediation phase, identities' entitlements are altered to remove any entitlements marked for revocation.
      In this situation, the certification campaign completes once all the remediation requests are completed.

      The end of a certification campaign is determined by its deadline, its completion status, or by an administrator's decision.

      For more information about certifications and certification campaigns, refer to [Certifications](https://documentation.sailpoint.com/saas/user-help/certifications.html).
  - name: Connectors
    description: |
      Use this API to implement connector functionality.
      With this functionality in place, administrators can view available connectors.

      Connectors are the bridges Identity Security Cloud uses to communicate with and aggregate data from sources.
      For example, if it is necessary to set up a connection between Identity Security Cloud and the Active Directory source, a connector can bridge the two and enable Identity Security Cloud to synchronize data between the systems.
      This ensures account entitlements and states are correct throughout the organization.

      In Identity Security Cloud, administrators can use the Connections drop-down menu and select Sources to view the available source connectors.

      Refer to [Identity Security Cloud Connectors](https://documentation.sailpoint.com/connectors/identitynow/landingpages/help/landingpages/identitynow_connectivity_landing.html) for more information about the connectors available in Identity Security Cloud.

      Refer to [SaaS Connectivity](https://developer.sailpoint.com/docs/connectivity/saas-connectivity) for more information about the SaaS custom connectors that do not need VAs (virtual appliances) to communicate with their sources.

      Refer to [Managing Sources](https://documentation.sailpoint.com/saas/help/sources/managing_sources.html) for more information about using connectors in Identity Security Cloud.
  - name: Connector Rule Management
  - name: Custom Forms
    description: |
      Use this API to build and manage custom forms.
      With this functionality in place, administrators can create and view form definitions and form instances.

      Forms are composed of sections and fields. Sections split the form into logical groups of fields and fields are the data collection points within the form. Configure conditions to modify elements of the form as the responder provides input. Create form inputs to pass information from a calling feature, like a workflow, to your form.

      Forms can be used within workflows as an action or as a trigger. The Form Action allows you to assign a form as a step in a running workflow, suspending the workflow until the form is submitted or times out, and the workflow resumes. The Form Submitted Trigger initiates a workflow when a form is submitted. The trigger can be configured to initiate on submission of a full form, a form element with any value, or a form element with a particular value.
      
      Refer to [Forms](https://documentation.sailpoint.com/saas/help/forms/index.html) for more information about using forms in Identity Security Cloud.
  - name: Custom Password Instructions
    description: |
      Use this API to implement custom password instruction functionality.
      With this functionality in place, administrators can create custom password instructions to help users reset their passwords, change them, unlock their accounts, or recover their usernames.
      This allows administrators to emphasize password policies or provide organization-specific instructions.

      Administrators must first use [Update Password Org Config](https://developer.sailpoint.com/docs/api/beta/put-password-org-config/) to set `customInstructionsEnabled` to `true`.

      Once they have enabled custom instructions, they can use [Create Custom Password Instructions](https://developer.sailpoint.com/docs/api/beta/create-custom-password-instructions/) to create custom page content for the specific pageId they select.

      For example, an administrator can use the pageId forget-username:user-email to set the custom text for the case when users forget their usernames and must enter their emails.

      Refer to [Creating Custom Instruction Text](https://documentation.sailpoint.com/saas/help/pwd/pwd_reset.html#creating-custom-instruction-text) for more information about creating custom password instructions.
  - name: Discovered Applications
    description: |
      Use this API to retrieve all the available discovered apps for a given tenant id.
  - name: Entitlements
    description: |
      Use this API to implement and customize entitlement functionality.
      With this functionality in place, administrators can view entitlements and configure them for use throughout Identity Security Cloud in certifications, access profiles, and roles.
      Administrators in Identity Security Cloud can then grant users access to the entitlements or configure them so users themselves can request access to the entitlements whenever they need them.
      With a good approval process, this entitlement functionality allows users to gain the specific access they need on sources quickly and securely.

      Entitlements represent access rights on sources.
      Entitlements are the most granular form of access in Identity Security Cloud.
      Entitlements are often grouped into access profiles, and access profiles themselves are often grouped into roles, the broadest form of access in Identity Security Cloud.

      For example, an Active Directory source in Identity Security Cloud can have multiple entitlements: the first, 'Employees,' may represent the access all employees have at the organization, and a second, 'Developers,' may represent the access all developers have at the organization.

      An administrator can then create a broader set of access in the form of an access profile, 'AD Developers' grouping the 'Employees' entitlement with the 'Developers' entitlement.

      An administrator can then create an even broader set of access in the form of a role grouping the 'AD Developers' access profile with another profile, 'GitHub Developers,' grouping entitlements for the GitHub source.

      When users only need Active Directory employee access, they can request access to the 'Employees' entitlement.

      When users need both Active Directory employee and developer access, they can request access to the 'AD Developers' access profile.

      When users need both the 'AD Developers' access profile and the 'GitHub Developers' access profile, they can request access to the role grouping both.

      Administrators often use roles and access profiles within those roles to manage access so that users can gain access more quickly, but the hierarchy of access all starts with entitlements.

      Anywhere entitlements appear, you can select them to find more information about the following:

      - Cloud Access Details: These provide details about the cloud access entitlements on cloud-enabled sources.

      - Permissions: Permissions represent individual units of read/write/admin access to a system.

      - Relationships: These list each entitlement's parent and child relationships.

      - Type: This is the entitlement's type. Some sources support multiple types, each with a different attribute schema.

      Identity Security Cloud uses entitlements in many features, including the following:

      - Certifications: Entitlements can be revoked from an identity that no longer needs them.

      - Roles: Roles can group access profiles which themselves group entitlements. You can grant and revoke access on a broad level with roles. Role membership criteria can grant roles to identities based on whether they have certain entitlements or attributes.

      - Access Profiles: Access profiles group entitlements.
      They are the most important units of access in Identity Security Cloud.
      Identity Security Cloud uses them in provisioning, certifications, and access requests, and administrators can configure them to grant very broad or very granular access.

      You cannot delete entitlements directly from Identity Security Cloud.
      Entitlements are deleted based on their inclusion in aggregations.

      Refer to [Deleting Entitlements](https://documentation.sailpoint.com/saas/help/access/entitlements.html#deleting-entitlements) more information about deleting entitlements.

      Refer to [Entitlements](https://documentation.sailpoint.com/saas/help/access/entitlements.html) for more information about entitlements.
  - name: Governance Groups
    description: |
      Use this API to implement and customize Governance Group functionality. With this functionality in place, administrators can create Governance Groups and configure them for use throughout Identity Security Cloud.

      A governance group is a group of users that can make governance decisions about access. If your organization has the Access Request or Certifications service, you can configure governance groups to review access requests or certifications. A governance group can determine whether specific access is appropriate for a user.

      Refer to [Creating and Managing Governance Groups](https://documentation.sailpoint.com/saas/help/common/users/governance_groups.html) for more information about how to build Governance Groups in the visual builder in the Identity Security Cloud UI.
  - name: IAI Access Request Recommendations
  - name: IAI Common Access
  - name: IAI Message Catalogs
  - name: IAI Outliers
  - name: IAI Peer Group Strategies
  - name: IAI Recommendations
  - name: IAI Role Mining
  - name: Icons
    description: |
      Use this API to implement functionality related to object icons (application icons for example). 
      With this functionality in place, administrators can set or remove an icon for specific object type for use throughout Identity Security Cloud.
  - name: Identities
    description: |
      Use this API to implement identity functionality.
      With this functionality in place, administrators can synchronize an identity's attributes with its various source attributes.

      Identity Security Cloud uses identities as users' authoritative accounts. Identities can own other accounts, entitlements, and attributes.

      An identity has a variety of attributes, such as an account name, an email address, a job title, and more.
      These identity attributes can be correlated with different attributes on different sources.
      For example, the identity John.Smith can own an account in the GitHub source with the account name John-Smith-Org, and Identity Security Cloud knows they are the same person with the same access and attributes.

      In Identity Security Cloud, administrators often set up these synchronizations to get triggered automatically with a change or to run on a schedule.
      To manually synchronize attributes for an identity, administrators can use the Identities drop-down menu and select Identity List to view the list of identities.
      They can then select the identity they want to manually synchronize and use the hamburger menu to select 'Synchronize Attributes.'
      Doing so immediately begins the attribute synchronization and analyzes all accounts for the selected identity.

      Refer to [Synchronizing Attributes](https://documentation.sailpoint.com/saas/help/provisioning/attr_sync.html) for more information about synchronizing attributes.
  - name: Identity Attributes
  - name: Identity History
  - name: Identity Profiles
    description: |
      Use this API to implement and customize identity profile functionality.
      With this functionality in place, administrators can manage identity profiles and configure them for use by identities throughout Identity Security Cloud.

      Identity profiles represent the configurations that can be applied to identities as a way of granting them a set of security and access, as well as defining the mappings between their identity attributes and their source attributes.
      This allows administrators to save time by applying identity profiles to any number of similar identities rather than configuring each one individually.

      In Identity Security Cloud, administrators can use the Identities drop-down menu and select Identity Profiles to view the list of identity profiles.
      This list shows some details about each identity profile, along with its status. They can select an identity profile to view and modify its settings, its mappings between identity attributes and correlating source account attributes, and its provisioning settings.
      Administrators can also use this page to create new identity profiles or delete existing ones.

      Refer to [Creating Identity Profiles](https://documentation.sailpoint.com/saas/help/setup/identity_profiles.html) for more information about identity profiles.
  - name: Lifecycle States
    description: |
      Use this API to implement and customize lifecycle state functionality.
      With this functionality in place, administrators can view and configure custom lifecycle states for use across their organizations, which is key to controlling which users have access, when they have access, and the access they have.

      A lifecycle state describes a user's status in a company. For example, two lifecycle states come by default with Identity Security Cloud: 'Active' and 'Inactive.'
      When an active employee takes an extended leave of absence from a company, his or her lifecycle state may change to 'Inactive,' for security purposes.
      The inactive employee would lose access to all the applications, sources, and sensitive data during the leave of absence, but when the employee returns and becomes active again, all that access would be restored.
      This saves administrators the time that would otherwise be spent provisioning the employee's access to each individual tool, reviewing the employee's certification history, etc.

      Administrators must define the criteria for being in each lifecycle state, and they must define how Identity Security Cloud manages users' access to apps and sources for each lifecycle state.

      In Identity Security Cloud, administrators can manage lifecycle states by going to Admin > Identities > Identity Profile, selecting the identity profile whose lifecycle states they want to manage, selecting the 'Provisioning' tab, and using the left panel to select the lifecycle state they want to modify.

      In the 'Provisioning' tab, administrators can make the following access changes to an identity profile's lifecycle state:

      - Enable/disable the lifecycle state for the identity profile.

      - Enable/disable source accounts for the identity profile's lifecycle state.

      - Add existing access profiles to grant to the identity profiles in that lifecycle state.

      - Create a new access profile to grant to the identity profile in that lifecycle state.

      Access profiles granted in a previous lifecycle state are automatically revoked when the identity moves to a new lifecycle state.
      To maintain access across multiple lifecycle states, administrators must grant the access profiles in each lifecycle state.
      For example, if an administrator wants users with the 'HR Employee' identity profile to maintain their building access in both the 'Active' and 'Leave of Absence' lifecycle states, the administrator must grant the access profile for that building access to both lifecycle states.

      During scheduled refreshes, Identity Security Cloud evaluates lifecycle states to determine whether their assigned identities have the access defined in the lifecycle states' access profiles.
      If the identities are missing access, Identity Security Cloud provisions that access.

      Administrators can also use the 'Provisioning' tab to configure email notifications for Identity Security Cloud to send whenever an identity with that identity profile has a lifecycle state change.
      Refer to [Configuring Lifecycle State Notifications](https://documentation.sailpoint.com/saas/help/provisioning/lifecycle.html#configuring-lifecycle-state-notifications) for more information on how to do so.

      An identity's lifecycle state can have four different statuses: the lifecycle state's status can be 'Active,' it can be 'Not Set,' it can be 'Not Valid,' or it 'Does Not Match Technical Name Case.'
      Refer to [Moving Identities into Lifecycle States](https://documentation.sailpoint.com/saas/help/provisioning/lifecycle.html#moving-identities-into-lifecycle-states) for more information about these different lifecycle state statuses.

      Refer to [Setting Up Lifecycle States](https://documentation.sailpoint.com/saas/help/provisioning/lifecycle.html) for more information about lifecycle states.
  - name: Managed Clients
    description: Read and write operations for managing client data and statuses
  - name: Managed Clusters
    description: Operations for accessing and managing client Clusters, including Log Configuration
  - name: Manual Discover Applications
    description: |
      Use this API to manually upload application names to be correlated to an ISC connector.
  - name: Manual Discover Applications Template
    description: |
      Use this API to download the CSV template to send to the application discovery service.
  - name: MFA Configuration
    description: Configure and test multifactor authentication (MFA) methods
  - name: MFA Controller
    description: This API used for multifactor authentication functionality belong to gov-multi-auth service. This controller allow you to verify authentication by specified method
  - name: Non-Employee Lifecycle Management
    description: |
      Use this API to implement non-employee lifecycle management functionality.
      With this functionality in place, administrators can create non-employee records and configure them for use in their organizations.
      This allows organizations to provide secure access to non-employees and control that access.

      The 'non-employee' term refers to any consultant, contractor, intern, or other user in an organization who is not a full-time permanent employee.
      Organizations can track non-employees' access and activity in Identity Security Cloud by creating and maintaining non-employee sources.
      Organizations can have a maximum of 50 non-employee sources.

      By using SailPoint's Non-Employee Lifecycle Management functionality, you agree to the following:

      - SailPoint is not responsible for storing sensitive data.
      You may only add account attributes to non-employee identities that are necessary for business operations and are consistent with your contractual limitations on data that may be sent or stored in Identity Security Cloud.

      - You are responsible for regularly downloading your list of non-employee accounts for all the sources you create and storing this list of accounts in a managed location to maintain an authoritative system of record and backup data for these accounts.

      To manage non-employees in Identity Security Cloud, administrators must create a non-employee source and add accounts to the source.

      To create a non-employee source in Identity Security Cloud, administrators must use the Admin panel to go to Connections > Sources.
      They must then specify 'Non-Employee' in the 'Source Type' field.
      Refer to [Creating a Non-Employee Source](https://documentation.sailpoint.com/saas/help/common/non-employee-mgmt.html#creating-a-non-employee-source) for more details about how to create non-employee sources.

      To add accounts to a non-employee source in Identity Security Cloud, administrators can select the non-employee source and add the accounts.
      They can also use the 'Manage Non-Employees' widget on their user dashboards to reach the list of sources and then select the non-employee source they want to add the accounts to.

      Administrators can either add accounts individually or in bulk. Each non-employee source can have a maximum of 20,000 accounts.
      To add accounts in bulk, they must select the 'Bulk Upload' option and upload a CSV file.
      Refer to [Adding Accounts](https://documentation.sailpoint.com/saas/help/common/non-employee-mgmt.html#adding-accounts) for more details about how to add accounts to non-employee sources.

      Once administrators have created the non-employee source and added accounts to it, they can create identity profiles to generate identities for the non-employee accounts and manage the non-employee identities the same way they would any other identities.

      Refer to [Managing Non-Employee Sources and Accounts](https://documentation.sailpoint.com/saas/help/common/non-employee-mgmt.html) for more information about non-employee lifecycle management.
  - name: Notifications
  - name: OAuth Clients
    description: |
      Use this API to implement OAuth client functionality.
      With this functionality in place, users with the appropriate security scopes can create and configure OAuth clients to use as a way to obtain authorization to use the Identity Security Cloud REST API.
      Refer to [Authentication](https://developer.sailpoint.com/docs/api/authentication/) for more information about OAuth and how it works with the Identity Security Cloud REST API.
  - name: Org Config
    description: Operations for managing org configuration settings (eg. time zone)
  - name: Password Configuration
    description: |
      Use this API to implement organization password configuration functionality.
      With this functionality in place, organization administrators can create organization-specific password configurations.

      These configurations include details like custom password instructions, as well as digit token length and duration.

      Refer to [Configuring User Authentication for Password Resets](https://documentation.sailpoint.com/saas/help/pwd/pwd_reset.html) for more information about organization password configuration functionality.
  - name: Password Dictionary
    description: |
      Use this API to implement password dictionary functionality.
      With this functionality in place, administrators can create password dictionaries to prevent users from using certain words or characters in their passwords.

      A password dictionary is a list of words or characters that users are prevented from including in their passwords.
      This can help protect users from themselves and force them to create passwords that are not easy to break.

      A password dictionary must meet the following requirements to for the API to handle them correctly:

      - It must be in .txt format.

      - All characters must be UTF-8 characters.

      - Each line must contain a single word or character with no spaces or whitespace characters.

      - It must contain at least one line other than the locale string.

      - Each line must not exceed 128 characters.

      - The file must not exceed 2500 lines.

      Administrators should also consider the following when they create their dictionaries:

      - Lines starting with a # represent comments.

      - All words in the password dictionary are case-insensitive.
      For example, adding the word "password" to the dictionary also disallows the following: PASSWORD, Password, and PassWord.

      - The dictionary uses substring matching.
      For example, adding the word "spring" to the dictionary also disallows the following: Spring124, 345SprinG, and 8spring.
      Users can then select 'Change Password' to update their passwords.

      Administrators must do the following to create a password dictionary:

      - Create the text file that will contain the prohibited password values.

      - If the dictionary is not in English, they must add a locale string to the top line: locale:`languageCode`_`countryCode`

      The languageCode value refers to the language's 2-letter ISO 639-1 code.
      The countryCode value refers to the country's 2-letter ISO 3166-1 code.

      Refer to this list https://docs.oracle.com/cd/E13214_01/wli/docs92/xref/xqisocodes.html to see all the available ISO 639-1 language codes and ISO 3166-1 country codes.

      - Upload the .txt file to Identity Security Cloud with [Update Password Dictionary](https://developer.sailpoint.com/docs/api/beta/put-password-dictionary). Uploading a new file always overwrites the previous dictionary file.

      Administrators can then specify which password policies check new passwords against the password dictionary by doing the following: In the Admin panel, they can use the Password Mgmt dropdown menu to select Policies, select the policy, and select the 'Prevent use of words in this site's password dictionary' checkbox beside it.

      Refer to [Configuring Advanced Password Management Options](https://documentation.sailpoint.com/saas/help/pwd/adv_config.html) for more information about password dictionaries.
  - name: Password Management
    description: |
      Use this API to implement password management functionality.
      With this functionality in place, users can manage their identity passwords for all their applications.

      In Identity Security Cloud, users can select their names in the upper right corner of the page and use the drop-down menu to select Password Manager.
      Password Manager lists the user's identity's applications, possibly grouped to share passwords.
      Users can then select 'Change Password' to update their passwords.

      Grouping passwords allows users to update their passwords more broadly, rather than requiring them to update each password individually.
      Password Manager may list the applications and sources in the following groups:

      - Password Group: This refers to a group of applications that share a password.
      For example, a user can use the same password for Google Drive, Google Mail, and YouTube.
      Updating the password for the password group updates the password for all its included applications.

      - Multi-Application Source: This refers to a source with multiple applications that share a password.
      For example, a user can have a source, G Suite, that includes the Google Calendar, Google Drive, and Google Mail applications.
      Updating the password for the multi-application source updates the password for all its included applications.

      - Applications: These are applications that do not share passwords with other applications.

      An organization may require some authentication for users to update their passwords.
      Users may be required to answer security questions or use a third-party authenticator before they can confirm their updates.

      Refer to [Managing Passwords](https://documentation.sailpoint.com/saas/user-help/accounts/passwords.html) for more information about password management.
  - name: Password Sync Groups
    description: |
      Use this API to implement password sync group functionality.
      With this functionality in place, administrators can group sources into password sync groups so that all their applications share the same password.
      This allows users to update the password for all the applications in a sync group if they want, rather than updating each password individually.

      A password sync group is a group of applications that shares a password.
      Administrators create these groups by grouping the applications' sources.
      For example, an administrator can group the ActiveDirectory, GitHub, and G Suite sources together so that all those sources' applications can also be grouped to share a password.
      A user can then update his or her password for ActiveDirectory, GitHub, Gmail, Google Drive, and Google Calendar all at once, rather then updating each one individually.

      The following are required for administrators to create a password sync group in Identity Security Cloud:

      - At least two direct connect sources connected to Identity Security Cloud and configured for Password Management.

      - Each authentication source in a sync group must have at least one application. Refer to [Adding and Resetting Application Passwords](https://documentation.sailpoint.com/saas/help/pwd/adv_config.html#adding-and-resetting-application-passwords) for more information about adding applications to sources.

      - At least one password policy. Refer to [Managing Password Policies](https://documentation.sailpoint.com/saas/help/pwd/policies.html) for more information about password policies.

      In the Admin panel in Identity Security Cloud, administrators can use the Password Mgmt dropdown menu to select Sync Groups.
      To create a sync group, administrators must provide a name, choose a password policy to be enforced across the sources in the sync group, and select the sources to include in the sync group.

      Administrators can also delete sync groups in Identity Security Cloud, but they should know the following before they do:

      - Passwords related to the associated sources will become independent, so changing one will not change the others anymore.

      - Passwords for the sources' connected applications will also become independent.

      - Password policies assigned to the sync group are then assigned directly to the associated sources.
      To change the password policy for a source, administrators must edit it directly.

      Once the password sync group has been created, users can update the password for the group in Password Manager.

      Refer to [Managing Password Sync Groups](https://documentation.sailpoint.com/saas/help/pwd/sync_grps.html) for more information about password sync groups.
  - name: Personal Access Tokens
    description: |
      Use this API to implement personal access token (PAT) functionality.
      With this functionality in place, users can use PATs as an alternative to passwords for authentication in Identity Security Cloud.

      PATs embed user information into the client ID and secret.
      This replaces the API clients' need to store and provide a username and password to establish a connection, improving Identity Security Cloud organizations' integration security.

      In Identity Security Cloud, users can do the following to create and manage their PATs: Select the dropdown menu under their names, select Preferences, and then select Personal Access Tokens.
      They must then provide a description about the token's purpose.
      They can then select 'Create Token' at the bottom of the page to generate and view the Secret and Client ID.

      Refer to [Managing Personal Access Tokens](https://documentation.sailpoint.com/saas/help/common/generate_tokens.html) for more information about PATs.
  - name: Public Identities Config
    description: |
      Use this API to implement public identity configuration functionality.
      With this functionality in place, administrators can make up to 5 identity attributes publicly visible so other non-administrator users can see the relevant information they need to make decisions.
      This can be helpful for access approvers, certification reviewers, managers viewing their direct reports' access, and source owners viewing their tasks.

      By default, non-administrators can select an identity and view the following attributes: email, lifecycle state, and manager.
      However, it may be helpful for a non-administrator reviewer to see other identity attributes like department, region, title, etc.
      Administrators can use this API to make those necessary identity attributes public to non-administrators.

      For example, a non-administrator deciding whether to approve another identity's request for access to the Workday application, whose access may be restricted to members of the HR department, would want to know whether the identity is a member of the HR department.
      If an administrator has used [Update Public Identity Config](https://developer.sailpoint.com/docs/api/beta/update-public-identity-config/) to make the "department" attribute public, the approver can see the department and make a decision without requesting any more information.
  - name: Requestable Objects
    description: |
      Use this API to implement requestable object functionality.
      With this functionality in place, administrators can determine which access items can be requested with the [Access Request APIs](https://developer.sailpoint.com/docs/api/beta/access-requests/), along with their statuses.
      This can be helpful for administrators who are implementing and customizing access request functionality as a way of checking which items are requestable as they are created, assigned, and made available.
  - name: Roles
    description: |
      Use this API to implement and customize role functionality.
      With this functionality in place, administrators can create roles and configure them for use throughout Identity Security Cloud.
      Identity Security Cloud can use established criteria to automatically assign the roles to qualified users. This enables users to get all the access they need quickly and securely and administrators to spend their time on other tasks.

      Entitlements represent the most granular level of access in Identity Security Cloud.
      Access profiles represent the next level and often group entitlements.
      Roles represent the broadest level of access and often group access profiles.

      For example, an Active Directory source in Identity Security Cloud can have multiple entitlements: the first, 'Employees,' may represent the access all employees have at the organization, and a second, 'Developers,' may represent the access all developers have at the organization.

      An administrator can then create a broader set of access in the form of an access profile, 'AD Developers' grouping the 'Employees' entitlement with the 'Developers' entitlement.

      An administrator can then create an even broader set of access in the form of a role grouping the 'AD Developers' access profile with another profile, 'GitHub Developers,' grouping entitlements for the GitHub source.

      When users only need Active Directory employee access, they can request access to the 'Employees' entitlement.

      When users need both Active Directory employee and developer access, they can request access to the 'AD Developers' access profile.

      When users need both the 'AD Developers' access profile and the 'GitHub Developers' access profile, they can request access to the role grouping both.

      Roles often represent positions within organizations.
      For example, an organization's accountant can access all the tools the organization's accountants need with the 'Accountant' role.
      If the accountant switches to engineering, a qualified member of the organization can quickly revoke the accountant's 'Accountant' access and grant access to the 'Engineer' role instead, granting access to all the tools the organization's engineers need.

      In Identity Security Cloud, adminstrators can use the Access drop-down menu and select Roles to view, configure, and delete existing roles, as well as create new ones.
      Administrators can enable and disable the role, and they can also make the following configurations:

      - Manage Access: Manage the role's access by adding or removing access profiles.

      - Define Assignment: Define the criteria Identity Security Cloud uses to assign the role to identities.
      Use the first option, 'Standard Criteria,' to provide specific criteria for assignment like specific account attributes, entitlements, or identity attributes.
      Use the second, 'Identity List,' to specify the identities for assignment.

      - Access Requests: Configure roles to be requestable and establish an approval process for any requests that the role be granted or revoked.
      Do not configure a role to be requestable without establishing a secure access request approval process for that role first.

      Refer to [Working with Roles](https://documentation.sailpoint.com/saas/help/access/roles.html) for more information about roles.
  - name: Role Insights
  - name: Search Attribute Configuration
  - name: Segments
    description: |
      Use this API to implement and customize access request segment functionality. 
      With this functionality in place, administrators can create and manage access request segments. 
      Segments provide organizations with a way to make the access their users have even more granular - this can simply the access request process for the organization's users and improves security by reducing the risk of overprovisoning access. 

      Segments represent sets of identities, all grouped by specified identity attributes, who are only able to see and access the access items associated with their segments.
      For example, administrators could group all their organization's London office employees into one segment, "London Office Employees," by their shared location. 
      The administrators could then define the access items the London employees would need, and the identities in the "London Office Employees" would then only be able to see and access those items.

      In Identity Security Cloud, administrators can use the 'Access' drop-down menu and select 'Segments' to reach the 'Access Requests Segments' page. 
      This page lists all the existing access request segments, along with their statuses, enabled or disabled. 
      Administrators can use this page to create, edit, enable, disable, and delete segments. 
      To create a segment, an administrator must provide a name, define the identities grouped in the segment, and define the items the identities in the segment can access.
      These items can be access profiles, roles, or entitlements. 

      When administrators use the API to create and manage segments, they use a JSON expression in the `visibilityCriteria` object to define the segment's identities and access items. 

      Refer to [Managing Access Request Segments](https://documentation.sailpoint.com/saas/help/requests/segments.html) for more information about segments in Identity Security Cloud.
  - name: Service Desk Integration
    description: |
      Use this API to build an integration between Identity Security Cloud and a service desk ITSM (IT service management) solution.
      Once an administrator builds this integration between Identity Security Cloud and a service desk, users can use Identity Security Cloud to raise and track tickets that are synchronized between Identity Security Cloud and the service desk.

      In Identity Security Cloud, administrators can create a service desk integration (sometimes also called an SDIM, or Service Desk Integration Module) by going to Admin > Connections > Service Desk and selecting 'Create.'

      To create a Generic Service Desk integration, for example, administrators must provide the required information on the General Settings page, the Connectivity and Authentication information, Ticket Creation information, Status Mapping information, and Requester Source information on the Configure page.
      Refer to [Integrating SailPoint with Generic Service Desk](https://documentation.sailpoint.com/connectors/generic_sd/help/integrating_generic_service_desk/intro.html) for more information about the process of setting up a Generic Service Desk in Identity Security Cloud.

      Administrators can create various service desk integrations, all with their own nuances.
      The following service desk integrations are available:

      - [Atlassian Cloud Jira Service Management](https://documentation.sailpoint.com/connectors/atlassian/jira_cloud/help/integrating_jira_cloud_sd/introduction.html)

      - [Atlassian Server Jira Service Management](https://documentation.sailpoint.com/connectors/atlassian/jira_server/help/integrating_jira_server_sd/introduction.html)

      - [BMC Helix ITSM Service Desk](https://documentation.sailpoint.com/connectors/bmc/helix_ITSM_sd/help/integrating_bmc_helix_itsm_sd/intro.html)

      - [BMC Helix Remedyforce Service Desk](https://documentation.sailpoint.com/connectors/bmc/helix_remedyforce_sd/help/integrating_bmc_helix_remedyforce_sd/intro.html)

      - [Generic Service Desk](https://documentation.sailpoint.com/connectors/generic_sd/help/integrating_generic_service_desk/intro.html)

      - [ServiceNow Service Desk](https://documentation.sailpoint.com/connectors/servicenow/sdim/help/integrating_servicenow_sdim/intro.html)

      - [Zendesk Service Desk](https://documentation.sailpoint.com/connectors/zendesk/help/integrating_zendesk_sd/introduction.html)
  - name: SOD Policies
    description: |
      Use this API to implement and manage "separation of duties" (SOD) policies. 
      With SOD policy functionality in place, administrators can organize the access in their tenants to prevent individuals from gaining conflicting or excessive access. 

      "Separation of duties" refers to the concept that people shouldn't have conflicting sets of access - all their access should be configured in a way that protects your organization's assets and data.  
      For example, people who record monetary transactions shouldn't be able to issue payment for those transactions.
      Any changes to major system configurations should be approved by someone other than the person requesting the change. 

      Organizations can use "separation of duties" (SOD) policies to enforce and track their internal security rules throughout their tenants.
      These SOD policies limit each user's involvement in important processes and protects the organization from individuals gaining excessive access. 

      To create SOD policies in Identity Security Cloud, administrators use 'Search' and then access 'Policies'.
      To create a policy, they must configure two lists of access items. Each access item can only be added to one of the two lists.
      They can search for the entitlements they want to add to these access lists.

      >Note: You can have a maximum of 500 policies of any type (including general policies) in your organization. In each access-based SOD policy, you can have a maximum of 50 entitlements in each access list.

      Once a SOD policy is in place, if an identity has access items on both lists, a SOD violation will trigger. 
      These violations are included in SOD violation reports that other users will see in emails at regular intervals if they're subscribed to the SOD policy.
      The other users can then better help to enforce these SOD policies. 

      To create a subscription to a SOD policy in Identity Security Cloud, administrators use 'Search' and then access 'Layers'.
      They can create a subscription to the policy and schedule it to run at a regular interval. 

      Refer to [Managing Policies](https://documentation.sailpoint.com/saas/help/sod/manage-policies.html) for more information about SOD policies. 

      Refer to [Subscribe to a SOD Policy](https://documentation.sailpoint.com/saas/help/sod/policy-violations.html#subscribe-to-an-sod-policy) for more information about SOD policy subscriptions.
  - name: SOD Violations
    description: |
      Use this API to check for current "separation of duties" (SOD) policy violations as well as potential future SOD policy violations. 
      With SOD violation functionality in place, administrators can get information about current SOD policy violations and predict whether an access change will trigger new violations, which helps to prevent them from occurring at all. 

      "Separation of duties" refers to the concept that people shouldn't have conflicting sets of access - all their access should be configured in a way that protects your organization's assets and data.  
      For example, people who record monetary transactions shouldn't be able to issue payment for those transactions.
      Any changes to major system configurations should be approved by someone other than the person requesting the change. 

      Organizations can use "separation of duties" (SOD) policies to enforce and track their internal security rules throughout their tenants.
      These SOD policies limit each user's involvement in important processes and protects the organization from individuals gaining excessive access. 

      Once a SOD policy is in place, if an identity has conflicting access items, a SOD violation will trigger. 
      These violations are included in SOD violation reports that other users will see in emails at regular intervals if they're subscribed to the SOD policy.
      The other users can then better help to enforce these SOD policies.

      Administrators can use the SOD violations APIs to check a set of identities for any current SOD violations, and they can use them to check whether adding an access item would potentially trigger a SOD violation. 
      This second option is a good way to prevent SOD violations from triggering at all. 

      Refer to [Handling Policy Violations](https://documentation.sailpoint.com/saas/help/sod/policy-violations.html) for more information about SOD policy violations.
  - name: Sources
    description: |
      Use this API to implement and customize source functionality.
      With source functionality in place, organizations can use Identity Security Cloud to connect their various sources and user data sets and manage access across all those different sources in a secure, scalable way.

      [Sources](https://documentation.sailpoint.com/saas/help/sources/managing_sources.html) refer to the Identity Security Cloud representations for external applications, databases, and directory management systems that maintain their own sets of users, like Dropbox, GitHub, and Workday, for example.
      Organizations may use hundreds, if not thousands, of different source systems, and any one employee within an organization likely has a different user record on each source, often with different permissions on many of those records.
      Connecting these sources to Identity Security Cloud makes it possible to manage user access across them all.
      Then, if a new hire starts at an organization, Identity Security Cloud can grant the new hire access to all the sources they need.
      If an employee moves to a new department and needs access to new sources but no longer needs access to others, Identity Security Cloud can grant the necessary access and revoke the unnecessary access for all the employee's various sources.
      If an employee leaves the company, Identity Security Cloud can revoke access to all the employee's various source accounts immediately.
      These are just a few examples of the many ways that source functionality makes identity governance easier, more efficient, and more secure.

      In Identity Security Cloud, administrators can create configure, manage, and edit sources, and they can designate other users as source admins to be able to do so.
      They can also designate users as source sub-admins, who can perform the same source actions but only on sources associated with their governance groups.
      Admins go to Connections > Sources to see a list of the existing source representations in their organizations.
      They can create new sources or select existing ones.

      To create a new source, the following must be specified: Source Name, Description, Source Owner, and Connection Type.
      Refer to [Configuring a Source](https://documentation.sailpoint.com/saas/help/accounts/loading_data.html#configuring-a-source) for more information about the source configuration process.

      Identity Security Cloud connects with its sources either by a direct communication with the source server (connection information specific to the source must be provided) or a flat file feed, a CSV file containing all the relevant information about the accounts to be loaded in.
      Different sources use different connectors to share data with Identity Security Cloud, and each connector's setup process is specific to that connector.
      SailPoint has built a number of connectors to come out of the box and connect to the most common sources, and SailPoint actively maintains these connectors.
      Refer to [Identity Security Cloud Connectors](https://documentation.sailpoint.com/connectors/identitynow/landingpages/help/landingpages/identitynow_connectivity_landing.html) for more information about these SailPoint supported connectors.
      Refer to the following links for more information about two useful connectors:

      - [JDBC Connector](https://documentation.sailpoint.com/connectors/jdbc/help/integrating_jdbc/introduction.html): This customizable connector an directly connect to databases that support JDBC (Java Database Connectivity).

      - [Web Services Connector](https://documentation.sailpoint.com/connectors/webservices/help/integrating_webservices/introduction.html): This connector can directly connect to databases that support Web Services.

      Refer to [SaaS Connectivity](https://developer.sailpoint.com/docs/connectivity/saas-connectivity/) for more information about SailPoint's new connectivity framework that makes it easy to build and manage custom connectors to SaaS sources.

      When admins select existing sources, they can view the following information about the source:

      - Associated connections (any associated identity profiles, apps, or references to the source in a transform).

      - Associated user accounts. These accounts are linked to their identities - this provides a more complete picture of each user's access across sources.

      - Associated entitlements (sets of access rights on sources).

      - Associated access profiles (groupings of entitlements).

      The user account data and the entitlements update with each data aggregation from the source.
      Organizations generally run scheduled, automated data aggregations to ensure that their data is always in sync between their sources and their Identity Security Cloud tenants so an access change on a source is detected quickly in Identity Security Cloud.
      Admins can view a history of these aggregations, and they can also run manual imports.
      Refer to [Loading Account Data](https://documentation.sailpoint.com/saas/help/accounts/loading_data.html) for more information about manual and scheduled aggregations.

      Admins can also make changes to determine which user account data Identity Security Cloud collects from the source and how it correlates that account data with identity data.
      To define which account attributes the source shares with Identity Security Cloud, admins can edit the account schema on the source.
      Refer to [Managing Source Account Schemas](https://documentation.sailpoint.com/saas/help/accounts/schema.html) for more information about source account schemas and how to edit them.
      To define the mapping between the source account attributes and their correlating identity attributes, admins can edit the correlation configuration on the source.
      Refer to [Assigning Source Accounts to Identities](https://documentation.sailpoint.com/saas/help/accounts/correlation.html) for more information about this correlation process between source accounts and identities.

      Admins can also delete sources, but they must first ensure that the sources no longer have any active connections: the source must not be associated with any identity profile or any app, and it must not be referenced by any transform.
      Refer to [Deleting Sources](https://documentation.sailpoint.com/saas/help/sources/managing_sources.html#deleting-sources) for more information about deleting sources.

      Well organized, mapped out connections between sources and Identity Security Cloud are essential to achieving comprehensive identity access governance across all the source systems organizations need.
      Refer to [Managing Sources](https://documentation.sailpoint.com/saas/help/sources/managing_sources.html) for more information about all the different things admins can do with sources once they are connected.
  - name: Source Usages
    description: |
      Use this API to implement source usage insight functionality.
      With this functionality in place, administrators can gather information and insights about how their tenants' sources are being used.
      This allows organizations to get the information they need to start optimizing and securing source usage.
  - name: SP-Config
    description: Import and export configuration for some objects between tenants.
  - name: Suggested Entitlement Description
    description: |
      Use this API to leverage power of LLM to generate suggested entitlement description.
  - name: Tagged Objects
    description: |
      Use this API to implement object tagging functionality. 
      With object tagging functionality in place, any user in an organization can use tags as a way to group objects together and find them more quickly when the user searches Identity Security Cloud. 

      In Identity Security Cloud, users can search their tenants for information and add tags objects they find.
      Tagging an object provides users with a way of grouping objects together and makes it easier to find these objects in the future. 

      For example, if a user is searching for an entitlement that grants a risky level of access to Active Directory, it's possible that the user may have to search through hundreds of entitlements to find the correct one. 
      Once the user finds that entitlement, the user can add a tag to the entitlement, "AD_RISKY" to make it easier to find the entitlement again.
      The user can add the same tag to multiple objects the user wants to group together for an easy future search, and the user can also do so in bulk.
      When the user wants to find that tagged entitlement again, the user can search for "tags:AD_RISKY" to find all objects with that tag. 

      With the API, you can tag even more different object types than you can in Identity Security Cloud (access profiles, entitlements, identities, and roles). 
      You can use the API to tag all these objects:

      - Access profiles 

      - Applications 

      - Certification campaigns

      - Entitlements

      - Identities 

      - Roles 

      - SOD (separation of duties) policies

      - Sources 

      You can also use the API to directly find, create, and manage tagged objects without using search queries. 

      There are limits to tags: 

      - You can have up to 500 different tags in your tenant.

      - You can apply up to 30 tags to one object. 

      - You can have up to 10,000 tag associations, pairings of 1 tag to 1 object, in your tenant. 

      Because of these limits, it is recommended that you work with your governance experts and security teams to establish a list of tags that are most expressive of governance objects and access managed by Identity Security Cloud. 

      These are the types of information often expressed in tags: 

      - Affected departments

      - Compliance and regulatory categories 

      - Remediation urgency levels 

      - Risk levels 

      Refer to [Tagging Items in Search](https://documentation.sailpoint.com/saas/help/search/index.html?h=tags#tagging-items-in-search) for more information about tagging objects in Identity Security Cloud.
  - name: Task Management
  - name: Tenant
    description: API for reading tenant details.
  - name: Transforms
    description: Operations for creating, managing, and deleting transforms.
  - name: Triggers
    description: |
      Event Triggers provide real-time updates to changes in Identity Security Cloud so you can take action as soon as an event occurs, rather than poll an API endpoint for updates. Identity Security Cloud provides a user interface within the admin console to create and manage trigger subscriptions.  These endpoints allow for programatically creating and managing trigger subscriptions.

      There are two types of event triggers:
        * `FIRE_AND_FORGET`: This trigger type will send a payload to each subscriber without needing a response.  Each trigger of this type has a limit of **50 subscriptions**.
        * `REQUEST_RESPONSE`: This trigger type will send a payload to a subscriber and expect a response back.  Each trigger of this type may only have **one subscription**.

      ## Available Event Triggers
      Production ready event triggers that are available in all tenants.

      | Name | ID | Type | Trigger condition |
      |-|-|-|-|
      | [Access Request Dynamic Approval](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/access-request-dynamic-approval/) | idn:access-request-dynamic-approver | REQUEST_RESPONSE |After an access request is submitted. Expects the subscriber to respond with the ID of an identity or workgroup to add to the approval workflow. |
      | [Access Request Decision](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/access-request-decision/) | idn:access-request-post-approval | FIRE_AND_FORGET | After an access request is approved. |
      | [Access Request Submitted](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/access-request-submitted/) | idn:access-request-pre-approval | REQUEST_RESPONSE | After an access request is submitted. Expects the subscriber to respond with an approval decision. |
      | [Account Aggregation Completed](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/account-aggregation-completed/) | idn:account-aggregation-completed | FIRE_AND_FORGET | After an account aggregation completed, terminated, failed. |
      | Account Attributes Changed | idn:account-attributes-changed | FIRE_AND_FORGET | After an account aggregation, and one or more account attributes have changed. |
      | Account Correlated | idn:account-correlated | FIRE_AND_FORGET | After an account is added to an identity. |
      | Accounts Collected for Aggregation |  idn:aggregation-accounts-collected | FIRE_AND_FORGET | New, changed, and deleted accounts have been gathered during an aggregation and are being processed. |
      | Account Uncorrelated | idn:account-uncorrelated | FIRE_AND_FORGET | After an account is removed from an identity. |
      | Campaign Activated | idn:campaign-activated | FIRE_AND_FORGET | After a campaign is activated. |
      | Campaign Ended | idn:campaign-ended | FIRE_AND_FORGET | After a campaign ends. |
      | Campaign Generated | idn:campaign-generated | FIRE_AND_FORGET | After a campaign finishes generating. |
      | Certification Signed Off | idn:certification-signed-off | FIRE_AND_FORGET | After a certification is signed off by its reviewer. |
      | [Identity Attributes Changed](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/account-aggregation-completed/) | idn:identity-attributes-changed | FIRE_AND_FORGET | After One or more identity attributes changed. |
      | [Identity Created](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/identity-created/) | idn:identity-created | FIRE_AND_FORGET | After an identity is created. |
      | [Provisioning Action Completed](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/provisioning-completed/) |  idn:post-provisioning | FIRE_AND_FORGET | After a provisioning action completed on a source. |
      | [Scheduled Search](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/scheduled-search/) |  idn:saved-search-complete | FIRE_AND_FORGET | After a scheduled search completed. |
      | [Source Created](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/source-created/) | idn:source-created | FIRE_AND_FORGET | After a source is created. |
      | [Source Deleted](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/source-deleted/) | idn:source-deleted | FIRE_AND_FORGET | After a source is deleted. |
      | [Source Updated](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/source-updated/) | idn:source-updated | FIRE_AND_FORGET | After configuration changes have been made to a source. |
      | [VA Cluster Status Change](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/va-cluster-status-change/) | idn:va-cluster-status-change | FIRE_AND_FORGET | After the status of a VA cluster has changed. |

      ## Early Access Event Triggers
      Triggers that are in-development and not ready for production use.  Please contact support to enable these triggers in your tenant.

      | Name | ID | Type | Trigger condition |
      |-|-|-|-|
      | [Identity Deleted](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/identity-deleted/) | idn:identity-deleted | FIRE_AND_FORGET | After an identity is deleted. |
      | [Source Account Created](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/source-account-created/) | idn:source-account-created | FIRE_AND_FORGET | After a source account is created. |
      | [Source Account Deleted](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/source-account-deleted/) | idn:source-account-deleted | FIRE_AND_FORGET | After a source account is deleted. |
      | [Source Account Updated](https://developer.sailpoint.com/docs/extensibility/event-triggers/triggers/source-account-updated/) | idn:source-account-updated | FIRE_AND_FORGET | After a source account is changed. |

      Refer to [Event Triggers](https://developer.sailpoint.com/docs/extensibility/event-triggers/) for more information about event triggers.
  - name: Vendor Connector Mappings
    description: |
      Use this API to manage mappings between various SaaS vendors and Identity Security Cloud (ISC) connectors.
  - name: Work Items
    description: |
      Use this API to implement work item functionality.
      With this functionality in place, users can manage their work items (tasks).

      Work items refer to the tasks users see in Identity Security Cloud's Task Manager.
      They can see the pending work items they need to complete, as well as the work items they have already completed.
      Task Manager lists the work items along with the involved sources, identities, accounts, and the timestamp when the work item was created.
      For example, a user may see a pending 'Create an Account' work item for the identity Fred.Astaire in GitHub for Fred's GitHub account, fred-astaire-sp.
      Once the user completes the work item, the work item will be listed with his or her other completed work items.

      To complete work items, users can use their dashboards and select the 'My Tasks' widget.
      The widget will list any work items they need to complete, and they can select the work item from the list to review its details.
      When they complete the work item, they can select 'Mark Complete' to add it to their list of completed work items.

      Refer to [Task Manager](https://documentation.sailpoint.com/saas/user-help/task_manager.html) for more information about work items, including the different types of work items users may need to complete.
  - name: Work Reassignment
    description: |
      Use this API to implement work reassignment functionality.

      Work Reassignment allows access request reviews, certifications, and manual provisioning tasks assigned to a user to be reassigned to a different user. This is primarily used for:

      - Temporarily redirecting work for users who are out of office, such as on vacation or sick leave
      - Permanently redirecting work for users who should not be assigned these tasks at all, such as senior executives or service identities
      
      Users can define reassignments for themselves, managers can add them for their team members, and administrators can configure them on any user’s behalf. Work assigned during the specified reassignment timeframes will be automatically reassigned to the designated user as it is created.
      
      Refer to [Work Reassignment](https://documentation.sailpoint.com/saas/help/users/work_reassignment.html) for more information about this topic.
  - name: Workflows
    description: |
      Workflows allow administrators to create custom automation scripts directly within Identity Security Cloud.  These automation scripts respond to [event triggers](https://developer.sailpoint.com/docs/extensibility/event-triggers/#how-to-get-started-with-event-triggers) and perform a series of actions to perform tasks that are either too cumbersome or not available in the Identity Security Cloud UI.  Workflows can be configured via a graphical user interface within Identity Security Cloud, or by creating and uploading a JSON formatted script to the Workflow service.  The Workflows API collection provides the necessary functionality to create, manage, and test your workflows via REST.

security:
  - UserContextAuth: [ ]

components:
  securitySchemes:
    UserContextAuth:
      type: oauth2
      description: |
        OAuth2 Bearer token (JWT) generated using either a Personal Access token or through the Authorization Code flow. 
        See [Identity Security Cloud REST API Authentication](https://developer.sailpoint.com/docs/api/authentication/) for more information.
        - Directions for generating a [personal access token](https://developer.sailpoint.com/docs/api/authentication/#personal-access-tokens)
        - Directions using [client credentials flow](https://developer.sailpoint.com/docs/api/authentication/#client-credentials-grant-flow)
        - Directions for using [authorization code flow](https://developer.sailpoint.com/docs/api/authentication/#authorization-code-grant-flow)

        Which authentication method should I choose?  See the [guide](https://developer.sailpoint.com/docs/api/authentication/#which-oauth-20-grant-flow-should-i-use).

        Learn more about how to find your `tokenUrl` and `authorizationUrl` [in the docs](https://developer.sailpoint.com/docs/api/authentication/#find-your-tenants-oauth-details).
      flows:
        clientCredentials:
          tokenUrl: https://tenant.api.identitynow.com/oauth/token
          scopes:
            "sp:scopes:default": "default scope"
            "sp:scopes:all": "access to all scopes"
        authorizationCode:
          authorizationUrl: https://tenant.login.sailpoint.com/oauth/authorize
          tokenUrl: https://tenant.api.identitynow.com/oauth/token
          scopes:
            "sp:scopes:default": "default scope"
            "sp:scopes:all": "access to all scopes"
    ApplicationOnlyAuth:
      type: oauth2
      description: |
        OAuth2 Bearer token (JWT) generated using client credentials flow. 
        See [Identity Security Cloud REST API Authentication](https://developer.sailpoint.com/docs/api/authentication/) for more information.
        - Directions using [client credentials flow](https://developer.sailpoint.com/docs/api/authentication/#client-credentials-grant-flow)

        Which authentication method should I choose?  See the [guide](https://developer.sailpoint.com/docs/api/authentication/#which-oauth-20-grant-flow-should-i-use).

        Learn more about how to find your `tokenUrl` and `authorizationUrl` [in the docs](https://developer.sailpoint.com/docs/api/authentication/#find-your-tenants-oauth-details).
      flows:
        clientCredentials:
          tokenUrl: https://tenant.api.identitynow.com/oauth/token
          scopes:
            "sp:scopes:default": "default scope"
  schemas:
    AccountAggregation:
      $ref: './beta/schemas/AccountAggregationStatus.yaml'
    ApprovalItems:
      $ref: './beta/schemas/ApprovalItemDetails.yaml'
    slimcampaign:
      $ref: './beta/schemas/SlimCampaign.yaml'
    fullcampaign:
      $ref: './beta/schemas/Campaign.yaml'
    IdentityProfile:
      $ref: './beta/schemas/IdentityProfile.yaml'
    ManagedClient:
      $ref: './beta/schemas/ManagedClient.yaml'
    ManagedClientStatus:
      $ref: './beta/schemas/ManagedClientStatus.yaml'
    MessageCatalogDto:
      $ref: './beta/schemas/MessageCatalogDto.yaml'
    PeerGroupMember:
      $ref: './beta/schemas/PeerGroupMember.yaml'
    RecommendationRequestDto:
      $ref: './beta/schemas/RecommendationRequestDto.yaml'
    RecommendationResponseDto:
      $ref: './beta/schemas/RecommendationResponseDto.yaml'
    RemediationItems:
      $ref: './beta/schemas/RemediationItemDetails.yaml'
    SearchAttributeConfig:
      $ref: './beta/schemas/SearchAttributeConfig.yaml'
    WorkItems:
      $ref: './beta/schemas/WorkItems.yaml'
    WorkItemsCount:
      $ref: './beta/schemas/WorkItemsCount.yaml'
    WorkItemsSummary:
      $ref: './beta/schemas/WorkItemsSummary.yaml'
    Form:
      $ref: './beta/schemas/FormDetails.yaml'
    FormItem:
      $ref: './beta/schemas/FormItemDetails.yaml'
    Section:
      $ref: './beta/schemas/SectionDetails.yaml'
    Field:
      $ref: './beta/schemas/FieldDetails.yaml'
    AccountUsage:
      $ref: './beta/schemas/AccountUsage.yaml'
    SourceUsage:
      $ref: './beta/schemas/SourceUsage.yaml'
    SourceUsageStatus:
      $ref: './beta/schemas/SourceUsageStatus.yaml'

paths:
  /access-profiles:
    $ref: './beta/paths/access-profiles.yaml'
  /access-profiles/{id}:
    $ref: './beta/paths/access-profile.yaml'
  /access-profiles/bulk-delete:
    $ref: './beta/paths/access-profile-bulk-delete.yaml'
  /access-profiles/bulk-update-requestable:
    $ref: './beta/paths/access-profile-bulk-update-requestable.yaml'
  /access-profiles/{id}/entitlements:
    $ref: './beta/paths/access-profile-entitlements.yaml'
  /access-requests:
    $ref: './v3/paths/access-requests.yaml'
  /access-requests/cancel:
    $ref: './v3/paths/access-request-cancel.yaml'
  /access-requests/close:
    $ref: './v3/paths/access-request-close.yaml'
  /access-request-config:
    $ref: './v3/paths/access-request-config.yaml'
  /access-request-status:
    $ref: './v3/paths/access-request-status.yaml'
  /access-request-approvals/pending:
    $ref: './beta/paths/pending-access-request-approvals.yaml'
  /access-request-approvals/completed:
    $ref: './beta/paths/completed-access-request-approvals.yaml'
  /access-request-approvals/{approvalId}/approve:
    $ref: './beta/paths/approve-access-request-approval.yaml'
  /access-request-approvals/{approvalId}/reject:
    $ref: './beta/paths/reject-access-request-approval.yaml'
  /access-request-approvals/{approvalId}/forward:
    $ref: './beta/paths/forward-access-request-approval.yaml'
  /access-request-approvals/approval-summary:
    $ref: './beta/paths/access-request-approval-summary.yaml'
  /ai-access-request-recommendations:
    $ref: './beta/paths/ai-access-request-recommendations.yaml'
  /ai-access-request-recommendations/ignored-items:
    $ref: './beta/paths/ai-access-request-recommendations-ignored.yaml'
  /ai-access-request-recommendations/requested-items:
    $ref: './beta/paths/ai-access-request-recommendations-requested.yaml'
  /ai-access-request-recommendations/viewed-items:
    $ref: './beta/paths/ai-access-request-recommendations-viewed.yaml'
  /ai-access-request-recommendations/viewed-items/bulk-create:
    $ref: './beta/paths/ai-access-request-recommendations-viewed-bulk-create.yaml'
  /accounts:
    $ref: './beta/paths/accounts.yaml'
  /accounts/{id}:
    $ref: './beta/paths/account.yaml'
  /accounts/{id}/entitlements:
    $ref: './beta/paths/accounts-id-entitlements.yaml'
  /accounts/{id}/reload:
    $ref: './beta/paths/accounts-id-reload.yaml'
  /accounts/{id}/enable:
    $ref: './beta/paths/accounts-id-enable.yaml'
  /accounts/{id}/disable:
    $ref: './beta/paths/accounts-id-disable.yaml'
  /accounts/{id}/unlock:
    $ref: './beta/paths/accounts-id-unlock.yaml'
  /accounts/{id}/remove:
    $ref: './beta/paths/remove-account.yaml'
  /identities-accounts/{id}/enable:
    $ref: './beta/paths/identity-accounts-id-enable.yaml'
  /identities-accounts/{id}/disable:
    $ref: './beta/paths/identity-accounts-id-disable.yaml'
  /identities-accounts/enable:
    $ref: './beta/paths/identities-accounts-enable.yaml'
  /identities-accounts/disable:
    $ref: './beta/paths/identities-accounts-disable.yaml'
  /accounts/search-attribute-config:
    $ref: './beta/paths/searchAttributeConfig.yaml'
  /accounts/search-attribute-config/{name}:
    $ref: './beta/paths/searchAttributeConfig-get-patch-delete.yaml'
  /account-activities:
    $ref: './beta/paths/account-activities.yaml'
  /account-activities/{id}:
    $ref: './beta/paths/account-activity.yaml'
  /account-aggregations/{id}/status:
    $ref: './beta/paths/account-aggregation-status.yaml'
  /auth-profiles:
    $ref: './beta/paths/auth-profiles.yaml'
  /auth-profiles/{id}:
    $ref: './beta/paths/auth-profile.yaml'
  /campaigns:
    $ref: './beta/paths/campaigns.yaml'
  /campaigns/delete:
    $ref: './beta/paths/campaigns-delete.yaml'
  /campaigns/{id}:
    $ref: './beta/paths/campaign.yaml'
  /campaigns/{id}/activate:
    $ref: './beta/paths/campaign-activate.yaml'
  /campaigns/{id}/complete:
    $ref: './beta/paths/campaign-complete.yaml'
  /campaigns/{id}/run-remediation-scan:
    $ref: './beta/paths/campaign-run-remediation-scan.yaml'
  /campaigns/{id}/reassign:
    $ref: './beta/paths/campaign-admin-cert-reassign.yaml'
  /campaigns/{id}/reports:
    $ref: './beta/paths/campaign-reports.yaml'
  /campaigns/{id}/run-report/{type}:
    $ref: './beta/paths/campaign-run-report.yaml'
  /campaigns/reports-configuration:
    $ref: './beta/paths/campaign-reports-configuration.yaml'
  /campaign-templates:
    $ref: './beta/paths/campaign-templates.yaml'
  /campaign-templates/{id}:
    $ref: './beta/paths/campaign-template.yaml'
  /campaign-templates/{id}/generate:
    $ref: './beta/paths/campaign-template-generate.yaml'
  /campaign-templates/{id}/schedule:
    $ref: './beta/paths/campaign-template-schedule.yaml'
  /certifications/{id}/reassign-async:
    $ref: './beta/paths/identity-certifications-reassign-async.yaml'
  /certifications/{id}/tasks/{taskId}:
    $ref: './beta/paths/identity-certifications-task-status.yaml'
  /certifications/{id}/tasks-pending:
    $ref: './beta/paths/identity-certifications-tasks-pending.yaml'
  /certifications/{certificationId}/access-review-items/{itemId}/permissions:
    $ref: './beta/paths/identity-certifications-item-permissions.yaml'
  /certifications/{id}/reviewers:
    $ref: './beta/paths/certifications-reviewers.yaml'
  /connector-rules:
    $ref: './beta/paths/connector-rules.yaml'
  /connector-rules/{id}:
    $ref: './beta/paths/connector-rule.yaml'
  /connector-rules/validate:
    $ref: './beta/paths/connector-rule-validate.yaml'
  /connectors:
    $ref: './beta/paths/connectors.yaml'
  /custom-password-instructions:
    $ref: './beta/paths/custom-password-instructions.yaml'
  /custom-password-instructions/{pageId}:
    $ref: './beta/paths/custom-password-instruction.yaml'
  /entitlements:
    $ref: './beta/paths/entitlements.yaml'
  /entitlements/{id}:
    $ref: './beta/paths/ears-entitlement.yaml'
  /entitlements/{id}/parents:
    $ref: './beta/paths/ears-entitlement-parents.yaml'
  /entitlements/{id}/children:
    $ref: './beta/paths/ears-entitlement-children.yaml'
  /entitlements/bulk-update:
    $ref: './beta/paths/ears-entitlement-bulk-update.yaml'
  /entitlements/{id}/entitlement-request-config:
    $ref: "./beta/paths/entitlement-request-config.yaml"
  /entitlements/reset/sources/{id}:
    $ref: './beta/paths/reset-entitlements.yaml'
  /entitlements/aggregate/sources/{id}:
    $ref: "./beta/paths/load-entitlements.yaml"
  /generate-password-reset-token/digit:
    $ref: './beta/paths/password-reset-digit-token.yaml'
  /historical-identities:
    $ref: './beta/paths/historical-identities.yaml'
  /historical-identities/{id}:
    $ref: './beta/paths/historical-identity.yaml'
  /historical-identities/{id}/access-items:
    $ref: './beta/paths/historical-identity-access-items.yaml'
  /historical-identities/{id}/snapshots:
    $ref: './beta/paths/historical-identity-snapshots.yaml'
  /historical-identities/{id}/snapshot-summary:
    $ref: './beta/paths/historical-identity-snapshot-summary.yaml'
  /historical-identities/{id}/snapshots/{date}:
    $ref: './beta/paths/historical-identity-snapshot-date.yaml'
  /historical-identities/{id}/snapshots/{date}/access-items:
    $ref: './beta/paths/historical-identity-snapshot-date-access-items.yaml'
  /common-access:
    $ref: './beta/paths/common-access.yaml'
  /common-access/update-status:
    $ref: './beta/paths/common-access-update-status.yaml'
  /historical-identities/{id}/events:
    $ref: './beta/paths/historical-identity-events.yaml'
  /historical-identities/{id}/start-date:
    $ref: './beta/paths/historical-identity-start-date.yaml'
  /historical-identities/{id}/compare:
    $ref: './beta/paths/historical-identity-compare.yaml'
  /historical-identities/{id}/compare/{access-type}:
    $ref: './beta/paths/historical-identity-compare-type.yaml'
  /identities/{identityId}/synchronize-attributes:
    $ref: './beta/paths/identity-synchronize-attributes.yaml'
  /identities/{identityId}/ownership:
    $ref: './beta/paths/identity-ownership.yaml'
  /identities:
    $ref: './beta/paths/identities.yaml'
  /identities/{id}:
    $ref: './beta/paths/identity.yaml'
  /identities/process:
    $ref: './beta/paths/identities-process.yaml'
  /identities/{id}/reset:
    $ref: './beta/paths/identity-reset.yaml'
  /identities/{identityId}/role-assignments/{assignmentId}:
    $ref: './beta/paths/identities-role-assignment.yaml'
  /identities/{identityId}/role-assignments:
    $ref: './beta/paths/identities-role-assignments.yaml'
  /identity-attributes:
    $ref: './beta/paths/identity-attributes.yaml'
  /identity-attributes/{name}:
    $ref: './beta/paths/identity-attribute.yaml'
  /identity-attributes/bulk-delete:
    $ref: './beta/paths/identity-attributes-bulk-delete.yaml'
  /identity-profiles:
    $ref: './beta/paths/identity-profiles.yaml'
  /identity-profiles/bulk-delete:
    $ref: './beta/paths/identity-profiles-bulk-delete.yaml'
  /identity-profiles/export:
    $ref: './beta/paths/identity-profiles-export.yaml'
  /identity-profiles/import:
    $ref: './beta/paths/identity-profiles-import.yaml'
  /identity-profiles/identity-preview:
    $ref: './beta/paths/identity-profiles-identity-preview.yaml'
  /identity-profiles/{identity-profile-id}:
    $ref: './beta/paths/identity-profile.yaml'
  /identity-profiles/{identity-profile-id}/default-identity-attribute-config:
    $ref: './beta/paths/identity-profile-default-config.yaml'
  /identity-profiles/{identity-profile-id}/process-identities:
    $ref: './beta/paths/identity-profile-process-identities.yaml'
  /identity-profiles/{identity-profile-id}/lifecycle-states/{lifecycle-state-id}:
    $ref: './beta/paths/identity-profile-lifecycle-state.yaml'
  /non-employee-records:
    $ref: './beta/paths/non-employee-records.yaml'
  /non-employee-records/{id}:
    $ref: './beta/paths/non-employee-record.yaml'
  /non-employee-records/bulk-delete:
    $ref: './beta/paths/non-employee-records-bulk-delete.yaml'
  /non-employee-requests:
    $ref: './beta/paths/non-employee-requests.yaml'
  /non-employee-requests/{id}:
    $ref: './beta/paths/non-employee-request.yaml'
  /non-employee-requests/summary/{requested-for}:
    $ref: './beta/paths/non-employee-request-summary-get.yaml'
  /non-employee-sources:
    $ref: './beta/paths/non-employee-sources.yaml'
  /non-employee-sources/{sourceId}:
    $ref: './beta/paths/non-employee-source.yaml'
  /non-employee-sources/{id}/non-employees/download:
    $ref: './beta/paths/non-employee-sources-export-non-employees.yaml'
  /non-employee-sources/{id}/non-employee-bulk-upload:
    $ref: './beta/paths/non-employee-sources-bulk-upload-non-employees.yaml'
  /non-employee-sources/{id}/non-employee-bulk-upload/status:
    $ref: './beta/paths/non-employee-sources-bulk-upload-status.yaml'
  /non-employee-sources/{id}/schema-attributes-template/download:
    $ref: './beta/paths/non-employee-sources-export-schema-attributes-template.yaml'
  /non-employee-approvals:
    $ref: './beta/paths/non-employee-approval-list.yaml'
  /non-employee-approvals/{id}:
    $ref: './beta/paths/non-employee-approve-get.yaml'
  /non-employee-approvals/{id}/approve:
    $ref: './beta/paths/non-employee-approve-request.yaml'
  /non-employee-approvals/{id}/reject:
    $ref: './beta/paths/non-employee-reject-request.yaml'
  /non-employee-approvals/summary/{requested-for}:
    $ref: './beta/paths/non-employee-approval-summary.yaml'
  /non-employee-sources/{sourceId}/schema-attributes:
    $ref: './beta/paths/non-employee-sources-schema-attributes.yaml'
  /non-employee-sources/{sourceId}/schema-attributes/{attributeId}:
    $ref: './beta/paths/non-employee-sources-schema-attribute.yaml'
  /managed-clients/{id}/status:
    $ref: './beta/paths/managed-client-status.yaml'
  /managed-clusters/{id}:
    $ref: './beta/paths/managed-cluster-path.yaml'
  /managed-clusters/{id}/log-config:
    $ref: './beta/paths/managed-cluster-log-config.yaml'
  /managed-clusters:
    $ref: './beta/paths/managed-clusters.yaml'
  /mail-from-attributes:
    $ref: './beta/paths/mail-from-attributes.yaml'
  /mail-from-attributes/{identity}:
    $ref: './beta/paths/mail-from-attribute.yaml'
  /approvals:
    $ref: './beta/paths/approvals.yaml'
  /approvals/{id}:
    $ref: './beta/paths/approval.yaml'
  /mfa/okta-verify/config:
    $ref: './beta/paths/mfa-okta-config.yaml'
  /mfa/duo-web/config:
    $ref: './beta/paths/mfa-duo-config.yaml'
  /mfa/kba/config:
    $ref: './beta/paths/mfa-kba-config.yaml'
  /mfa/kba/config/answers:
    $ref: './beta/paths/mfa-kba-config-answers.yaml'
  /mfa/{method}/test:
    $ref: './beta/paths/mfa-config-test.yaml'
  /mfa/{method}/delete:
    $ref: './beta/paths/mfa-config-delete.yaml'
  /mfa/okta-verify/verify:
    $ref: './beta/paths/mfa-okta-verify.yaml'
  /mfa/duo-web/verify:
    $ref: './beta/paths/mfa-duo-verify.yaml'
  /mfa/{method}/poll:
    $ref: './beta/paths/mfa-poll.yaml'
  /mfa/kba/authenticate:
    $ref: './beta/paths/mfa-kba-authenticate.yaml'
  /mfa/token/authenticate:
    $ref: './beta/paths/mfa-token-authenticate.yaml'
  /mfa/token/send:
    $ref: './beta/paths/mfa-token-send.yaml'
  /notification-template-defaults:
    $ref: './beta/paths/notification-template-defaults.yaml'
  /notification-templates:
    $ref: './beta/paths/notification-templates.yaml'
  /notification-templates/{id}:
    $ref: './beta/paths/notification-template.yaml'
  /notification-templates/bulk-delete:
    $ref: './beta/paths/notification-templates-bulk-delete.yaml'
  /oauth-clients:
    $ref: './beta/paths/oauth-clients.yaml'
  /oauth-clients/{id}:
    $ref: './beta/paths/oauth-client.yaml'
  /org-config:
    $ref: './beta/paths/org-config.yaml'
  /org-config/valid-time-zones:
    $ref: './beta/paths/org-config-valid-time-zones.yaml'
  /outlier-summaries:
    $ref: './beta/paths/outlier-summaries.yaml'
  /outlier-summaries/latest:
    $ref: './beta/paths/outlier-summaries-latest.yaml'
  /outliers:
    $ref: './beta/paths/outliers.yaml'
  /outliers/{outlierId}/contributing-features:
    $ref: './beta/paths/outliers-contributing-features.yaml'
  /outliers/{outlierId}/feature-details/{contributingFeatureName}/access-items:
    $ref: './beta/paths/outliers-contributing-feature-access-items.yaml'
  /outliers/ignore:
    $ref: './beta/paths/outliers-ignore.yaml'
  /outliers/unignore:
    $ref: './beta/paths/outliers-unignore.yaml'
  /outliers/export:
    $ref: './beta/paths/outliers-export.yaml'
  /outlier-feature-summaries/{outlierFeatureId}:
    $ref: './beta/paths/outlier-feature-summaries.yaml'
  /password-dictionary:
    $ref: './v3/paths/password-dictionary.yaml'
  /query-password-info:
    $ref: './beta/paths/query-password-info.yaml'
  /set-password:
    $ref: './beta/paths/set-password.yaml'
  /password-change-status/{id}:
    $ref: './beta/paths/password-change-status.yaml'
  /password-sync-groups:
    $ref: './v3/paths/password-sync-groups.yaml'
  /password-sync-groups/{id}:
    $ref: './v3/paths/password-sync-group.yaml'
  /password-org-config:
    $ref: './v3/paths/password-org-config.yaml'
  /peer-group-strategies/{strategy}/identity-outliers:
    $ref: './beta/paths/peer-group-strategies.yaml'
  /personal-access-tokens:
    $ref: './beta/paths/personal-access-tokens.yaml'
  /personal-access-tokens/{id}:
    $ref: './beta/paths/personal-access-token.yaml'
  /public-identities-config:
    $ref: './beta/paths/public-identities-config.yaml'
  /notification-template-context:
    $ref: './beta/paths/notification-template-context.yaml'
  /notification-preferences/{key}:
    $ref: './beta/paths/notification-preferences.yaml'
  /reassignment-configurations/types:
    $ref: './beta/paths/reassignment-configuration-types.yaml'
  /reassignment-configurations:
    $ref: './beta/paths/reassignment-configurations.yaml'
  /reassignment-configurations/{identityId}:
    $ref: './beta/paths/reassignment-configuration.yaml'
  /reassignment-configurations/{identityId}/evaluate/{configType}:
    $ref: './beta/paths/reassignment-configuration-evaluate.yaml'
  /reassignment-configurations/tenant-config:
    $ref: './beta/paths/tenant-configuration.yaml'
  /recommendations/request:
    $ref: './beta/paths/recommendations-request.yaml'
  /recommendations/config:
    $ref: './beta/paths/recommendations-config.yaml'
  /requestable-objects:
    $ref: './v3/paths/requestable-object-list.yaml'
  /role-insights/requests:
    $ref: './beta/paths/role-insights-requests.yaml'
  /role-insights/requests/{id}:
    $ref: './beta/paths/role-insights-request.yaml'
  /role-insights/summary:
    $ref: './beta/paths/role-insights-summary.yaml'
  /role-insights:
    $ref: './beta/paths/role-insights.yaml'
  /role-insights/{insightId}:
    $ref: './beta/paths/role-insight.yaml'
  /role-insights/{insightId}/entitlement-changes:
    $ref: './beta/paths/role-insights-entitlement-changes.yaml'
  /role-insights/{insightId}/entitlement-changes/download:
    $ref: './beta/paths/role-insights-entitlement-changes-download.yaml'
  /role-insights/{insightId}/current-entitlements:
    $ref: './beta/paths/role-insights-current-entitlements.yaml'
  /role-insights/{insightId}/entitlement-changes/{entitlementId}/identities:
    $ref: './beta/paths/role-insights-entitlement-changes-identities.yaml'
  /role-mining-sessions:
    $ref: './beta/paths/role-mining-sessions.yaml'
  /role-mining-sessions/{sessionId}:
    $ref: './beta/paths/role-mining-session.yaml'
  /role-mining-sessions/{sessionId}/status:
    $ref: './beta/paths/role-mining-session-status.yaml'
  /role-mining-sessions/{sessionId}/potential-role-summaries:
    $ref: './beta/paths/role-mining-session-potential-role-summaries.yaml'
  /role-mining-sessions/{sessionId}/potential-role-summaries/{potentialRoleId}:
    $ref: './beta/paths/role-mining-session-potential-role-summary.yaml'
  /role-mining-sessions/{sessionId}/potential-role-summaries/{potentialRoleId}/applications:
    $ref: './beta/paths/role-mining-session-potential-role-applications.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/entitlement-popularities:
    $ref: './beta/paths/role-mining-potential-role-entitlement-popularities.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/entitlement-popularity-distribution:
    $ref: './beta/paths/role-mining-potential-role-entitlement-popularity-distribution.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/edit-entitlements:
    $ref: './beta/paths/role-mining-potential-role-edit-entitlements.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/identities:
    $ref: './beta/paths/role-mining-potential-role-identities.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/export:
    $ref: './beta/paths/role-mining-session-potential-role-export.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/export-async:
    $ref: './beta/paths/role-mining-session-potential-role-export-async.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/export-async/{exportId}:
    $ref: './beta/paths/role-mining-session-potential-role-export-status.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/export-async/{exportId}/download:
    $ref: './beta/paths/role-mining-session-potential-role-export-download.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/provision:
    $ref: './beta/paths/role-mining-potential-role-provision.yaml'
  /role-mining-sessions/{sessionId}/potential-roles/{potentialRoleId}/excluded-entitlements:
    $ref: './beta/paths/role-mining-potential-role-excluded-entitlements.yaml'
  /role-mining-potential-roles:
    $ref: './beta/paths/role-mining-potential-role-summaries.yaml'
  /role-mining-potential-roles/{potentialRoleId}:
    $ref: './beta/paths/role-mining-potential-role.yaml'
  /role-mining-potential-roles/saved:
    $ref: './beta/paths/role-mining-potential-roles-draft.yaml'
  /role-mining-potential-roles/{potentialRoleId}/sources/{sourceId}/identityUsage:
    $ref: './beta/paths/role-mining-potential-role-source-identity-usage.yaml'
  /roles:
    $ref: './beta/paths/roles.yaml'
  /roles/{id}:
    $ref: './beta/paths/role.yaml'
  /roles/bulk-delete:
    $ref: './beta/paths/role-bulk-delete.yaml'
  /roles/{id}/assigned-identities:
    $ref: './beta/paths/role-assigned-identities.yaml'
  /roles/{id}/entitlements:
    $ref: './beta/paths/role-entitlements.yaml'
  /segments:
    $ref: './beta/paths/segments.yaml'
  /segments/{id}:
    $ref: './beta/paths/segment.yaml'
  /send-test-notification:
    $ref: './beta/paths/send-test-notification.yaml'
  /service-desk-integrations:
    $ref: './beta/paths/service-desk-integrations.yaml'
  /service-desk-integrations/{id}:
    $ref: './beta/paths/service-desk-integration.yaml'
  /service-desk-integrations/types:
    $ref: './beta/paths/service-desk-integration-types.yaml'
  /service-desk-integrations/templates/{scriptName}:
    $ref: './beta/paths/service-desk-integration-template.yaml'
  /service-desk-integrations/status-check-configuration:
    $ref: './beta/paths/service-desk-integration-configuration.yaml'
  /sp-config/export:
    $ref: './beta/paths/sp-config-export.yaml'
  /sp-config/export/{id}:
    $ref: './beta/paths/sp-config-export-status.yaml'
  /sp-config/export/{id}/download:
    $ref: './beta/paths/sp-config-export-download.yaml'
  /sp-config/import:
    $ref: './beta/paths/sp-config-import.yaml'
  /sp-config/import/{id}:
    $ref: './beta/paths/sp-config-import-status.yaml'
  /sp-config/import/{id}/download:
    $ref: './beta/paths/sp-config-import-download.yaml'
  /sp-config/config-objects:
    $ref: './beta/paths/sp-config-objects.yaml'
  /sources:
    $ref: './beta/paths/sources.yaml'
  /sources/{id}:
    $ref: './beta/paths/source.yaml'
  /sources/{id}/attribute-sync-config:
    $ref: './beta/paths/attr-sync-config-source.yaml'
  /sources/{sourceId}/connector/check-connection:
    $ref: './beta/paths/source-connector-check-connection.yaml'
  /sources/{sourceId}/connector/peek-resource-objects:
    $ref: './beta/paths/source-connector-peek-resource-objects.yaml'
  /sources/{sourceId}/connector/ping-cluster:
    $ref: './beta/paths/source-connector-ping-cluster.yaml'
  /sources/{sourceId}/connector/test-configuration:
    $ref: './beta/paths/source-connector-test-configuration.yaml'
  /sources/{id}/connectors/source-config:
    $ref: './beta/paths/source-connectors-source-config.yaml'
  /sources/{sourceId}/native-change-detection-config:
    $ref: './beta/paths/native-change-detection-config.yaml'
  /sources/{sourceId}/provisioning-policies:
    $ref: './v3/paths/provisioning-policies.yaml'
  /sources/{sourceId}/provisioning-policies/{usageType}:
    $ref: './v3/paths/provisioning-policy.yaml'
  /sources/{sourceId}/provisioning-policies/bulk-update:
    $ref: './v3/paths/provisioning-policies-bulk-update.yaml'
  /sources/{id}/remove-accounts:
    $ref: './beta/paths/remove-accounts.yaml'
  /sources/{sourceId}/schemas:
    $ref: './beta/paths/schemas.yaml'
  /sources/{sourceId}/schemas/{schemaId}:
    $ref: './beta/paths/schema.yaml'
  /sources/{id}/schemas/accounts:
    $ref: './beta/paths/source-accounts-schema.yaml'
  /sources/{id}/schemas/entitlements:
    $ref: './beta/paths/source-entitlements-schema.yaml'
  /sources/{sourceId}/upload-connector-file:
    $ref: './beta/paths/source-upload-connector-file.yaml'
  /sources/{id}/synchronize-attributes:
    $ref: './beta/paths/source-synchronize-attributes.yaml'
  /sources/{id}/entitlement-request-config:
    $ref: './beta/paths/sources-entitlement-request-config.yaml'
  /sources/{id}/load-accounts:
    $ref: './beta/paths/load-accounts.yaml'
  /task-status/{id}:
    $ref: "./beta/paths/task-status.yaml"
  /task-status:
    $ref: "./beta/paths/task-status-list.yaml"
  /task-status/pending-tasks:
    $ref: "./beta/paths/task-status-pending.yaml"
  /tagged-objects:
    $ref: './beta/paths/tagged-objects.yaml'
  /tagged-objects/{type}:
    $ref: './beta/paths/tagged-objects-type.yaml'
  /tagged-objects/{type}/{id}:
    $ref: './beta/paths/tagged-object.yaml'
  /tagged-objects/bulk-add:
    $ref: './beta/paths/bulk-add-tagged-objects.yaml'
  /tagged-objects/bulk-remove:
    $ref: './beta/paths/bulk-remove-tagged-objects.yaml'
  /tenant:
    $ref: './beta/paths/tenant.yaml'
  /transforms:
    $ref: './beta/paths/transforms.yaml'
  /transforms/{id}:
    $ref: './beta/paths/transform.yaml'
  /translation-catalogs/{catalog-id}:
    $ref: './beta/paths/message-catalog.yaml'
  /triggers:
    $ref: './beta/paths/triggers.yaml'
  /trigger-subscriptions:
    $ref: './beta/paths/trigger-subscriptions.yaml'
  /trigger-subscriptions/{id}:
    $ref: './beta/paths/trigger-subscription.yaml'
  /trigger-subscriptions/validate-filter:
    $ref: './beta/paths/trigger-subscriptions-validate-filter.yaml'
  /trigger-invocations/status:
    $ref: './beta/paths/trigger-invocations-status.yaml'
  /trigger-invocations/{id}/complete:
    $ref: './beta/paths/trigger-invocations-complete.yaml'
  /trigger-invocations/test:
    $ref: './beta/paths/trigger-invocations-test.yaml'
  /verified-from-addresses:
    $ref: './beta/paths/verified-from-addresses.yaml'
  /verified-from-addresses/{id}:
    $ref: './beta/paths/verified-from-address.yaml'
  /verified-domains:
    $ref: './beta/paths/verified-domains.yaml'
  /sod-policies:
    $ref: './beta/paths/sod-policies.yaml'
  /sod-policies/{id}:
    $ref: './beta/paths/sod-policy.yaml'
  /sod-policies/{id}/schedule:
    $ref: './beta/paths/sod-schedule.yaml'
  /sod-policies/{id}/violation-report/run:
    $ref: './beta/paths/sod-report-run.yaml'
  /sod-policies/{id}/violation-report:
    $ref: './beta/paths/sod-violation-report.yaml'
  /sod-violations/predict:
    $ref: './beta/paths/sod/predict-violations.yaml'
  /sod-policies/sod-violation-report-status/{reportResultId}:
    $ref: './beta/paths/sod-violation-report-status.yaml'
  /sod-violation-report/run:
    $ref: './beta/paths/sod-all-report-run.yaml'
  /sod-violation-report:
    $ref: './beta/paths/sod-all-report-status.yaml'
  /sod-violation-report/{reportResultId}/download:
    $ref: './beta/paths/sod-download-default-report.yaml'
  /sod-violation-report/{reportResultId}/download/{fileName}:
    $ref: './beta/paths/sod-download-custom-report.yaml'
  /work-items:
    $ref: './beta/paths/work-items.yaml'
  /work-items/completed:
    $ref: './beta/paths/work-items-completed.yaml'
  /work-items/count:
    $ref: './beta/paths/work-items-count.yaml'
  /work-items/count/completed:
    $ref: './beta/paths/work-items-completed-count.yaml'
  /work-items/summary:
    $ref: './beta/paths/work-items-summary.yaml'
  /work-items/{id}:
    $ref: './beta/paths/work-item.yaml'
  /work-items/{id}/forward:
    $ref: './beta/paths/work-item-forward.yaml'
  /work-items/{id}/approve/{approvalItemId}:
    $ref: './beta/paths/work-items-approve-approval-item.yaml'
  /work-items/{id}/reject/{approvalItemId}:
    $ref: './beta/paths/work-items-reject-approval-item.yaml'
  /work-items/bulk-approve/{id}:
    $ref: './beta/paths/work-items-bulk-approve-approval-item.yaml'
  /work-items/bulk-reject/{id}:
    $ref: './beta/paths/work-items-bulk-reject-approval-item.yaml'
  /work-items/{id}/submit-account-selection:
    $ref: './beta/paths/work-items-account-selection.yaml'
  /workflows:
    $ref: './beta/paths/workflows.yaml'
  /workflows/{id}:
    $ref: './beta/paths/workflow.yaml'
  /workflows/{id}/test:
    $ref: './beta/paths/workflow-test.yaml'
  /workflows/{id}/executions:
    $ref: './beta/paths/workflow-executions.yaml'
  /workflow-executions/{id}:
    $ref: './beta/paths/workflow-execution.yaml'
  /workflow-executions/{id}/history:
    $ref: './beta/paths/workflow-execution-history.yaml'
  /workflow-executions/{id}/cancel:
    $ref: './beta/paths/workflow-execution-cancel.yaml'
  /workflow-library:
    $ref: './beta/paths/workflow-library.yaml'
  /workflow-library/actions:
    $ref: './beta/paths/workflow-library-actions.yaml'
  /workflow-library/triggers:
    $ref: './beta/paths/workflow-library-triggers.yaml'
  /workflow-library/operators:
    $ref: './beta/paths/workflow-library-operators.yaml'
  /workflows/{id}/external/oauth-clients:
    $ref: './beta/paths/workflow-external-oauth-client.yaml'
  /workflows/execute/external/{id}:
    $ref: './beta/paths/workflow-external-execute.yaml'
  /workflows/execute/external/{id}/test:
    $ref: './beta/paths/workflow-external-execute-test.yaml'
  /workgroups:
    $ref: './beta/paths/workgroups/workgroups.yaml'
  /workgroups/{id}:
    $ref: './beta/paths/workgroups/workgroup.yaml'
  /workgroups/bulk-delete:
    $ref: './beta/paths/workgroups/workgroups-bulk-delete.yaml'
  /workgroups/{workgroupId}/connections:
    $ref: './beta/paths/workgroups/connections.yaml'
  /workgroups/{workgroupId}/members:
    $ref: './beta/paths/workgroups/workgroup-members.yaml'
  /workgroups/{workgroupId}/members/bulk-add:
    $ref: './beta/paths/workgroups/bulk-add-workgroup-members.yaml'
  /workgroups/{workgroupId}/members/bulk-delete:
    $ref: './beta/paths/workgroups/bulk-delete-workgroup-members.yaml'
  /form-definitions:
    $ref: './beta/paths/form-definitions.yaml'
  /form-definitions/{formDefinitionID}:
    $ref: './beta/paths/form-definition.yaml'
  /form-definitions/{formDefinitionID}/data-source:
    $ref: './beta/paths/form-definition-data-source.yaml'
  /form-definitions/export:
    $ref: './beta/paths/form-definitions-export.yaml'
  /form-definitions/forms-action-dynamic-schema:
    $ref: './beta/paths/form-definition-forms-action-dynamic-schema.yaml'
  /form-definitions/import:
    $ref: './beta/paths/form-definitions-import.yaml'
  /form-definitions/{formDefinitionID}/upload:
    $ref: './beta/paths/form-definition-files.yaml'
  /form-definitions/{formDefinitionID}/file/{fileID}:
    $ref: './beta/paths/form-definition-file.yaml'
  /form-instances:
    $ref: './beta/paths/form-instances.yaml'
  /form-instances/{formInstanceID}:
    $ref: './beta/paths/form-instance.yaml'
  /form-instances/{formInstanceID}/data-source/{formElementID}:
    $ref: './beta/paths/form-instance-data-source.yaml'
  /form-instances/{formInstanceID}/file/{fileID}:
    $ref: './beta/paths/form-instance-file.yaml'
  /form-definitions/predefined-select-options:
    $ref: './beta/paths/form-definitions-predefined-select-options.yaml'
  /source-usages/{sourceId}/status:
    $ref: "./beta/paths/source-usage-status.yaml"
  /source-usages/{sourceId}/summaries:
    $ref: "./beta/paths/source-usages.yaml"
  /account-usages/{accountId}/summaries:
    $ref: "./beta/paths/account-usages.yaml"
  /access-request-identity-metrics/{identityId}/requested-objects/{requestedObjectId}/type/{type}:
    $ref: "./beta/paths/access-request-identity-metrics.yaml"
  /manual-discover-applications:
    $ref: "./beta/paths/manual-discover-applications.yaml"
  /manual-discover-applications-template:
    $ref: "./beta/paths/manual-discover-applications-template.yaml"
  /discovered-applications:
    $ref: "./beta/paths/discovered-applications.yaml"
  /vendor-connector-mappings:
    $ref: "./beta/paths/vendor-connector-mappings.yaml"
  /icons/{objectType}/{objectId}:
    $ref: './beta/paths/icon.yaml'
  /suggested-entitlement-description-batches/{batchId}/stats:
    $ref: "./beta/paths/suggested-entitlement-description-batches-stats.yaml"
  /suggested-entitlement-description-batches:
    $ref: "./beta/paths/suggested-entitlement-description-batches.yaml"
  /suggested-entitlement-description-approvals:
    $ref: "./beta/paths/suggested-entitlement-description-approvals.yaml"
  /suggested-entitlement-description-assignments:
    $ref: "./beta/paths/suggested-entitlement-description-assignments.yaml"
  /suggested-entitlement-descriptions:
    $ref: "./beta/paths/suggested-entitlement-descriptions.yaml"