The Impact of Deactivating a User That Authored a Workflow or Created a Connection in Okta Workflows
Last Updated:
Overview
Deactivating an Okta account affects Okta Workflows differently depending on whether the user authored a workflow or was the last to authorize a connection. While deactivating a workflow creator does not affect runtime execution, deactivating the user that was last used to authorize a connection revokes access and refresh tokens used for the connection and stops associated action cards from executing. Administrators must reauthorize affected Okta and third-party connections using an active Super Administrator or service account to restore functionality. The items below detail the specific design-time and runtime impacts of deactivating a workflow author, the effects on Okta and third-party connections, and the recommended practices for connection authorization.
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- Okta Workflows
- Okta Workflows Connections
Solution
What is the design-time impact of deactivating the user who originally authored a workflow?
Deactivating the original author of a workflow has the following design-time impacts.
- Workflows created by the deactivated user will remain active and can still be viewed and edited by users with the Super Administrator or Workflows Administrator role, as described in the Roles and permissions section of the Workflows Role-based access control documentation.
- When viewing the list of flows in a folder from the Workflows console, the AUTHOR column will reflect the name of the original author. It does not get updated based on the user who last saved the flow.
What is the runtime impact of deactivating the user who originally authored a workflow?
Deactivating the original author of a workflow has the following runtime impacts.
- Existing running flow executions and new flow executions will not be impacted, as they do not run under the context of the original author. If the author's account is deactivated or deleted, it will not impact flow execution.
Can the original author of a workflow be modified?
Administrators cannot change the original author who created a workflow, but they can update the author by performing the following actions.
- No, the original author who created a workflow cannot be changed; however, it is possible to:
- Export and import the flow, and the author of the imported flow will be set to the logged-on user.
- Duplicate the flow, and the author of the duplicated flow will be set to the logged-on user.
What is the impact of deactivating the user who authorized connections for any of the Okta connectors?
Deactivating the account that authorized any Okta connections in Okta Workflows results in the following impacts.
- Okta Workflows clears the user session and revokes the access tokens.
- The connection becomes unauthorized, and any Okta action cards that use the connection stop working.
- Administrators must reauthorize the connection, including Okta, Okta Devices, Okta Realms, Okta Identity Governance, and Okta Identity Threat Protection (ITP) connections, using a Super Administrator account.
- NOTE: There is a requirement to authorize these connections using a Super Admin account, which is documented for each specific connector:
How to determine which account last authorized a connection?
Identify the account currently in use for a connection by reviewing the provided Knowledge Base Article.
- If it is not known which account was last used to authorize a connection in workflows, for certain connectors, the following article describes how to determine the account that a Workflows connection is currently using: How to See what User Account a Workflows Connection is Using / Authorized with.
What is the impact of deactivating/deleting the account used to authorize connections to third-party systems?
Review the required permissions for specific connectors to reauthorize third-party system connections.
- If the account used to authorize third-party connectors is deactivated or deleted in the third-party system, depending on the type of authorization required by the connector, the connection may need to be reauthorized using an active account that has the required permissions as specified in the Okta Workflows Connectors documentation for each specific connector.
What is the recommended practice for authorizing connections in Okta Workflows?
Administrators should follow these recommended practices for authorizing connections in Okta Workflows.
- User accounts that will get deactivated or deleted when the account owner departs the company should not be used to authorize connections in Okta Workflow. It is recommended that service accounts, with the required permissions as documented for each connector, be used to authorize all connections in Okta Workflows.
- Maintain a list of connections with connection-specific configuration settings and credentials in a secure location. This is particularly important when using the Okta API Connector, so there is a record of which Auth Type was used to authorize the connection.
