workers: fix typo

src/content/changelogs/workflows.yaml

@@ -0,0 +1,15 @@
+---
+link: "/workflows/reference/changelog/"
+productName: Workflows
+productLink: "/workflows/"
+productArea: Developer platform
+productAreaLink: /workers/platform/changelog/platform/
+entries:
+  - publish_date: "2024-10-23"
+    title: "Workflows is now in public beta!"
+    description: |-
+      Workflows, a new product for building reliable, multi-step workflows using Cloudflare Workers, is now in public beta. The public beta is available to any user with a [free or paid Workers plan](/workers/platform/pricing/).
+
+      A Workflow allows you to define multiple, independent steps that encapsulate errors, automatically retry, persist state, and can run for seconds, minutes, hours or even days. A Workflow can be useful for post-processing data from R2 buckets before querying it, automating a Workers AI RAG pipeline, or managing user signup flows and lifecycle emails.
+
+      You can learn more about Workflows in [our announcement blog](https://blog.cloudflare.com/building-workflows-durable-execution-on-workers/), or start building in our [get started guide](/workflows/get-started/guide/).

src/content/docs/workers/configuration/cron-triggers.mdx

@@ -11,6 +11,12 @@ Cron Triggers allow users to map a cron expression to a Worker using a [`schedul
 
 Cron Triggers are ideal for running periodic jobs, such as for maintenance or calling third-party APIs to collect up-to-date data. Workers scheduled by Cron Triggers will run on underutilized machines to make the best use of Cloudflare's capacity and route traffic efficiently.
 
+:::note
+
+Cron Triggers can also be combined with [Workflows](/workflows/) to trigger multi-step, long-running tasks. You can [bind to a Workflow](/workflows/build/workers-api/) from directly from your Cron Trigger to execute a Workflow on a schedule.
+
+:::
+
 Cron Triggers execute on UTC time.
 
 ## Add a Cron Trigger

src/content/docs/workers/runtime-apis/bindings/workflows.mdx

@@ -0,0 +1,10 @@
+---
+pcx_content_type: navigation
+title: Workflows
+external_link: /workflows/
+head: []
+description: APIs available in Cloudflare Workers to interact with
+  Workflows. Workflows allow you to build durable, multi-step applications
+  using Workers.
+
+---

src/content/docs/workers/wrangler/commands.mdx

@@ -28,6 +28,7 @@ Wrangler offers a number of commands to manage your Cloudflare Workers.
 - [`r2 object`](#r2-object) - Manage Workers R2 objects.
 - [`secret`](#secret) - Manage the secret variables for a Worker.
 - [`secret:bulk`](#secretbulk) - Manage multiple secret variables for a Worker.
+- [`workflows`](#workflows) - Manage and configure Workflows.
 - [`tail`](#tail) - Start a session to livestream logs from a deployed Worker.
 - [`pages`](#pages) - Configure Cloudflare Pages.
 - [`queues`](#queues) - Configure Workers Queues.
@@ -138,10 +139,10 @@ wrangler docs [<COMMAND>]
 
 ## `init`
 
-:::note 
+:::note
 
 
-The `init` command will be removed in a future version. Please use `npm create cloudflare@latest` instead. 
+The `init` command will be removed in a future version. Please use `npm create cloudflare@latest` instead.
 
 
 :::
@@ -1244,6 +1245,151 @@ Finished processing secrets JSON file:
 🚨 1 secrets failed to upload
 ```
 
+## `workflows`
+
+:::note
+
+`wrangler workflows` commands are available in `wrangler` version `3.82.0` or later.
+
+:::
+
+Manage and configure [Workflows](/workflows/).
+
+### `list`
+
+Lists the registered Workflows for this account.
+
+```sh
+wrangler workflows list
+```
+
+- `--page` <Type text="number" /> <MetaInfo text="optional" />
+  -  Show a specific page from the listing. You can configure page size using "per-page".
+- `--per-page` <Type text="number" /> <MetaInfo text="optional" />
+  - Configure the maximum number of Workflows to show per page.
+
+### `instances`
+
+Manage and interact with specific instances of a Workflow.
+
+### `instances list`
+
+List Workflow instances.
+
+```sh
+wrangler workflows instances list <WORKFLOW_NAME> [OPTIONS]
+```
+
+- `WORKFLOW_NAME` <Type text="string" /> <MetaInfo text="required" />
+  - The name of a registered Workflow.
+
+### `instances describe`
+
+Describe a specific instance of a Workflow, including its current status, any persisted state, and per-step outputs.
+
+```sh
+wrangler workflows instances describe <WORKFLOW_NAME> <ID> [OPTIONS]
+```
+
+- `WORKFLOW_NAME` <Type text="string" /> <MetaInfo text="required" />
+  - The name of a registered Workflow.
+- `ID` <Type text="string" /> <MetaInfo text="required" />
+  - The ID of a Workflow instance. You can optionally provide `latest` to refer to the most recently created instance of a Workflow.
+
+```sh
+# Passing `latest` instead of an explicit ID will describe the most recently queued instance
+wrangler workflows instances describe my-workflow latest
+```
+```sh output
+Workflow Name:         my-workflow
+Instance Id:           51c73fc8-7fd5-47d9-bd82-9e301506ee72
+Version Id:            cedc33a0-11fa-4c26-8a8e-7d28d381a291
+Status:                ✅ Completed
+Trigger:               🌎 API
+Queued:                10/16/2024, 2:00:39 PM
+Success:               ✅ Yes
+Start:                 10/16/2024, 2:00:39 PM
+End:                   10/16/2024, 2:01:40 PM
+Duration:              1 minute
+# Remaining output truncated
+```
+
+### `instances terminate`
+
+Terminate (permanently stop) a Workflow instance.
+
+```sh
+wrangler workflows instances terminate <WORKFLOW_NAME> <ID> [OPTIONS]
+```
+
+- `WORKFLOW_NAME` <Type text="string" /> <MetaInfo text="required" />
+  - The name of a registered Workflow.
+- `ID` <Type text="string" /> <MetaInfo text="required" />
+  - The ID of a Workflow instance.
+
+### `instances pause`
+
+Pause (until resumed) a Workflow instance.
+
+```sh
+wrangler workflows instances pause <WORKFLOW_NAME> <ID> [OPTIONS]
+```
+
+- `WORKFLOW_NAME` <Type text="string" /> <MetaInfo text="required" />
+  - The name of a registered Workflow.
+- `ID` <Type text="string" /> <MetaInfo text="required" />
+  - The ID of a Workflow instance.
+
+### `instances resume`
+
+Resume a paused Workflow instance.
+
+```sh
+wrangler workflows instances resume <WORKFLOW_NAME> <ID> [OPTIONS]
+```
+
+- `WORKFLOW_NAME` <Type text="string" /> <MetaInfo text="required" />
+  - The name of a registered Workflow.
+- `ID` <Type text="string" /> <MetaInfo text="required" />
+  - The ID of a Workflow instance.
+
+### `describe`
+
+```sh
+wrangler workflows describe <WORKFLOW_NAME> [OPTIONS]
+```
+
+- `WORKFLOW_NAME` <Type text="string" /> <MetaInfo text="required" />
+  - The name of a registered Workflow.
+
+### `trigger`
+
+Trigger (create) a Workflow instance.
+```sh
+wrangler workflows describe <WORKFLOW_NAME> <PARAMS> [OPTIONS]
+```
+
+- `WORKFLOW_NAME` <Type text="string" /> <MetaInfo text="required" />
+  - The name of a registered Workflow.
+- `PARAMS` <Type text="string" /> <MetaInfo text="optional" />
+  - The parameters to pass to the Workflow as an event. Must be a JSON-encoded string.
+
+ ```sh
+ # Pass optional params to the Workflow.
+ wrangler workflows instances trigger my-workflow '{"hello":"world"}'
+ ```
+
+### `delete`
+
+Delete (unregister) a Workflow.
+
+```sh
+wrangler workflows delete <WORKFLOW_NAME> [OPTIONS]
+```
+
+- `WORKFLOW_NAME` <Type text="string" /> <MetaInfo text="required" />
+  - The name of a registered Workflow.
+
 ## `tail`
 
 Start a session to livestream logs from a deployed Worker.

src/content/docs/workflows/build/dynamic-steps.mdx

@@ -0,0 +1,35 @@
+---
+title: Dynamic steps
+pcx_content_type: concept
+sidebar:
+  order: 5
+
+---
+
+A Workflow does not have to define all of its steps statically: steps can be created programmatically and/or conditionally.
+
+This allows you to not only trigger steps based on specific input parameters, but to also name steps dynamically and set the retry configuration for a single step. 
+
+
+## Example
+
+You can create steps on-the-fly. You can create a step for each parameter passed to your Workflow, for each file you want to read from storage, or for calls to third-party APIs.
+
+For example, you can loop over each event, label the step dynamically, and have the step operate only over that `event`:
+
+```ts
+export class MyWorkflow extends Workflow<Env, Params> {
+	async run(events: WorkflowEvent[], step: WorkflowStep) {
+    // Dynamically create a step for each event passed to our workflow
+    // ... or for every file we want to read from R2 storage
+    // ... or each API call we need to make based on an incoming request
+		for (const event of events) {
+			await step.do(`processing ${event.id}`, async () => {
+				// Step logic for one event goes here
+				// You can also specify a StepConfig for each step, just as you
+				// would for any other step
+			})
+		}
+  }
+}
+```

src/content/docs/workflows/build/events-and-parameters.mdx

@@ -0,0 +1,104 @@
+---
+title: Events and parameters
+pcx_content_type: concept
+sidebar:
+  order: 10
+
+---
+
+When a Workflow is triggered, it can receive an optional event. This event can include data that your Workflow can act on, including request details, user data fetched from your database (such as D1 or KV) or from a webhook, or messages from a Queue consumer.
+
+Events are a powerful part of a Workflow, as you often want a Workflow to act on data. Because a given Workflow instance executes durably, events are a useful way to provide a Workflow with data that should be immutable (not changing) and/or represents data the Workflow needs to operate on at that point in time.
+
+## Pass parameters to a Workflow
+
+You can pass parameters to a Workflow in two ways:
+
+* As an optional argument to the `create` method on a [Workflow binding](/workers/wrangler/commands/#trigger) when triggering a Workflow from a Worker.
+* Via the `--params` flag when using the `wrangler` CLI to trigger a Workflow.
+
+You can pass any JSON-serializable object as a parameter.
+
+:::caution
+
+A `WorkflowEvent` and its associated `payload` property are effectively _immutable_: any changes to an event are not persisted across the steps of a Workflow. This includes both cases when a Workflow is progressing normally, and in cases where a Workflow has to be restarted due to a failure.
+
+Store state durably by returning it from your `step.do` callbacks.
+
+:::
+
+```ts
+export default {
+	async fetch(req: Request, env: Env) {
+	  let someEvent = { url: req.url, createdTimestamp: Date.now() }
+	  // Trigger our Workflow
+		// Pass our event as the second parameter to the `create` method
+		// on our Workflow binding.
+		let instance = await env.MYWORKFLOW.create(await crypto.randomUUID(), someEvent);
+
+		return Response.json({
+		  id: instance.id,
+		  details: await instance.status(),
+		});
+
+		return Response.json({ result });
+	 },
+};
+```
+
+To pass parameters via the `wrangler` command-line interface, pass a JSON string as the second parameter to the `workflows trigger` sub-command:
+
+```sh
+npx wrangler@latest workflows trigger workflows-starter '{"some":"data"}'
+```
+```sh output
+🚀 Workflow instance "57c7913b-8e1d-4a78-a0dd-dce5a0b7aa30" has been queued successfully
+```
+
+## TypeScript and type parameters
+
+By default, the `WorkflowEvent` passed to the `run` method of your Workflow definition has a type that conforms to the following, with `payload` (your data) and `timestamp` properties:
+
+```ts
+export type WorkflowEvent<T> = {
+  // The data passed as the parameter when the Workflow instance was triggered
+  payload: T;
+  // The timestamp that the Workflow was triggered
+  timestamp: Date;
+};
+```
+
+You can optionally type these events by defining your own type and passing it as a [type parameter](https://www.typescriptlang.org/docs/handbook/2/generics.html#working-with-generic-type-variables) to the `WorkflowEvent`:
+
+```ts
+// Define a type that conforms to the events your Workflow instance is
+// instantiated with
+interface YourEventType {
+  userEmail: string;
+  createdTimestamp: number;
+  metadata?: Record<string, string>;
+}
+```
+
+When you pass your `YourEventType` to `WorkflowEvent` as a type parameter, the `event.payload` property now has the type `YourEventType` throughout your workflow definition:
+
+```ts title="src/index.ts"
+// Import the Workflow definition
+import { Workflow, WorkflowEvent, WorkflowStep } from "cloudflare:workflows"
+
+export class MyWorkflow implements Workflow {
+    // Pass your type as a type parameter to WorkflowEvent
+    // The 'payload' property will have the type of your parameter.
+    async run(event: WorkflowEvent<YourEventType>, step: WorkflowStep) {
+        let state = step.do("my first step", async () => {
+          // Access your properties via event.payload
+          let userEmail = event.payload.userEmail
+          let createdTimestamp = event.payload.createdTimestamp
+        })
+
+        step.do("my second step", async () => { /* your code here */ )
+    }
+}
+```
+
+Note that type parameters do not _validate_ that the incoming event matches your type definition. Properties (fields) that do not exist or conform to the type you provided will be dropped. If you need to validate incoming events, we recommend a library such as [zod](https://zod.dev/) or your own validator logic.

src/content/docs/workflows/build/index.mdx

@@ -0,0 +1,13 @@
+---
+title: Build with Workflows
+pcx_content_type: navigation
+sidebar:
+  order: 2
+  group:
+    hideIndex: true
+
+---
+
+import { DirectoryListing } from "~/components"
+
+<DirectoryListing />