created

docs/idn_docs/triggers/available-event-triggers/access-request-dynamic-approval-event-trigger.md

@@ -0,0 +1,93 @@
+---
+id: access-request-dynamic-approval-event-trigger
+title: Access Request Dynamic Approval Event Trigger
+sidebar_label: Access Request Dynamic Approval Event Trigger
+sidebar-position: 2
+---
+
+# Access Request Dynamic Approval Event Trigger
+
+## Event context
+
+The Access Request Dynamic Approval event trigger provides a way to route a request to an additional approval step by an identity or a governance group.
+
+When an access request is submitted, the Access Request Dynamic Approval trigger:
+
+- Sends data about the access request and expects a response that includes the ID of an existing identity or workgroup (i.e. governance group) to add to the approval workflow
+- Based on the ID received, an approval task will be assigned to the identity or governance group in IdentityNow for a decision as an additional step after other configured approval requirements
+- If the new approver is also the target identity for this request, the manager is assigned instead. If the identity has no manager, a random org admin is assigned.
+- If the ID of the additional approver is wrong, then a random org admin is assigned.
+- You can choose to **NOT** add an additional approver by providing an empty object as the
+response to the triggered REST request.
+
+This trigger can be used to develop logic outside of IdentityNow’s out-of-the-box offerings to route an approval step to users such as:
+
+- The recipient’s department head
+- The recipient’s cost center
+- A security officer
+- A high-risk governance group for highly sensitive roles
+
+## Configuration
+
+This is a `REQUEST_RESPONSE` type trigger.  For general information on how to respond to a `REQUEST_RESPONSE` type trigger, see [responding to a request response type trigger](../event-triggers-responding-to-a-request-response-trigger.md).  This trigger intercepts newly submitted access requests and allows the subscribing service to add one additional identity or governance group as the last step in the approver list for the access request.
+
+The subscribing service will receive the following input from the trigger service.  The input schema can be found in the [API specification](https://developer.sailpoint.com/apis/beta/#section/Access-Request-Dynamic-Approver-Event-Trigger-Input):
+
+```json
+{
+  "accessRequestId": "4b4d982dddff4267ab12f0f1e72b5a6d",
+  "requestedFor": {
+    "type": "IDENTITY",
+    "id": "2c91808568c529c60168cca6f90c1313",
+    "name": "William Wilson"
+  },
+  "requestedItems": [
+    {
+      "id": "2c91808b6ef1d43e016efba0ce470904",
+      "name": "Engineering Access",
+      "description": "Engineering Access",
+      "type": "ACCESS_PROFILE",
+      "operation": "Add",
+      "comment": "William needs this access for his day to day job activities."
+    }
+  ],
+  "requestedBy": {
+    "type": "IDENTITY",
+    "id": "2c91808568c529c60168cca6f90c1314",
+    "name": "Billy Bob"
+  }
+}
+```
+
+The subscribing service can use this information to make a decision on whether to add additional approvers to the access request.  The output schema can be found in the [API specification](https://developer.sailpoint.com/apis/beta/#section/Access-Request-Dynamic-Approver-Event-Trigger-Output).  To add an identity to the approver list, the subscribing service should respond to the event trigger with the following payload:
+
+```json
+{
+  "id": "2c91808b6ef1d43e016efba0ce470906",
+  "name": "Adam Adams",
+  "type": "IDENTITY"
+}
+```
+
+To add a governance group to the approver list, the subscribing service should respond to the event trigger with the following payload:
+
+```json
+{
+  "id": "2c91808b6ef1d43e016efba0ce470907",
+  "name": "Audit Committee",
+  "type": "GOVERNANCE_GROUP"
+}
+```
+
+If no identity or group should be added to a particular access request, then the subscribing service should respond with an empty object:
+
+```json
+{}
+```
+
+## Additional information and links
+
+- **Trigger Type**: [REQUEST_RESPONSE](../event-triggers-trigger-types.md#request-response)
+- [Input Schema](https://developer.sailpoint.com/apis/beta/#section/Access-Request-Dynamic-Approver-Event-Trigger-Input)
+- [Output Schema](https://developer.sailpoint.com/apis/beta/#section/Access-Request-Dynamic-Approver-Event-Trigger-Output)
+- [How to respond to a REQUEST_RESPONSE trigger](../event-triggers-responding-to-a-request-response-trigger.md)

docs/idn_docs/triggers/available-event-triggers/access-request-postapproval-trigger.md

@@ -0,0 +1,27 @@
+---
+id: access-request-postapproval-trigger
+title: Access Request Postapproval Trigger
+sidebar_label: Access Request Postapproval Trigger
+sidebar-position: 3
+---
+
+# Access Request Postapproval Trigger
+
+## Event context
+
+The SailPoint IdentityNow platform now includes event triggers within the Access Request Approval workflow. The Access Request Postapproval event trigger provides more proactive governance and ensure users can quickly obtain needed access.
+
+![Flow](./img/access-request-postapproval-path.png)
+
+ When an access request is approved, this event trigger can:
+
+- Notify the requester that the access request has been approve or denied.
+- Notify the administrator or system to take the appropriate provisioning actions for the requested access.
+- Notify a third party system to trigger another action (e.g. customer feedback survey, initiate another business process), or simply for auditing once an access request decision has been made.
+
+The Access Request event trigger is a flexible way to extend the Access Request workflow after access is approved for the requester.
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/Access-Request-Post-Approval-Event-Trigger-Input)

docs/idn_docs/triggers/available-event-triggers/access-request-preapproval-event-trigger.md

@@ -0,0 +1,90 @@
+---
+id: access-request-preapproval-event-trigger
+title: Access Request Preapproval Event Trigger
+sidebar_label: Access Request Preapproval Event Trigger
+sidebar-position: 4
+---
+
+# Access Request Preapproval Event Trigger
+
+## Event context
+
+The platform now includes event triggers within the Access Request approval workflow. The Access Request Submitted event trigger provides more proactive governance, ensures users can quickly obtain needed access, and helps with more preventative measures towards unintended access.
+
+![Flow](./img/access-request-preapproval-path.png)
+
+When an access request is submitted, this event trigger can:
+
+- Provide the approver with additional context about the access request, for instance, any Separation of Duties (SOD) policy violations
+- Notify the approver through a different medium, such as Slack or Outlook Actionable Messages
+- Send a Terms of Agreement form of the requested Application to be signed by the access requester
+- On average you can expect about 1 access request for every 4 identities within your org per day. - On average you can expect about 1 to 2 access requests within a 10 second period.
+
+Additional use cases include:
+
+- Sending a Slack Notification to the approver or an approval channel and approve the request within Slack.
+- Create an Outlook Actionable Message.
+- Create a Google Doc for the requester to fill out and submit.
+
+## Configuration
+
+This is a `REQUEST_RESPONSE` type trigger.  For general information on how to respond to a `REQUEST_RESPONSE` type trigger, see [responding to a request response type trigger](../event-triggers-responding-to-a-request-response-trigger.md).  This trigger intercepts newly submitted access requests and allows the subscribing service to perform a preliminary approve/deny before the access request moves to the next approver in the chain.
+
+The subscribing service will receive the following input from the trigger service.  The input schema can be found in the [API specification](https://developer.sailpoint.com/apis/beta/#section/Access-Request-Pre-Approval-Event-Trigger-Input):
+
+```json
+{
+  "accessRequestId": "2c91808b6ef1d43e016efba0ce470904",
+  "requestedFor": {
+    "type": "IDENTITY",
+    "id": "2c91808568c529c60168cca6f90c1313",
+    "name": "William Wilson"
+  },
+  "requestedItems": [
+    {
+      "id": "2c91808b6ef1d43e016efba0ce470904",
+      "name": "Engineering Access",
+      "description": "Access to engineering database",
+      "type": "ACCESS_PROFILE",
+      "operation": "Add",
+      "comment": "William needs this access to do his job."
+    }
+  ],
+  "requestedBy": {
+    "type": "IDENTITY",
+    "id": "2c91808568c529c60168cca6f90c1314",
+    "name": "Rob Robertson"
+  }
+}
+```
+
+The subscribing service can use this information to make a decision on whether to approve or deny the request.  The output schema can be found in the [API specification](https://developer.sailpoint.com/apis/beta/#section/Access-Request-Pre-Approval-Event-Trigger-Output).  To approve an access request, the subscribing service should respond to the event trigger with the following payload:
+
+```json
+{
+  "approved": true,
+  "comment": "This access has passed preliminary approval.",
+  "approver": "AcmeCorpExternalIntegration"
+}
+```
+
+To deny an access request, the subscribing service should respond to the event trigger with the following payload:
+
+```json
+{
+  "approved": false,
+  "comment": "This access should be denied, because this will cause an SOD violation.",
+  "approver": "AcmeCorpExternalIntegration"
+}
+```
+
+This event trigger interrupts the normal workflow for access requests.  Access requests can only proceed if the subscribing service responds within the alotted time by approving the request.  If the subscribing service is non responsive, or responding with an incorrect payload, then access requests will fail after the **Separation of Duties** check.  If you see numerous access requests failing at this stage, check to make sure your subscribing service is operating correctly.
+
+![AR failed](./img/access-request-preapproval-failure.png)
+
+## Additional information and links
+
+- **Trigger Type**: [REQUEST_RESPONSE](../event-triggers-trigger-types.md#request-response)
+- [Input Schema](https://developer.sailpoint.com/apis/beta/#section/Access-Request-Pre-Approval-Event-Trigger-Input)
+- [Output Schema](https://developer.sailpoint.com/apis/beta/#section/Access-Request-Pre-Approval-Event-Trigger-Output)
+- [How to respond to a REQUEST_RESPONSE trigger](../event-triggers-responding-to-a-request-response-trigger.md)

docs/idn_docs/triggers/available-event-triggers/account-aggregation-completed.md

@@ -0,0 +1,51 @@
+---
+id: account-aggregation-completed
+title: Account Aggregation Completed
+sidebar_label: Account Aggregation Completed
+sidebar-position: 5
+---
+
+# Account Aggregation Completed
+
+## Event context
+
+The platform has introduced an event trigger within the Source Aggregation workflow to provide additional monitoring capabilities. This helps to ensure account aggregations are performing as expected and that identity data always reflects current source account information for better identity governance.  Aggregations connect to a source and collect account information from the source to discover the number of accounts that have been added, changed, or removed. For more information about account aggregation see [Account Aggregation Data flow](https://community.sailpoint.com/t5/Technical-White-Papers/Account-Aggregation-Data-Flow/ta-p/79914#toc-hId-1367430234)
+
+![Flow](./img/aggregation-diagram.png)
+
+After the initial collection of accounts in the source system during aggregation completes, this event trigger can:
+
+- Notify an administrator that IdentityNow was able to successfully connect to the source system and was able to collect source accounts.
+- Notify an administrator when the aggregation is terminated manually during the account collection phase.
+- Notify an administrator or system (e.g. PagerDuty) that IdentityNow failed to collect accounts during aggregation and indicate required remediation for the source system.
+
+> This event trigger does not include entitlement aggregations.
+
+The source account activity is summarized in `stats` e.g:
+
+```JSON
+"stats": {
+            "scanned": 200,
+            "unchanged": 190,
+            "changed": 6,
+            "added": 4,
+            "removed": 3
+        }
+```
+
+In this example, there are 10 changed accounts (`scanned` (200) - `unchanged` - (190)). Changed accounts include accounts that are `added` (6) and accounts that are `changed` (4), which equals 10 accounts. Removed accounts may or may not be included in the changed account total depending on the sources. For this example, `removed` (3) may be considered a changed account in some sources and would show a `scanned` count of 203 instead of 200.
+
+> This event trigger will fire even without changed accounts. The unchanged count will match the scanned accounts in the response.
+
+The status of the aggregation can be one of three possible values:
+
+- **Success**: Account collection successful and aggregation can move to the next step.
+- **Error**: There is failure in account collection or issues with connecting to the source. `errors` vary by source.
+- **Termination**: The aggregation was terminated during the account collection phase. Aggregation can be terminated when the account deletion threshold is exceeded. For example, an account delete threshold of 10% is set by default for the source and if the number of `removed` accounts for the above example is 21 (more than 10% of `scanned` accounts (200)), the aggregation is cancelled.
+
+![Account_Delete_Threshold](./img/aggregation-delete-threshold.png)
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/Account-Aggregation-Completed-Event-Trigger-Input)

docs/idn_docs/triggers/available-event-triggers/identity-attribute-changed-event-trigger.md

@@ -0,0 +1,24 @@
+---
+id: identity-attribute-changed-event-trigger
+title: Identity Attribute Changed Event Trigger
+sidebar_label: Identity Attribute Changed Event Trigger
+sidebar-position: 6
+---
+
+# Identity Attribute Changed Event Trigger
+
+## Event context
+
+![Flow](./img/trigger-path.png)
+
+Identity Attribute Changed events occur when any attributes that are aggegrated from an authoritative source differ from the current attributes for an identity during an identity refresh. See [Configuring Correlation](https://community.sailpoint.com/t5/Connectors/Configuring-Correlation/ta-p/74045) for more information about attributes that are updated for an Identity Profile.
+
+This event trigger provides a flexible way to extend Joiner-Mover-Leaver processes. This provides more proactive governance and ensures users can quickly obtain needed access when enter your organization.  Some examples of how this trigger can be used include:
+
+- Notify an administrator or system to take the appropriate provisioning actions as part of the Mover workflow.
+- Notify a system to trigger another action (e.g. trigger a certification campaign when an identity's manager had changed ).
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/Identity-Attributes-Changed-Event-Trigger-Input)

docs/idn_docs/triggers/available-event-triggers/identity-created-event-trigger.md

@@ -0,0 +1,24 @@
+---
+id: identity-created-event-trigger
+title: Identity Created Event Trigger
+sidebar_label: Identity Created Event Trigger
+sidebar-position: 7
+---
+
+# Identity Created Event Trigger
+
+## Event context
+
+![Flow](./img/identity-created-path.png)
+
+Identity Created events occur when a new identity is detected during an aggregration and refresh from an authoritative source.  New identities are detected when an account from the authoritative source is not correlated to an existing identity. For more information, see [Configuring Correlation](https://community.sailpoint.com/t5/Connectors/Configuring-Correlation/ta-p/74045). The Identity Created event will contain all attributes of the identity as configured in the identity profile. For more information, see [Mapping Identity Profiles](https://community.sailpoint.com/t5/Admin-Help/Mapping-Identity-Profiles/ta-p/77877).
+
+This event trigger provides a flexible way to extend Joiner-Mover-Leaver processes. This provides more proactive governance and ensure users can quickly obtain needed access when they enter your organization. Some examples of how this trigger can be used include:
+
+- Notify an administrator or system to take the appropriate birthright provisioning actions as part of the Joiner workflow.
+- Notify a third party system to trigger another action (e.g. create an onboarding experience for a new hire).
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/Identity-Created-Event-Trigger-Input)

docs/idn_docs/triggers/available-event-triggers/provisioning-action-completed-trigger.md

@@ -0,0 +1,111 @@
+---
+id: provisioning-action-completed-trigger
+title: Provisioning Action Completed Trigger
+sidebar_label: Provisioning Action Completed Trigger
+sidebar-position: 8
+---
+
+# Provisioning Action Completed Trigger
+
+## Event context
+
+![Flow](./img/provisioning-action.png)
+
+The Provisioning Action Completed event trigger notifies subscribed applications after the action is completed. This event trigger provides a flexible way to extend the Provisioning workflow after access has changed for an identity within SailPoint. This provides more proactive governance and ensure users can quickly obtain needed access. Some examples of how this trigger can be used include:
+
+- Notify the requester that the access request has been fulfilled.
+- Notify an application user and/or access certifier that access has been revoked.
+- Notify an administrator or system that provisioning has been completed.
+- Notify a third party system to trigger another action (e.g. continue additional provisioning actions) or simply for auditing of provisioning activities.
+
+## Prerequisites
+
+Before consuming this event trigger, the following prerequesites must be met.
+
+- An oAuth Client configured with authority as `ORG_ADMIN`.
+- An org enabled with the `ARSENAL_ALLOW_POSTPROVISIONING_TRIGGERS` feature flag.
+- Configure connectors for Provisioning into target applications.
+- An org configured for automated Provisioning. See Event context section for specific setup.
+
+In order to provision to a target application, the connector for the source needs to support the following connector features:
+
+- `ENABLE` - Can enable or disable an account.
+- `UNLOCK` - Can lock or unlock an account.
+- `PROVISIONING` - Can write to accounts. Currently, the trigger does not include attribute synchronization.
+- `PASSWORD` - Can update password for account
+
+For a list of supported connectors and features, see [Supported Connectors for IdentityNow](https://community.sailpoint.com/t5/Connectors/Supported-Sources-Connectors-for-IdentityNow/ta-p/80019).
+
+For information about configuring sources for provisioning, see [How can I edit the Create Profile on a source?](https://community.sailpoint.com/t5/Connectors/How-can-I-edit-the-Create-Profile-on-a-source/ta-p/74429).
+
+Provisioning events occur in these workflows:
+
+- [Access Request](#access-request)
+- [Certification](#certification)
+- [Role Membership](#role-membership)
+- [Lifecycle Management](#lifecycle-management)
+- [Password Management](#password-management)
+
+### Access Request
+
+When an Access Request approval process has completed with all positive approvals, the access request is fulfilled with provisioning to the target application with requested access.
+
+![Flow](./img/provisioning-access-request.png)
+
+Access acquired through a role request can also be revoked and those changes can be provisioned to an account.
+
+The following steps need to be completed:
+
+- Source Connector configured for `PROVISIONING`.
+Access Request in SailPoint SaaS currently does not support `ACCOUNT_ONLY_REQUEST` or `ADDITIONAL_ACCOUNT_REQUEST`.
+- Source Entitlements mapped in Account Schema.
+- Access Profile using Source Entitlements. Role setup is optional.
+- Application enabled for Access Request.
+
+> **NOTE:** There is no indication to the approver in the IdentityNow UI that the approval is for a revoke action. This must be considered for all usage of these APIs.
+
+![Flow](./img/provisioning-access-request-2.png)
+
+### Certification
+
+To provision removal of accounts acquired through Access Request is through Certifications.
+> **Note:** Certifications cannot revoke access acquired via Role Membership or Lifecycle Changes.
+
+![Flow](./img/provisioning-access-request-certification.png)
+
+### Role membership
+
+Access defined in access profiles can be grouped into Roles and Roles can be assigned to identities using `COMPLEX_CRITERION` or `IDENTITY_LIST`. For information on how to set `COMPLEX_CRITERION`, see [Admin UI](https://community.sailpoint.com/t5/Admin-Help/Standard-Role-Membership-Criteria-Options/ta-p/74392)
+> **Note:** Using `CUSTOM` Role Membership through Rules is no longer supported.
+
+Additionally, roles can be mapped from an authoritative source.
+
+![Flow](./img/provisioning-role-membership.png)
+
+### Lifecycle Management
+
+This trigger will fire when an account has been provisioned, enabled, or disabled.
+
+![Flow](./img/provisioning-lifecycle-management.png)
+
+To provision access with lifecycle states, the following steps must be completed:
+
+- Source Connector configured for `ENABLE` to enable/disable accounts and/or `PROVISIONING` to create/update/delete accounts.
+- Source Entitlements mapped from Authoritative Source
+- Source Entitlements mapped to Access Profiles
+- Identity Profile using authoritative source
+- Lifecycle states configured. To set up, follow this [guide].
+
+### Password Management
+
+Password changes can be provisioned to target applications through password reset or password interception. Also, unlocking of accounts can be provisioned via password change within SailPoint SaaS.
+
+For password management setup, you will need to configure:
+
+- Source Connector configured for `PASSWORD` for password changes and/or `UNLOCK` for unlocking changes.
+- Password Sync Group
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/Provisioning-Completed-Event-Trigger-Input)

docs/idn_docs/triggers/available-event-triggers/saved-search-completed.md

@@ -0,0 +1,28 @@
+---
+id: saved-search-completed
+title: Saved Search Completed
+sidebar_label: Saved Search Completed
+sidebar-position: 9
+---
+
+# Saved Search Completed
+
+## Event context
+
+![Flow](./img/saved-search-path.png)
+
+Users can to subscribe to Saved Searches and receive an email of a report generated from the saved search. For example, a user can save a search query called "Identities with upcoming end dates" and create a subscription to receive a daily report showing identities with an end date within 10 days from the current date. This event trigger can also notify an external HTTP application that a report generated from a saved search subscription is available to be processed.
+
+Saved Search Completed events occur based on the schedules set for saved search subscriptions. For example, if you have a scheduled saved search for Monday, Tuesday, Wednesday, Thursday, Friday at 6:00 GMT, this is when your HTTP endpoint will also receive a notification. This can be set using the `schedule` object in the [create scheduled search endpoint](https://developer.sailpoint.com/apis/v3/#operation/scheduledSearchCreate).
+
+To receive this event when a saved search query does not have any results, set `emailEmptyResults` to `TRUE`.  You can also set the expiration date in the `expiration` field within the `schedule` object. Your HTTP endpoint will stop receiving these events when the Scheduled Search expires.
+
+Some examples of how this trigger can be used include:
+
+- Perform Quality Control, such as continuously checking for Separation of Duties (SOD) violations
+- Respond to upcoming Joiner-Mover-Leaver scenarios, such as deprovisioning access before an employee's separation date.
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/Saved-Search-Complete-Event-Trigger-Input)

docs/idn_docs/triggers/available-event-triggers/source-created-trigger.md

@@ -0,0 +1,21 @@
+---
+id: source-created-trigger
+title: Source Created Trigger
+sidebar_label: Source Created Trigger
+---
+
+# Source Created Trigger
+
+## Event context
+
+Source Created events occur when a new source is successfully created via the API or the Admin UI.
+
+Some uses cases for this trigger include:
+
+- Provide evidence to show auditors that connector logic and sources are not manipulated outside of proper change control processes.
+- Auto-configure new sources with proper owners using external data sources.
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/Source-Created-Event-Trigger-Input)

docs/idn_docs/triggers/available-event-triggers/source-deleted-trigger.md

@@ -0,0 +1,21 @@
+---
+id: source-deleted-trigger
+title: Source Deleted Trigger
+sidebar_label: Source Deleted Trigger
+---
+
+# Source Deleted Trigger
+
+## Event context
+
+Source Deleted events occur when a source is successfully deleted via the API or the Admin UI.
+
+Some uses cases for this trigger include:
+
+- Provide evidence to show auditors that connector logic and sources are not manipulated outside of proper change control processes.
+- Alert admins in the event that a source was wrongfully deleted.
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/Source-Deleted-Event-Trigger-Input)

docs/idn_docs/triggers/available-event-triggers/source-updated-trigger.md

@@ -0,0 +1,21 @@
+---
+id: source-updated-trigger
+title: Source Updated Trigger
+sidebar_label: Source Updated Trigger
+---
+
+# Source Updated Trigger
+
+## Event context
+
+Source Updated events occur when configuration changes are made to a source.
+
+Some uses cases for this trigger include:
+
+- Provide evidence to show auditors that connector logic and sources are not manipulated outside of proper change control processes.
+- Trigger review of an updated source.
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/Source-Updated-Event-Trigger-Input)

docs/idn_docs/triggers/available-event-triggers/va-cluster-status-change-event-trigger.md

@@ -0,0 +1,44 @@
+---
+id: va-cluster-status-change-event-trigger
+title: VA Cluster Status Change Event
+sidebar_label: VA Cluster Status Change Event
+sidebar-position: 10
+---
+
+# VA Cluster Status Change Event
+
+## Event context
+
+VA Cluster Status Change Events occur when a health check is run on a VA cluster and the health status is different from the previous health check.  This trigger can be used by customers for monitoring all the health status changes of their Virtual Appliance (VA) cluster
+
+Some examples of what you can do with this trigger:
+
+- Create real-time health dashboards for VA Clusters
+- Notify an administrator or system to take the appropriate actions when a health status changes
+
+Additional notes about VA Cluster Status Changes:
+
+- VA cluster health checks run every 30 minutes.
+- This trigger will invoke on any VA cluster health status change (i.e. healthy -> unhealthy, unhealthy -> healthy)
+- More information on [troubleshooting virtual appliances](https://community.sailpoint.com/t5/IdentityNow-Connectors/Virtual-Appliance-Troubleshooting-Guide/ta-p/78735)
+
+Healthy Cluster Source
+
+![VA cluster source healthy](./img/va-cluster-healthy-source.png)
+
+Unhealthy Cluster Source
+
+![VA cluster source unhealthy](./img/va-cluster-unhealthy-source.png)
+
+Warning - Unhealthy Cluster
+
+![Warning unhealthy cluster](./img/va-cluster-warning.png)
+
+Failed - Unhealthy Cluster
+
+![Failed unhealthy cluster](./img/va-cluster-failed.png)
+
+## Additional information and links
+
+- **Trigger Type**: [FIRE_AND_FORGET](../event-triggers-trigger-types.md#fire-and-forget)
+- [Input schema](https://developer.sailpoint.com/apis/beta/#section/VA-Cluster-Status-Change-Event-Event-Trigger-Input)