Integration Permissions

The Integration Permissions option in the Permissions section of an integration establish the system permissions for the entire integration. There are the following base permissions, described below: Owner, Auto Approved, Requestable, and Rotatable. The permissions are enabled with inheritance, and provide the established value in the downward direction: from the integration to the resource, to an entitlement or an account.

The integration permissions can also inherit a value from the upward object which is the Default Approver. In case when the value is inherited, its icon is grey, or otherwise blue, meaning that it was directly established.

Integration Permissions

At the integration level, the following system permissions can be established:

Property	Description
Owner	A workgroup or an identity can be selected as the integration owner. The owner will be asked to provide an approval for an access request.
Auto Approved	It enables or disables the capability to bypass the approval process and make an access request automatically approved. If `Yes` is established, an access request is approved automatically without asking anybody. If `No` is established, then the approval process defines who should be asked for a decision and sends an approval request to the approver. For example, `No` is established for the integration. When an access request was triggered to provision access to the resource of the current integration, then the approval strategy can ask the resource owner for an approval. Assuming that the resource owner is not established and the resource inherits `No` for the Auto Approve permission from the integration, then the integration owner is asked for an approval, according to the inheritance chain. And if it is `Yes` that is established for the integration. When an access request was triggered to provision access to the resource of the current integration, then the approval strategy can ask the resource owner for an approval. Assuming that the resource inherits `Yes` from the integration, then the access request gets automatically approved, according to the inheritance chain.
Requestable	It enables or disables the capability to request access to the integration. If `No` is established for the Requestable permission for the integration, then none of the accounts and\or none of the entitlements that pertain to this integration can be provisioned, and the integration with all its resources and entitlements become completely removed from all workflows, unless any specific resource or entitlement has an explicit `Yes` established for their respective Requestable permissions. If `Yes` is established for the Requestable permission for the integration, then the entitlements and resources of the integration are available for selection in the workflows and accounts can be created or provisioned with access, unless any of the Resources, or Entitlements, or Accounts have an explicit `No` established for their Requestable permissions.
Rotatable	It enables or disables the passwords to the accounts of the integration to be deleted and established anew. If `No` is established for the Rotatable permission for the integration, then the workflows cannot rotate the credentials for the accounts of the integration, unless the resource that an account pertains to, or a specific account have been established with the direct explicit `Yes` option for their Rotatable permission. If `Yes` is established for the Rotatable permission for the integration, then the workflows can rotate the credentials, unless a resource or an account have an explicit `No` for their Rotatable permission.
Remember to click the Save button, to save the changes.