diff --git a/content/en/actions/workflows/access_and_auth.md b/content/en/actions/workflows/access_and_auth.md
index 46f39a0ec8a..a78529eab93 100644
--- a/content/en/actions/workflows/access_and_auth.md
+++ b/content/en/actions/workflows/access_and_auth.md
@@ -25,40 +25,56 @@ A few tools control access and authentication for workflows and their components
 
 ## Workflow identity
 
-A workflow can run using the identity of the owner of the workflow, or a service account associated with the workflow. By default, a workflow uses the Datadog user identity of its author.
+Every run of a workflow uses a single Datadog identity, controlled by the workflow's {{< ui >}}Run as{{< /ui >}} setting. That identity determines:
+- Which [connections][6] a run can resolve, including connections that use [private action runners][10]
+- Which Datadog resources a run can read and modify
+- Which user a run's actions are attributed to, in [audit trails][1] and in the products those actions touch
 
-### Use a service account
+A workflow can run as one of the following identities:
 
-A service account can be associated with a workflow and act as the identity of the workflow when it runs. A service account can:
-- resolve the connections defined in the workflow actions at runtime
-- provide an identity for workflow executions
-- provide an identity for workflow [audit trails][1]
+{{< ui >}}Owner{{< /ui >}}
+: The workflow runs as its owner, and any editor of the workflow can access the same resources as the owner. A new workflow runs as its owner by default.
 
-To create a service account for a workflow, you must have either the Datadog admin role, or a custom role with the {{< ui >}}Service Account Write{{< /ui >}} permission. The service account you create adopts your role and permissions. For more information on service accounts and permissions, see [Service accounts][2] or [Role based access control][3].
+{{< ui >}}Initiator{{< /ui >}}
+: The workflow runs as the user who triggered the run, so each run is limited to the resources that user can access. The Initiator identity is only supported for [triggers][4] that have an end user.
 
-#### Associate a service account with a workflow
+{{< ui >}}Service Account{{< /ui >}}
+: The workflow runs as a service account associated with the workflow. Use a service account to control the exact permissions a run has, with roles you choose for the workflow.
 
-You can dynamically create a service account for your workflow when you [add an automatic trigger][4].
+### Set the workflow identity
 
-1. Click the cog ({{< ui >}}Settings{{< /ui >}}) icon.
-1. Click {{< ui >}}Manage ownership and identity{{< /ui >}}.
-1. Click {{< ui >}}Run as Service Account{{< /ui >}}.
-1. Select a role for your service account user or select an existing Service Account.
-1. Click {{< ui >}}Save{{< /ui >}} to save the service account and apply the changes.
+Select an identity when you publish a workflow, or change it at any time:
 
-When you run a workflow, the service account user resolves the connections defined in the workflow actions. Therefore, the service account user needs the `connections_resolve` permission. The Datadog Admin Role and the Datadog Standard Role include the `connections_resolve` permission.
+1. In the workflow editor, click the cog ({{< ui >}}Settings{{< /ui >}}) icon.
+1. Click {{< ui >}}Edit permissions{{< /ui >}}.
+1. Under {{< ui >}}Run as{{< /ui >}}, select {{< ui >}}Owner{{< /ui >}}, {{< ui >}}Initiator{{< /ui >}}, or {{< ui >}}Service Account{{< /ui >}}.
+1. Click {{< ui >}}Save{{< /ui >}}.
+
+The following restrictions apply:
+- Only the owner of the workflow can select {{< ui >}}Owner{{< /ui >}} or {{< ui >}}Initiator{{< /ui >}}.
+- To select {{< ui >}}Service Account{{< /ui >}}, you need either the Datadog Admin Role or a custom role with the {{< ui >}}Service Account Write{{< /ui >}} permission.
+
+To see the identity a workflow uses, hover over the workflow name in the editor and read the {{< ui >}}Run as{{< /ui >}} field.
+
+### Run as the owner
+
+When a workflow runs as its owner, every run uses the owner's identity, whoever triggers it. A run can use the connections and Datadog resources the owner can access, even when the user who triggered it cannot access them.
 
-#### View service account details
+The owner resolves the connections defined in the workflow actions. The owner needs the `connections_resolve` permission, plus {{< ui >}}Resolver{{< /ui >}} access to each connection the workflow uses.
 
-1. Click the cog ({{< ui >}}Settings{{< /ui >}}) icon.
-1. Click {{< ui >}}Manage ownership and identity{{< /ui >}}.
-1. Click on your service account next to *Run As*.
+### Run as the initiator
 
-#### Remove a service account associated with a workflow
+When a workflow runs as the initiator, each run uses the identity of the user who triggered it. A run can only use the connections and Datadog resources that this user can access, and the actions the workflow takes are attributed to them. For example, if the workflow declares an incident, the incident is created by the user who triggered the workflow.
 
-1. Click the cog ({{< ui >}}Settings{{< /ui >}}) icon.
-1. Click {{< ui >}}Manage ownership and identity{{< /ui >}}.
-1. Click {{< ui >}}Change service account{{< /ui >}}.
+The initiator resolves the connections defined in the workflow actions. Each user who triggers the workflow needs the `connections_resolve` permission, plus {{< ui >}}Resolver{{< /ui >}} access to each connection the workflow uses.
+
+### Run as a service account
+
+When a workflow runs as a service account, every run uses that account's identity, whoever triggers it. Because you choose which roles the service account has, you control the exact permissions a run has, independently of any user's permissions.
+
+Attach an existing service account to the workflow, or create a service account when you set the identity. When you create one, you select its roles. You can assign any subset of the roles you have. With the {{< ui >}}User Access Manage{{< /ui >}} permission, you can assign any role in your organization. For more information, see [Service accounts][2] or [Role based access control][3].
+
+The service account resolves the connections defined in the workflow actions. It needs a role with the `workflows_run` and `connections_resolve` permissions, plus {{< ui >}}Resolver{{< /ui >}} access to each connection the workflow uses.
 
 ## Action credentials
 
@@ -120,7 +136,7 @@ You can restrict access on a specific workflow either from the workflow list pag
 
 **Restricting permissions from the workflow list page**
 1. Navigate to the [Workflow Automation page][8].
-1. Hover over the workflow on which you would like to set granular permissions. {{< ui >}}Edit{{< /ui >}}, {{< ui >}}Permissions{{< /ui >}}, and {{< ui >}}Delete{{< /ui >}} icons appear on the right.
+1. Hover over the workflow on which you would like to set granular permissions. Action icons, including {{< ui >}}Permissions{{< /ui >}}, appear on the right.
 1. Click the padlock ({{< ui >}}Permissions{{< /ui >}}) icon.
 1. Select {{< ui >}}Restrict Access{{< /ui >}}.
 1. Select a role from the dropdown menu. Click {{< ui >}}Add{{< /ui >}}. The role you selected populates into the bottom of the dialog box.
@@ -129,13 +145,14 @@ You can restrict access on a specific workflow either from the workflow list pag
 1. Click {{< ui >}}Save{{< /ui >}}.
 
 **Restricting permissions from the workflow editor**
-1. In the workflow editor click on the cog ({{< ui >}}Settings{{< /ui >}}) icon.
-1. Select {{< ui >}}Edit Permissions{{< /ui >}} from the dropdown.
+1. In the workflow editor, click the cog ({{< ui >}}Settings{{< /ui >}}) icon.
+1. Select {{< ui >}}Edit permissions{{< /ui >}} from the dropdown.
+1. Under {{< ui >}}Who has access{{< /ui >}}, select {{< ui >}}Custom{{< /ui >}}.
 1. Select {{< ui >}}Restrict Access{{< /ui >}}.
 1. Select a role from the dropdown menu. Click {{< ui >}}Add{{< /ui >}}. The role you selected populates into the bottom of the dialog box.
 1. Next to the role name, select your desired permission from the dropdown menu.
 1. If you would like to remove access from a role, click the trash can icon to the right of the role name.
-1. Click {{< ui >}}Save{{< /ui >}}.
+1. Click {{< ui >}}Done{{< /ui >}}, then click {{< ui >}}Save{{< /ui >}}.
 
 ## Further Reading
 
@@ -152,3 +169,4 @@ You can restrict access on a specific workflow either from the workflow list pag
 [7]: /account_management/rbac/permissions/#workflow-automation
 [8]: https://app.datadoghq.com/workflow
 [9]: https://chat.datadoghq.com/
+[10]: /actions/private_actions/
diff --git a/content/en/actions/workflows/trigger.md b/content/en/actions/workflows/trigger.md
index 0d79f0a2299..22a2dd59553 100644
--- a/content/en/actions/workflows/trigger.md
+++ b/content/en/actions/workflows/trigger.md
@@ -14,9 +14,9 @@ further_reading:
 - link: "/getting_started/workflow_automation/"
   tag: "Documentation"
   text: "Getting Started with Workflow Automation"
-- link: "/actions/workflows/access_and_auth/#use-a-service-account"
+- link: "/actions/workflows/access_and_auth/#workflow-identity"
   tag: "Documentation"
-  text: "Find out more about Service Accounts for workflows"
+  text: "Find out more about the identity used to run a workflow"
 - link: "dashboards"
   tag: "Documentation"
   text: "Find out more about setting up a dashboard"
@@ -33,7 +33,7 @@ further_reading:
 
 You can trigger a workflow manually or automatically and a workflow can have multiple triggers. This allows you to trigger a workflow from a variety of different sources, like a Datadog monitor and a Datadog dashboard.
 
-A workflow can either run with the identity of the user who owns it, or with the identity of a service account associated with the workflow. For more information on service accounts, see [Service accounts for Workflow Automation][1].
+A workflow runs with the identity of its owner, the user who triggered the run, or an associated service account. Triggers that fire without a user, such as schedules and webhooks, require the owner or a service account. For more information, see [Workflow identity][1].
 
 {{< img src="actions/workflows/trigger/multiple-triggers.png" alt="A workflow with multiple triggers" style="width:100%;" >}}
 
@@ -262,7 +262,7 @@ In later steps of your workflow, use `Source.api.requestBody` to reference the p
 
 To schedule a workflow run:
 1. On the workflow canvas, click {{< ui >}}Add an Automated Trigger{{< /ui >}} and select {{< ui >}}Schedule{{< /ui >}}.
-1. Click {{< ui >}}Create{{< /ui >}} to create a service account. For more information, see [Use a service account][1].
+1. Click {{< ui >}}Create{{< /ui >}} to create a service account. For more information, see [Run as a service account][17].
 1. Enter a time and frequency for the run.
 1. (Optional) Enter a description for the workflow in the {{< ui >}}Memo{{< /ui >}} field.
 1. Click {{< ui >}}Save{{< /ui >}}.
@@ -292,7 +292,7 @@ After you trigger a workflow, the workflow page switches to the workflow's {{< u
 
 <br>Do you have questions or feedback? Join the {{< ui >}}#workflows{{< /ui >}} channel on the [Datadog Community Slack][7].
 
-[1]: /actions/workflows/access_and_auth/#use-a-service-account
+[1]: /actions/workflows/access_and_auth/#workflow-identity
 [2]: https://app.datadoghq.com/monitors/manage
 [3]: https://app.datadoghq.com/security/configuration/notification-rules
 [4]: /security/cloud_security_management/workflows
@@ -307,4 +307,5 @@ After you trigger a workflow, the workflow page switches to the workflow's {{< u
 [13]: /actions/workflows/test_and_debug/#debug-a-failed-step
 [14]: https://app.datadoghq.com/software
 [15]: /incident_response/incident_management/setup_and_configuration/automations
-[16]: /incident_response/incident_management/setup_and_configuration/notification_rules/
\ No newline at end of file
+[16]: /incident_response/incident_management/setup_and_configuration/notification_rules/
+[17]: /actions/workflows/access_and_auth/#run-as-a-service-account