diff --git a/generated/routes.json b/generated/routes.json index f9cd80ee..3f04b181 100644 --- a/generated/routes.json +++ b/generated/routes.json @@ -341,11 +341,11 @@ }, "/plural-features/workbenches": { "relPath": "/plural-features/workbenches/index.md", - "lastmod": "2026-05-27T21:33:58.000Z" + "lastmod": "2026-07-31T10:05:04.000Z" }, "/plural-features/workbenches/configuration": { "relPath": "/plural-features/workbenches/configuration.md", - "lastmod": "2026-05-27T21:33:58.000Z" + "lastmod": "2026-07-31T10:05:04.000Z" }, "/plural-features/workbenches/coding-agent": { "relPath": "/plural-features/workbenches/coding-agent.md", @@ -353,15 +353,23 @@ }, "/plural-features/workbenches/tools": { "relPath": "/plural-features/workbenches/tools.md", - "lastmod": "2026-05-27T21:33:58.000Z" + "lastmod": "2026-07-31T10:05:04.000Z" + }, + "/plural-features/workbenches/tools/datadog": { + "relPath": "/plural-features/workbenches/tools/datadog.md", + "lastmod": "2026-07-31T10:05:04.000Z" }, "/plural-features/workbenches/running-jobs": { "relPath": "/plural-features/workbenches/running-jobs.md", - "lastmod": "2026-05-27T21:33:58.000Z" + "lastmod": "2026-07-31T10:05:04.000Z" }, "/plural-features/workbenches/automation": { "relPath": "/plural-features/workbenches/automation.md", - "lastmod": "2026-05-27T21:33:58.000Z" + "lastmod": "2026-07-30T14:01:51.000Z" + }, + "/plural-features/workbenches/follow-up-automation": { + "relPath": "/plural-features/workbenches/follow-up-automation.md", + "lastmod": "2026-07-30T15:19:23.000Z" }, "/plural-features/workbenches/use-cases": { "relPath": "/plural-features/workbenches/use-cases.md", diff --git a/pages/plural-features/workbenches/automation.md b/pages/plural-features/workbenches/automation.md index 1716a733..c0cf3e4b 100644 --- a/pages/plural-features/workbenches/automation.md +++ b/pages/plural-features/workbenches/automation.md @@ -5,12 +5,13 @@ description: Trigger workbench runs on a schedule, from incidents, or from ticke ## Overview -Workbenches can run jobs automatically through two mechanisms: +Workbenches can run jobs automatically through several mechanisms: * **Cron schedules** — run a prompt on a recurring schedule * **Webhook triggers** — fire a job when an observability alert or issue tracker event matches a pattern, including when someone writes `Plural fix this` on a PR or ticket +* **Post-merge follow-ups** — ask the workbench associated with a merged pull request to verify the reconciled system state -Both are managed from the overflow menu (**•••**) on a workbench. +Cron schedules and webhook triggers are managed from the overflow menu (**•••**) on a workbench. Follow-up prompts are configured in your source control or CI automation. --- @@ -105,6 +106,14 @@ Each webhook source has its own setup guide available during trigger creation. C --- +## Post-merge follow-up jobs + +When a workbench opens a pull request, a GitHub Actions workflow can send a follow-up prompt after the pull request merges and GitOps reconciliation completes. This lets the same workbench verify the live system or infrastructure state and address issues that are not visible from the source diff alone. + +See [Automating workbench follow-up](/plural-features/workbenches/follow-up-automation) for provider-specific setup. The current guide includes authentication, inputs, and a complete GitHub Actions workflow. + +--- + ## Flow-triggered jobs Workbenches can also be triggered from a [Plural Flow](/plural-features/flows). On the flow detail page, click **Start workbench job** to select a workbench and enter a prompt. The resulting job is scoped to the flow's services and pipelines, giving the agent the right context for that application boundary. diff --git a/pages/plural-features/workbenches/configuration.md b/pages/plural-features/workbenches/configuration.md index 38926c91..88934f0a 100644 --- a/pages/plural-features/workbenches/configuration.md +++ b/pages/plural-features/workbenches/configuration.md @@ -107,7 +107,7 @@ Attach only the tools this specific workbench needs. A tightly-scoped tool list ## Running your first job -Once the workbench is created, open it from the **Workbenches** list and type a prompt into the input field at the top of the **Jobs** tab. +Once the workbench is created, open it from the **Workbenches** list and type a prompt into the input field on the **Launch** tab. A few prompts to start with: diff --git a/pages/plural-features/workbenches/follow-up-automation.md b/pages/plural-features/workbenches/follow-up-automation.md new file mode 100644 index 00000000..647efecd --- /dev/null +++ b/pages/plural-features/workbenches/follow-up-automation.md @@ -0,0 +1,171 @@ +--- +title: Automating workbench follow-up +description: Send a follow-up prompt after a pull request merges, deployment completes, and GitOps reconciliation settles +--- + +## Overview + +Follow-up automation lets the workbench associated with a pull request verify changes after they merge, build, and deploy. The workbench can inspect the live system and infrastructure state, then report or fix issues that are only visible after deployment. + +The automation method depends on your source control and CI provider. The following section documents GitHub Actions. + +## GitHub Actions + +The [Plural Workbench Follow-up Action](https://github.com/pluralsh/workbench-followup-action) sends a follow-up prompt to the workbench job associated with a merged pull request. It wraps the `plural workbenches pr-followup` command. + +{% callout severity="info" %} +Run the action only for merged pull requests. The action does not check the pull request state itself. +{% /callout %} + +### Requirements + +The workflow requires: + +* A GitHub Actions runner with Bash, Git, and `jq` +* `pluralsh/setup-plural@v2` run earlier in the same job with Plural CLI version `0.12.60` or newer +* Access to the target Plural Console through federated credentials or a Console token +* A workbench job associated with the pull request + +### Configure the workflow + +A common pattern is to run the follow-up after the same workflow builds the image, deploys the application, and then gives GitOps reconciliation time to settle before asking the workbench to verify the live result: + +```yaml +name: Build, deploy, and verify merged changes + +on: + pull_request: + types: [closed] + +permissions: + contents: read + id-token: write + +jobs: + deploy-and-follow-up: + if: github.event.pull_request.merged == true + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Build Docker image + run: | + docker build -t ghcr.io/acme/example:${{ github.sha }} . + docker push ghcr.io/acme/example:${{ github.sha }} + + - name: Deploy application + run: ./scripts/deploy.sh ghcr.io/acme/example:${{ github.sha }} + + - name: Set up Plural + uses: pluralsh/setup-plural@v2 + with: + consoleUrl: ${{ vars.PLURAL_CONSOLE_URL }} + email: ${{ vars.PLURAL_CONSOLE_EMAIL }} + vsn: 0.12.60 + + - name: Verify deployed changes + id: follow-up + uses: pluralsh/workbench-followup-action@v1 + with: + prompt: | + Pull request #${{ github.event.pull_request.number }} was merged into ${{ github.event.pull_request.base.ref }}. + The Docker image was built and the application was deployed. + Verify the live deployment, confirm the expected change is working, and fix any issues you find. + url: ${{ github.event.pull_request.html_url }} + defer: 5m + skip-missing: true + + - name: Print Workbench job + if: steps.follow-up.outputs.skipped != 'true' + run: echo '${{ steps.follow-up.outputs.workbench-job-url }}' +``` + +Replace the example build and deploy commands with your own pipeline steps. Adjust `defer` to match the time your deployment normally needs to finish reconciling. `skip-missing: true` lets the workflow succeed when the pull request is not associated with a workbench job. + +When `url` and `commit` are omitted, the action uses `github.event.pull_request.html_url`, so the explicit `url` input above is optional for a `pull_request` workflow. + +### Authentication + +`pluralsh/setup-plural` installs the selected CLI version and exports `PLURAL_CONSOLE_URL` and `PLURAL_CONSOLE_TOKEN` to subsequent steps in the job. Configure it with one of the following authentication methods. + +#### Federated credentials + +Use `consoleUrl` and `email` with a matching Plural federated credential. The workflow must grant `id-token: write` so `setup-plural` can exchange the GitHub OIDC token for a Console access token: + +```yaml +permissions: + contents: read + id-token: write + +steps: + - name: Set up Plural + uses: pluralsh/setup-plural@v2 + with: + consoleUrl: ${{ vars.PLURAL_CONSOLE_URL }} + email: ${{ vars.PLURAL_CONSOLE_EMAIL }} + vsn: 0.12.60 +``` + +#### Console token + +Alternatively, store a Console token as a GitHub Actions secret. This method does not require the OIDC permission: + +```yaml +permissions: + contents: read + +steps: + - name: Set up Plural + uses: pluralsh/setup-plural@v2 + with: + consoleUrl: ${{ vars.PLURAL_CONSOLE_URL }} + consoleToken: ${{ secrets.PLURAL_CONSOLE_TOKEN }} + vsn: 0.12.60 +``` + +The follow-up action reads authentication from the environment and does not accept the Console URL or token as inputs. + +### Inputs + +| Input | Required | Default | Description | +|---|---|---|---| +| `prompt` | Yes | — | Follow-up prompt sent to the workbench. | +| `url` | No | Event PR URL | Explicit merged pull request URL. When omitted without `commit`, the action uses `github.event.pull_request.html_url`. | +| `commit` | No | `HEAD` | Commit or ref whose subject identifies the pull request when the URL is omitted. | +| `base-url` | No | Origin web URL | Repository web URL used to construct the pull request URL. | +| `provider` | No | `auto` | Source control provider: `auto`, `github`, `gitlab`, or `bitbucket`. | +| `defer` | No | `0s` | Duration to defer the follow-up, such as `30s`, `5m`, or `2h`. | +| `output` | No | `json` | CLI output format: `raw` or `json`. Structured action outputs are available only with `json`. | +| `skip-missing` | No | `false` | Exit successfully if no workbench job is associated with the pull request. | + +`url` and `commit` are mutually exclusive. + +### Outputs + +| Output | Description | +|---|---| +| `prompt-id` | ID of the created follow-up prompt. Empty when skipped. | +| `pull-request-url` | Pull request URL used by the command. | +| `workbench-job-url` | URL of the associated workbench job. Empty when skipped. | +| `skipped` | `true` when no associated workbench job was found and `skip-missing` was enabled. | + +The action populates structured outputs only when `output` is `json`. With `output: raw`, it writes the human-readable CLI result to the workflow log and leaves these outputs empty. + +### Resolve a pull request from a commit + +For a workflow triggered by a push to the deployment branch, the action can infer the pull request from the checked-out commit subject. Check out the repository with full history first: + +```yaml +- uses: actions/checkout@v4 + with: + fetch-depth: 0 + +- name: Verify merged changes + uses: pluralsh/workbench-followup-action@v1 + with: + prompt: Verify the merged changes against the reconciled system and infrastructure state. + commit: HEAD + provider: github +``` + +Use `base-url` with `provider` if the Git remote does not provide the correct repository web URL, such as for a self-hosted source control provider. diff --git a/pages/plural-features/workbenches/index.md b/pages/plural-features/workbenches/index.md index 48f29ed2..f89a8fff 100644 --- a/pages/plural-features/workbenches/index.md +++ b/pages/plural-features/workbenches/index.md @@ -56,6 +56,6 @@ Workbenches live under a **project**, inheriting and extending that project's RB 1. Navigate to **Workbenches** in the Plural Console sidebar. 2. Click **Create workbench** and step through the [creation wizard](/plural-features/workbenches/configuration). 3. (Optional) Set up shared [tools](/plural-features/workbenches/tools) your workbench can call. -4. Run your first job from the workbench's **Jobs** tab. +4. Run your first job from the workbench's **Launch** tab. Once you have a job running, you can layer in [automation](/plural-features/workbenches/automation) to trigger jobs on a schedule or from incidents. diff --git a/pages/plural-features/workbenches/running-jobs.md b/pages/plural-features/workbenches/running-jobs.md index 6c469f14..8b34124e 100644 --- a/pages/plural-features/workbenches/running-jobs.md +++ b/pages/plural-features/workbenches/running-jobs.md @@ -16,7 +16,7 @@ Jobs can be started manually from the UI, by a [cron schedule](/plural-features/ ## Starting a job manually -Open a workbench and click **Start job** (or the prompt input at the top of the **Jobs** tab). Type your prompt and press **Run**. +Open a workbench, select the **Launch** tab, and type your prompt into the new-job input. Submit the prompt to start the job. ![](/assets/workbenches/workbench-start-job.png) diff --git a/pages/plural-features/workbenches/tools.md b/pages/plural-features/workbenches/tools.md index ff6587ad..08ce859f 100644 --- a/pages/plural-features/workbenches/tools.md +++ b/pages/plural-features/workbenches/tools.md @@ -36,7 +36,7 @@ All native integrations respect your existing RBAC — enabling a capability her | Tool | What the agent can do | |---|---| | **Prometheus** | Query metrics from a Prometheus-compatible endpoint | -| **Datadog** | Query metrics and logs from the Datadog API | +| **[Datadog](/plural-features/workbenches/tools/datadog)** | Query metrics, logs, and traces from the Datadog API | | **Loki** | Query log streams from a Loki-compatible endpoint | | **Elastic** | Query and search indices in an Elasticsearch cluster | | **Tempo** | Query distributed traces from a Grafana Tempo endpoint | diff --git a/pages/plural-features/workbenches/tools/datadog.md b/pages/plural-features/workbenches/tools/datadog.md new file mode 100644 index 00000000..399218e1 --- /dev/null +++ b/pages/plural-features/workbenches/tools/datadog.md @@ -0,0 +1,171 @@ +--- +title: Datadog integration +description: Connect Datadog to a workbench and query metrics, logs, and traces +--- + +Use the Datadog integration to give a workbench read-only access to the metrics, logs, and traces already stored in your Datadog account. After you configure the connection once, you can attach it to one or more workbenches and investigate Datadog data with natural-language prompts. + +This guide uses the Plural Console UI. For the complete list of integrations and general tool behavior, see [Workbench tools](/plural-features/workbenches/tools). + +## Prerequisites + +Before you begin, make sure you have: + +* A Datadog account that is already receiving the metrics, logs, or traces you want the workbench to query. Installing a Datadog Agent is not required specifically for this integration; Plural queries your Datadog account through the Datadog API. +* Permission in Plural Console to create a configured tool and edit the target workbench. +* The hostname for your [Datadog site](https://docs.datadoghq.com/getting_started/site/), such as `datadoghq.com`. Enter only the hostname, without `https://`. +* A [Datadog API key and application key](https://docs.datadoghq.com/account_management/api-app-keys/). Use dedicated, read-only credentials where possible. +* An existing workbench, or permission to create one. See [Setting up a workbench](/plural-features/workbenches/configuration). + +{% callout severity="warning" %} +The Console currently labels **Application key** as optional, but Datadog queries require both an API key and an application key. Configure both keys before using the integration. +{% /callout %} + +### Create credentials in Datadog + +Create the organization API key: + +1. Open your account menu in Datadog and select **Organization Settings**. +2. Select **API Keys**, then click **New Key**. +3. Enter a descriptive name, create the key, and copy its value. + +For the application key, a [service account](https://docs.datadoghq.com/account_management/org_settings/service_accounts/) is recommended because its credentials are not tied to an individual user's lifecycle: + +1. Go to **Organization Settings → Accounts → Service Accounts**. +2. Click **New Service Account**, enter its details, and assign it a role with the permissions described below. +3. Create the account, select it from the service account list, and click **New Key**. +4. Name the application key, click **Create Key**, and copy its value immediately. A service-account application key is displayed only once. + +As an alternative, go to **Organization Settings → Application Keys → New Key** to create a user-owned application key. This key inherits its owner's permissions and is revoked if that user is disabled, so use this option only when tying the integration to an individual account is acceptable. + +### Datadog permissions + +An application key uses the permissions of the Datadog user or service account that owns it. Assign that identity a [Datadog role](https://docs.datadoghq.com/account_management/rbac/) with only the permissions needed for the capabilities you plan to enable: + +| Capability | Required Datadog permissions | What the workbench can query | +|---|---|---| +| **Metrics** | `timeseries_query`, `metrics_read` | Metric timeseries, recently active metric names, and indexed metric tags | +| **Logs** | `logs_read_data`, `logs_read_index_data` | Log events from the indexes granted to the application key owner | +| **Traces** | `apm_read` | APM spans | + +For all three capabilities, grant all five permissions. Scope `logs_read_index_data` to every log index the workbench needs to query. See the Datadog documentation for [Log Management permissions](https://docs.datadoghq.com/account_management/rbac/permissions/#log-management), [metric timeseries](https://docs.datadoghq.com/api/latest/metrics/query-timeseries-points/), [metric search](https://docs.datadoghq.com/api/latest/metrics/search-metrics/), [logs](https://docs.datadoghq.com/api/latest/logs/search-logs-post/), and [spans](https://docs.datadoghq.com/api/latest/spans/search-spans/). + +## Create the Datadog tool + +1. In Plural Console, open **Workbenches → Integrations**. +2. Find the **Datadog** card and click **Add tool**. + +![Datadog integration card on the Workbenches Integrations page](/assets/workbenches/datadog-integration-card.png) + +### Configure the connection + +On the **Configuration** step, enter: + +* **Name** — a recognizable name for the connection, such as `datadog-production`. +* **Site** — your Datadog site hostname, without a URL scheme. +* **API key** — the Datadog API key. +* **Application key** — the Datadog application key whose owner has the required permissions. + +Under **Allowed capabilities**, select one or more of **Metrics**, **Logs**, and **Traces**. All three are selected by default. Enable only capabilities that the application key is authorized to use and that the target workbenches need. + +Click **Next**. + +![Datadog tool configuration form with metrics, logs, and traces enabled](/assets/workbenches/datadog-configuration.png) + +{% callout severity="warning" %} +Treat both keys as secrets. Plural stores them encrypted and does not display them after saving. Never include credential values in screenshots, workbench prompts, or job output. +{% /callout %} + +### Configure access + +On the **Access policy** step, add the users or groups that should have read or write access to this configured tool: + +* **Read permissions** control who can access and attach the tool to a workbench. +* **Write permissions** control who can modify the tool configuration and access policy. + +Click **Save**. After the creation confirmation appears, the connection is available under **Workbenches → Configured Tools**. + +![Datadog tool access policy with read and write user and group bindings](/assets/workbenches/datadog-access-policy.png) + +## Attach Datadog to a workbench + +You can attach the tool while creating a workbench or add it to an existing one. + +### New workbench + +On the final **Attach tools** step of the workbench wizard: + +1. Click **Add tools**. +2. Select the Datadog connection by its configured name. +3. Confirm that the capability chips you enabled during configuration appear on the selected tool. +4. Complete the wizard by clicking **Create workbench**. + +### Existing workbench + +1. Open the workbench. +2. In the left sidebar, find **Tools** and click **Add tools**. You can also open the overflow menu and select **Tools**. +3. In **Add or remove tool from workbench**, select the Datadog connection. +4. Click **Save**. + +The configured Datadog tool now appears in the workbench's **Tools** section. + +![Datadog selected in the tool picker for an existing workbench](/assets/workbenches/datadog-attach-to-workbench.png) + +## Query Datadog from a workbench + +Open the workbench's **Launch** tab and describe the investigation in the prompt box. The **Jobs** tab contains run history rather than the new-job prompt. Include the signal, relevant service or environment tags, a time range, and the result you want. The workbench chooses the appropriate Datadog operation; there is no separate Datadog query builder in Console. + +Try prompts such as: + +* **Metrics:** `Using Datadog, compare the average CPU usage for hosts tagged env:prod over the last hour and identify outliers.` +* **Logs:** `Search Datadog logs for errors from service:checkout in env:prod during the last 30 minutes. Group the findings by status and summarize the most common messages.` +* **Traces:** `Find error spans for service:checkout in Datadog during the last 30 minutes. Identify the slowest resources and summarize any shared tags.` +* **Correlated investigation:** `Investigate the checkout latency increase over the last hour using Datadog metrics, logs, and traces. Build a timeline and cite the signals that support your conclusion.` + +Use Datadog metric and tag syntax when you need precise filtering. For example, include `avg:system.cpu.user{env:prod} by {host}` directly in a metrics prompt, or `service:checkout status:error` in a log or trace prompt. + +Submit the job and watch its activity stream. To verify the integration, confirm that the job completes, open its Datadog tool activity, and check that the call succeeded and returned data for the requested signal. A tool activity entry can also contain an API error, so its presence alone does not verify the connection. For more about job output, see [Running workbench jobs](/plural-features/workbenches/running-jobs). + +![Completed Datadog metrics investigation with tool activity, conclusions, and a dashboard](/assets/workbenches/datadog-job-result.png) + +## Query behavior and limits + +The Datadog tool is read-only. It cannot create or modify dashboards, monitors, logs, metrics, or traces. + +Keep these query behaviors in mind: + +* Specify a time range, especially for trace prompts. Metrics and logs default to a recent 30-minute window when no range is supplied, but explicit ranges produce more predictable results. +* Metrics queries must cover less than seven days. +* Metric-name and tag discovery covers recently indexed data and is not an exhaustive historical catalog. +* Log and trace searches return one page of results. Use narrow filters, time ranges, and limits for reliable investigations. +* Trace results are individual spans, not reconstructed trace trees. + +## Troubleshooting + +### Authentication or permission errors + +* Confirm that both the API key and application key are configured and belong to the same Datadog organization. +* For a `403` response, verify that the application key owner has the permissions required for every enabled capability. +* If only log queries fail or omit expected indexes, grant the application key owner both `logs_read_data` and `logs_read_index_data`, and confirm that the index-level permission covers the required indexes. +* Confirm that **Site** matches the Datadog account. Enter the hostname only, not a full URL. +* To rotate a key, open **Workbenches → Configured Tools**, select **Edit configuration**, and enter the replacement secret. Existing secret values are never displayed. + +### No data is returned + +* Verify in Datadog that the expected data exists for the same query and time range. +* Include an explicit time range and check service, environment, host, and tag filters for spelling or scope mismatches. +* Confirm that the required capability is enabled on the configured tool and that the tool is attached to the workbench. +* Remember that enabling **Logs** or **Traces** makes those query operations available; it does not configure log or trace ingestion into Datadog. + +### A query fails or returns incomplete results + +* Open the failed Datadog activity in the job and inspect the API error before retrying. +* Check metric, log, or span filters against the corresponding Datadog query syntax. Start with a narrow, known-good query and add filters incrementally. +* Keep metrics ranges under seven days. For logs and traces, reduce the time range or add filters if the first page does not contain enough relevant results. +* If Datadog reports a rate limit, wait for the limit to reset and retry with a narrower query. Avoid repeatedly launching broad trace searches. + +### The Datadog tool is unavailable + +* Confirm that the tool appears under **Workbenches → Configured Tools**. +* Verify that your user or group has read access to the configured tool. +* Reopen the workbench's **Tools** dialog and confirm that the Datadog connection is selected. diff --git a/public/assets/workbenches/datadog-access-policy.png b/public/assets/workbenches/datadog-access-policy.png new file mode 100644 index 00000000..00e16756 Binary files /dev/null and b/public/assets/workbenches/datadog-access-policy.png differ diff --git a/public/assets/workbenches/datadog-attach-to-workbench.png b/public/assets/workbenches/datadog-attach-to-workbench.png new file mode 100644 index 00000000..3d3a9c8e Binary files /dev/null and b/public/assets/workbenches/datadog-attach-to-workbench.png differ diff --git a/public/assets/workbenches/datadog-configuration.png b/public/assets/workbenches/datadog-configuration.png new file mode 100644 index 00000000..a3b4dab1 Binary files /dev/null and b/public/assets/workbenches/datadog-configuration.png differ diff --git a/public/assets/workbenches/datadog-integration-card.png b/public/assets/workbenches/datadog-integration-card.png new file mode 100644 index 00000000..ce322409 Binary files /dev/null and b/public/assets/workbenches/datadog-integration-card.png differ diff --git a/public/assets/workbenches/datadog-job-result.png b/public/assets/workbenches/datadog-job-result.png new file mode 100644 index 00000000..00d95ca8 Binary files /dev/null and b/public/assets/workbenches/datadog-job-result.png differ diff --git a/src/routing/docs-structure.ts b/src/routing/docs-structure.ts index bd38e38c..495f603f 100644 --- a/src/routing/docs-structure.ts +++ b/src/routing/docs-structure.ts @@ -261,9 +261,17 @@ export const docsStructure: DocSection[] = [ sections: [ { path: 'configuration', title: 'Setting up a workbench' }, { path: 'coding-agent', title: 'Coding agent' }, - { path: 'tools', title: 'Workbench tools' }, + { + path: 'tools', + title: 'Workbench tools', + sections: [{ path: 'datadog', title: 'Datadog integration' }], + }, { path: 'running-jobs', title: 'Running workbench jobs' }, { path: 'automation', title: 'Automating workbench jobs' }, + { + path: 'follow-up-automation', + title: 'Automating workbench follow-up', + }, { path: 'use-cases', title: 'Common use cases' }, ], },