Okta Workflows
| eventType | Description | Sample | Rule |
|---|---|---|---|
| workflows. | Report that a Workflows org has exceeded its step execution limit. | N | N |
| workflows. | Warn that a Workflows org is approaching its step execution limit. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the creation of new connections for Workflows connectors. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the deletion of existing Workflows connections. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the reauthorization of existing connections for Workflows connectors. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a token for a Workflows connection has been revoked in a third party service., and the event usually fires along with workflows.user.connection.delete. | N | N |
| workflows. | This event can be used by admins or security team members to monitor the execution of delegated flows in the Workflows platform from the Admin application. | N | N |
| workflows. | Workflows admin activated execution log streaming for their org. | N | N |
| workflows. | Workflows admin deactivated execution log streaming for their org. | N | N |
| workflows. | Workflows admin updated the configuration of their org's execution log streaming connection. | N | N |
| workflows. | Triggered when a user activates a flow in Workflows. | N | N |
| workflows. | Triggered when a user creates a new flow in Workflows. | N | N |
| workflows. | Triggered when a user deactivates a flow in Workflows. | Y | N |
| workflows. | Triggered when a user deletes a flow in Workflows. | N | N |
| workflows. | Workflows user requested to cancel flow execution. | N | N |
| workflows. | Workflows user activated saving execution history for a given flow. | N | N |
| workflows. | Workflows user deactivated saving execution history for a given flow. | N | N |
| workflows. | Workflows user deleted all or part of a flow's execution history. | N | N |
| workflows. | Workflows user activated execution log streaming for a given flow. | N | N |
| workflows. | Workflows user deactivated execution log streaming for a given flow. | N | N |
| workflows. | Triggered when a user exports a flow from Workflows. | N | N |
| workflows. | Triggered when a user imports a flow into Workflows. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor users moving flows between folders on the Workflows platform. | N | N |
| workflows. | Triggered when a user saves a flow in Workflows. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the creation of new folders in the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the deletion of folders in the Workflows platform. | N | N |
| workflows. | Duplicate Workflows folder. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user exports a folder from the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user imports a folder to the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user moves a folder in the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user renames a folder in the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the addition of Workflows roles to an Okta group. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the removal of Workflows roles from an Okta group. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the addition of Workflows roles to an Okta user. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the removal of Workflows roles from an Okta user. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the creation of new tables in the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user deletes a table from the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user exports table data from the Workflows platform using the Tables interface. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user imports table data into the Workflows platform using the Tables interface. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor users moving tables between folders on the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user exported a table schema from the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user has imported a table schema into the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor when a user updates a table's schema on the Workflows platform. | N | N |
| workflows. | This event can be used by any admin or security team member to monitor the viewing of table data in the Workflows platform. | N | N |
| workflows. | Add a certificate authority to a Workflows trust store. | N | N |
| workflows. | Delete a certificate authority from a Workflows trust store. | N | N |
| workflows. | Update a certificate authority in a Workflows trust store. | N | N |
| workflows. | View certificate authority details in a Workflows trust store. | N | N |
workflows.org.step_execution_limit.violation
#Description
Report that a Workflows org has exceeded its step execution limit. Monitor for step execution limit violations to understand when orgs are being throttled or blocked due to exceeding their monthly or lifetime step limit. Fires at 100% utilization of the org's step limit. After this event fires, flows will be throttled or blocked depending on enforcementType. Additional step limit information can be found in the debug context field.
References #
workflows.org.step_execution_limit.warning
#Description
Warn that a Workflows org is approaching its step execution limit. Monitor step execution utilization to proactively manage Workflows orgs before they reach their execution limit and become throttled or blocked. Fires at 50%, 75%, and 90% utilization of the org's step limit. Additional step limit information can be found in the debug context field.
References #
workflows.user.connection.create
#Description
This event can be used by any admin or security team member to monitor the creation of new connections for Workflows connectors. The target fields provide information on the user that created the connection, the application for which the connection was created, and the display name the user provided for the connection. Other connection lifecycle events include: workflows.user.connection.revoke, workflows.user.connection.reauthorize, and workflows.user.connection.delete. Note that this event only indicates if a connection was successfully added to the database, and does not distinguish whether or not that connection is valid.
References #
workflows.user.connection.delete
#Description
This event can be used by any admin or security team member to monitor the deletion of existing Workflows connections. The target fields provide information on the user that deleted the connection, the application for which the connection was deleted, and the display name originally provided for the connection. Other connection lifecycle events include: workflows.user.connection.create, workflows.user.connection.reauthorize, and workflows.user.connection.revoke. Note that for OAuth connections this will often fire with the workflows.user.connection.revoke event.
References #
workflows.user.connection.revoke
#Description
This event can be used by any admin or security team member to monitor when a token for a Workflows connection has been revoked in a third party service., and the event usually fires along with workflows.user.connection.delete. The target fields provide information on the user that revoked the connection, the application for which the connection was revoked, and the display name originally provided for the connection. Other connection lifecycle events include: workflows.user.connection.create, workflows.user.connection.reauthorize, and workflows.user.connection.delete. Note that this event only fires for connections where the service supplies an API endpoint for revoking tokens. Tokens that cannot be revoked via API must be managed manually in the third party application.
References #
workflows.user.delegatedflow.run
#Description
This event can be used by admins or security team members to monitor the execution of delegated flows in the Workflows platform from the Admin application. The actor field provides the Okta User ID of the user that ran the flow. The target fields provide context on the Workflows instance as well as the name and flow id of the executed flow. This event only indicates if the flow was successfully triggered and does not provide information about whether the flow encountered an error.
References #
workflows.user.execution_log_stream_connection.activate
#Description
Workflows admin activated execution log streaming for their org. Connections to a downstream HTTP endpoint (e.g. ingestion point to a SIEM) may be configured to stream execution logs for a Workflows org. Note that these logs only contain metadata about flow executions and not the I/O data processed in each execution.
References #
workflows.user.execution_log_stream_connection.deactivate
#Description
Workflows admin deactivated execution log streaming for their org. Connections to stream Workflows execution logs may be shut off by a Workflows admin at any time. Note that deactivating an execution log streaming connection will also wipe its configuration details, including sensitive API credentials in headers. These details will need to be re-entered upon reactivation.
References #
workflows.user.execution_log_stream_connection.update
#Description
Workflows admin updated the configuration of their org's execution log streaming connection. These changes may be related to the connection's destination URL, event subscriptions, or the headers and message body of each request. Note that the detailEntry field in this event's target object contains an array of fieldsUpdated, with the following possible values: DESTINATION_URL, EVENT_SUBSCRIPTIONS, HEADERS, or BODY.
References #
workflows.user.flow.activate
#Description
Triggered when a user activates a flow in Workflows. Can be used to audit user activity in Workflows. Event is fired when a user toggles a flow on.
References #
workflows.user.flow.create
#Description
Triggered when a user creates a new flow in Workflows. Can be used to audit user activity in Workflows. Event is fired when a user creates and saves a new flow.
References #
workflows.user.flow.deactivate
#Description
Triggered when a user deactivates a flow in Workflows. Can be used to audit user activity in Workflows. This is triggered by deactivating a flow.
Example System Log Event #
{
"published": 1784657932124,
"id": null,
"etag": null,
"kind": null,
"uuid": "00000000-0000-0000-0000-000000000141",
"actor": {
"id": "00u00000000000000093",
"type": "User",
"alternateId": "user20@dw-harness.example",
"displayName": "DW Harness 30",
"detailEntry": null
},
"client": {
"userAgent": null,
"zone": null,
"device": null,
"id": null,
"ipAddress": "198.51.100.3",
"geographicalContext": null
},
"device": null,
"events": null,
"target": [
{
"id": "00o00000000000000286",
"type": "AppInstance",
"alternateId": "user76@dw-harness.example",
"displayName": "DW Harness 117",
"detailEntry": null
},
{
"id": "01J00000000000000347",
"type": "Flow",
"alternateId": "user77@dw-harness.example",
"displayName": "DW Harness 118",
"detailEntry": null
}
],
"outcome": {
"result": "SUCCESS",
"reason": null
},
"request": {
"ipChain": [
{
"ip": "198.51.100.3",
"geographicalContext": null,
"version": null,
"source": null
}
]
},
"version": "0",
"severity": "INFO",
"eventType": "workflows.user.flow.deactivate",
"ipAddress": null,
"networkInfo": null,
"transaction": {
"type": "WORKFLOW",
"id": "00000000-0000-0000-0000-000000000142",
"detail": {}
},
"debugContext": {
"debugData": {
"sessionId": "00000000-0000-0000-0000-000000000142"
}
},
"displayMessage": "Flow deactivated",
"gatewayContext": null,
"legacyEventType": null,
"resourceDetails": null,
"securityContext": null,
"authenticationContext": null
}
References #
workflows.user.flow.delete
#Description
Triggered when a user deletes a flow in Workflows. Can be used to audit user activity in Workflows. Event is fired when a user toggles a flow off.
References #
workflows.user.flow.execution.cancel
#Description
Workflows user requested to cancel flow execution. These requests attempt cancellation of in-progress flow executions which are infinitely looping, stalled, or accidentally triggered. Canceling a flow execution cancels the execution of all remaining steps in the flow as well as all parent and helper flow executions associated with that execution. These cancellation requests are best-effort meaning that at the time of request some execution processes may be past the point of no return and will still complete.
References #
workflows.user.flow.execution_history.activate
#Description
Workflows user activated saving execution history for a given flow. Flows may save recent execution history for the purposes of testing, debugging, or auditing a flow's activity in the Workflows console. Note that in-product flow execution history is retained for 30 days.
References #
workflows.user.flow.execution_history.deactivate
#Description
Workflows user deactivated saving execution history for a given flow. Flows may be opted out of saving recent execution history for any reason (e.g. handling extremely sensitive data). Note that this setting is managed per individual flow, so helper flows invoked by a flow which has this setting deactivated will continue to write history unless switched off themselves.
References #
workflows.user.flow.execution_history.delete
#Description
Workflows user deleted all or part of a flow's execution history. Either in the course of testing / debugging or for data sensitivity / compliance reasons, a Workflows user may elect to delete recent execution history for a given flow. Note that the detailEntry field in this event's target object contains an executionHistoryType, which may be IO_DATA_ONLY or ALL depending on which option was selected in the UI.
References #
workflows.user.flow.execution_log_stream.activate
#Description
Workflows user activated execution log streaming for a given flow. A flow with execution log streaming deactivated may be reactivated by an authorized Workflow user at any time. This flow-level setting is enabled by default and so this activation event will only fire in the case of an individual flow having execution log streaming deactivated then reactivated.
References #
workflows.user.flow.execution_log_stream.deactivate
#Description
Workflows user deactivated execution log streaming for a given flow. Individual flows may have execution log streaming deactivated by an authorized Workflow user at any time to remain within monthly execution log limits per org or to reduce log volume/noise in downstream systems. This flow-level setting is enabled by default and must be manually deactivated on individual flows for which execution log streaming is undesired while an org's execution log streaming connection remains active.
References #
workflows.user.flow.export
#Description
Triggered when a user exports a flow from Workflows. Can be used to audit user activity in Workflows. Event is fired when a user exports one or more flows as a flowpack.
References #
workflows.user.flow.import
#Description
Triggered when a user imports a flow into Workflows. Can be used to audit user activity in Workflows. Event is fired when a user imports one or more flows as a flowpack.
References #
workflows.user.flow.move
#Description
This event can be used by any admin or security team member to monitor users moving flows between folders on the Workflows platform. The payload provides information on the user that moved the flow and the flow that was moved. Other Workflows resource move events include workflows.user.folder.move and workflows.user.table.move. Note that this event fires when a user manually drags a flow from one folder to another folder. Additional information including old and new folder locations can be found in the debug context field.
References #
workflows.user.flow.save
#Description
Triggered when a user saves a flow in Workflows. Can be used to audit user activity in Workflows. Event is fired when a user saves a flow.
References #
workflows.user.folder.create
#Description
This event can be used by any admin or security team member to monitor the creation of new folders in the Workflows platform. The payload provides information about the user that created the folder and the folder that was created. Other folder lifecycle events include: workflows.user.folder.delete, workflows.user.folder.import, workflows.user.folder.export, and workflows.user.folder.rename. Note that this event doesn't fire when a folder is imported. For that, users can reference workflows.user.folder.import.
References #
workflows.user.folder.delete
#Description
This event can be used by any admin or security team member to monitor the deletion of folders in the Workflows platform. The payload provides information on the user that deleted the folder and which folder was deleted. Other folder lifecycle events include: workflows.user.folder.create, workflows.user.folder.import, workflows.user.folder.export, and workflows.user.folder.rename. Note that this event fires when a user manually deletes a folder and recursively for each subfolder contained within the deleted folder. Subsequent workflows.user.flow.delete and workflows.user.table.delete events will fire for each flow and table deleted within each folder.
References #
workflows.user.folder.duplicate
#Description
Duplicate Workflows folder. Identifies when a user duplicates an Okta Workflows folder. This event fires for the folder that is duplicated and recursively for all subfolders contained within it. The folder name and location is found in the debug context object. Other folder lifecycle events include workflows.user.folder.create, workflows.user.folder.delete, workflows.user.folder.import, workflows.user.folder.export, workflows.user.folder.rename, and workflows.user.folder.move.
References #
workflows.user.folder.export
#Description
This event can be used by any admin or security team member to monitor when a user exports a folder from the Workflows platform. The payload provides information on the user that exported the folder and the folder that was exported. Other folder lifecycle events include: workflows.user.folder.create, workflows.user.folder.delete, workflows.user.folder.import, and workflows.user.folder.rename. Note that this event fires for the exported folder and recursively for each subfolder contained within the exported folder depending on the user's selection. Subsequent workflows.user.flow.export and workflows.user.table.schema.export events will fire for each flow and table exported within each exported folder. Additional folder information can be found in the debug context field.
References #
workflows.user.folder.import
#Description
This event can be used by any admin or security team member to monitor when a user imports a folder to the Workflows platform. The payload provides information on the user that imported the folder and the folder that was imported. Other folder lifecycle events include: workflows.user.folder.create, workflows.user.folder.delete, workflows.user.folder.export, and workflows.user.folder.rename. Note that this event fires for the imported folder and recursively for each subfolder contained within the imported folder. Subsequent workflows.user.flow.import and workflows.user.table.schema.import events will fire for each flow and table imported within each imported folder. Additional folder information can be found in the debug context field.
References #
workflows.user.folder.move
#Description
This event can be used by any admin or security team member to monitor when a user moves a folder in the Workflows platform. The payload provides information on the user that moved the folder and the folder that was moved. Other folder lifecycle events include workflows.user.folder.create, workflows.user.folder.delete, workflows.user.folder.import, workflows.user.folder.export, workflows.user.folder.rename, and workflows.user.folder.duplicate. Note that this event fires for the moved folder and recursively for each subfolder contained within the moved folder. Additional information including old and new folder locations can be found in the debug context field.
References #
workflows.user.folder.rename
#Description
This event can be used by any admin or security team member to monitor when a user renames a folder in the Workflows platform. The payload provides information on the user that renamed the folder and the new name of the folder. Other folder lifecycle events include: workflows.user.folder.create, workflows.user.folder.delete, workflows.user.folder.import, and workflows.user.folder.export. Additional information including old and new folder names can be found in the debug context field.
References #
workflows.user.role.group.add
#Description
This event can be used by any admin or security team member to monitor the addition of Workflows roles to an Okta group. The payload provides information about both the group to which the role was added and the role that was added. Related events include workflows.user.role.group.remove, workflows.user.role.user.add, workflows.user.role.user.remove, application.user_membership.add, and application.user_membership.remove. The event fires when an admin manually adds a role to an Okta group in the Workflows console. Adding multiple roles in a single action triggers multiple system log events.
References #
workflows.user.role.group.remove
#Description
This event can be used by any admin or security team member to monitor the removal of Workflows roles from an Okta group. The payload provides information about both the group from which the role was removed and the role that was removed. Related events include workflows.user.role.group.add, workflows.user.role.user.add, workflows.user.role.user.remove, application.user_membership.add, and application.user_membership.remove. The event fires when an admin manually removes a role from an Okta group in the Workflows console. Removing roles in a single action triggers multiple system log events.
References #
workflows.user.role.user.add
#Description
This event can be used by any admin or security team member to monitor the addition of Workflows roles to an Okta user. The payload provides information about both the user to whom the role was added and the role that was added. Related events include workflows.user.role.user.remove, workflows.user.role.group.add, workflows.user.role.group.remove, application.user_membership.add, and application.user_membership.remove. The event fires when an admin manually adds a role to a user in the Workflows console. Adding multiple roles in a single action triggers multiple system log events.
References #
workflows.user.role.user.remove
#Description
This event can be used by any admin or security team member to monitor the removal of Workflows roles from an Okta user. The payload provides information about both the user from whom the role was removed and the role that was removed. Related events include workflows.user.role.user.add, workflows.user.role.group.add, workflows.user.role.group.remove, application.user_membership.add, and application.user_membership.remove. The event fires when an admin manually removes a role from a user in the Workflows console. Removing multiple in a single action triggers multiple system log events.
References #
workflows.user.table.create
#Description
This event can be used by any admin or security team member to monitor the creation of new tables in the Workflows platform. The target fields provide information on the user that created the table and the new table. Other table lifecycle events include: workflows.user.table.view, workflows.user.table.update, and workflows.user.table.delete. Note that this event doesn't fire when a table is imported. For that, users can reference workflows.user.table.import or workflows.user.folder.import.
References #
workflows.user.table.delete
#Description
This event can be used by any admin or security team member to monitor when a user deletes a table from the Workflows platform. The target fields provide information on the user that deleted the table and the table itself. Other table lifecycle events include: workflows.user.table.view, workflows.user.table.update, and workflows.user.table.create.
References #
workflows.user.table.export
#Description
This event can be used by any admin or security team member to monitor when a user exports table data from the Workflows platform using the Tables interface. The target fields provide information on the user that exported the table and the table itself. Related events include: workflows.user.table.import, workflows.user.folder.import, and workflows.user.folder.export. Note that exports through the table interface include table data, while exporting tables as part of folder export does not.
References #
workflows.user.table.import
#Description
This event can be used by any admin or security team member to monitor when a user imports table data into the Workflows platform using the Tables interface. The target fields provide information on the user that imported the table and the table itself. Related events include: workflows.user.table.export, workflows.user.folder.export, and workflows.user.folder.import. Note that importing through the table interface requires an existing schema and is used to import the data from a .csv file. This event does not fire as part of workflows.user.folder.import.
References #
workflows.user.table.move
#Description
This event can be used by any admin or security team member to monitor users moving tables between folders on the Workflows platform. The payload provides information on the user that moved the table and the table that was moved. Other Workflows resource move events include workflows.user.folder.move and workflows.user.flow.move. Note that this event fires when a user manually drags a table from one folder to another folder. Additional information including old and new folder locations can be found in the debug context field.
References #
workflows.user.table.schema.export
#Description
This event can be used by any admin or security team member to monitor when a user exported a table schema from the Workflows platform. The payload provides information on the user that exported the table schema and the table that was exported. Other related table events include: workflows.user.table.create, workflows.user.table.delete, workflows.user.table.update, workflows.user.table.view, workflows.user.table.import, workflows.user.table.export, and workflows.user.table.schema.import. This event fires when a user exports a folder that contains a table.
References #
workflows.user.table.schema.import
#Description
This event can be used by any admin or security team member to monitor when a user has imported a table schema into the Workflows platform. The payload provides information on the user that imported the schema and the table that was created from that schema. Other related table events include: workflows.user.table.create, workflows.user.table.delete, workflows.user.table.update, workflows.user.table.view, workflows.user.table.import, workflows.user.table.export, and workflows.user.table.schema.export. This event fires when a user imports a folder that contains a table.
References #
workflows.user.table.update
#Description
This event can be used by any admin or security team member to monitor when a user updates a table's schema on the Workflows platform. The target fields provide information on the user that updated the table and the table itself. Other table lifecycle events include workflows.user.table.view, workflows.user.table.create, and workflows.user.table.delete. Note that this event does not include information about what was updated, only that the table name or columns were modified. It does not fire when the table data itself is updated.
References #
workflows.user.table.view
#Description
This event can be used by any admin or security team member to monitor the viewing of table data in the Workflows platform. The target fields provide information on the user that viewed the table and which table was viewed. Other table lifecycle events include: workflows.user.table.create, workflows.user.table.update, and workflows.user.table.delete. Note that this event only fires when a user manually accesses a table. It does not fire when table data is accessed using the Workflows Table functions.
References #
workflows.user.truststore.create
#Description
Add a certificate authority to a Workflows trust store. Security teams can use this event to audit additions to the trust store and ensure compliance with organizational security standards. Other trust-store lifecycle events include: workflows.user.truststore.delete, workflows.user.truststore.update, and workflows.user.truststore.view. Target carries the trust-store name and the certificate serial number. This event is only available for US Regulated Environments: FedRAMP High and DOD IL4/5, and eligible FedRAMP Moderate customers.
References #
workflows.user.truststore.delete
#Description
Delete a certificate authority from a Workflows trust store. Enables alerting on unauthorized or accidental removals of trusted roots, which could disrupt secure connections. Other trust-store lifecycle events include: workflows.user.truststore.create, workflows.user.truststore.update, and workflows.user.truststore.view. Target carries the trust-store name and the certificate serial number. This event is only available for US Regulated Environments: FedRAMP High and DOD IL4/5, and eligible FedRAMP Moderate customers.
References #
workflows.user.truststore.update
#Description
Update a certificate authority in a Workflows trust store. Tracks modifications to existing entries, such as certificate rotations, to ensure updates are authorized. Other trust-store lifecycle events include: workflows.user.truststore.create, workflows.user.truststore.delete, and workflows.user.truststore.view. Fires when an admin uploads a new certificate over an existing entry. Target carries the trust-store name and the new certificate serial number. This event is only available for US Regulated Environments: FedRAMP High and DOD IL4/5, and eligible FedRAMP Moderate customers.
References #
workflows.user.truststore.view
#Description
View certificate authority details in a Workflows trust store. Provides an audit trail for users inspecting sensitive security configurations, which is useful for detecting potential reconnaissance. Other trust-store lifecycle events include: workflows.user.truststore.create, workflows.user.truststore.delete, and workflows.user.truststore.update. Target carries the trust-store name and the certificate serial number. This event is only available for US Regulated Environments: FedRAMP High and DOD IL4/5, and eligible FedRAMP Moderate customers.