pass pt 2

Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>

daprdocs/content/en/developing-applications/building-blocks/workflow/howto-author-workflow.md

@@ -9,7 +9,7 @@ description: "Learn how to develop and author workflows"
 This article provides a high-level overview of how to author workflows that are executed by the Dapr Workflow engine.
 
 {{% alert title="Note" color="primary" %}}
- If you haven't already, [try out the .NET SDK Workflow example](https://github.com/dapr/dotnet-sdk/tree/master/examples/Workflow) for a quick walk-through on how to use the Dapr Workflows.
+ If you haven't already, [try out the workflow quickstart](todo) for a quick walk-through on how to use workflows.
 
 {{% /alert %}}
 
@@ -26,8 +26,7 @@ Dapr Workflow logic is implemented using general purpose programming languages,
 
 The Dapr sidecar doesn’t load any workflow definitions. Rather, the sidecar simply drives the execution of the workflows, leaving all other details to the application layer.
 
-
-### Register the workflow
+## Register the workflow
 
 To start using the workflow building block, simply write the workflow details directly into your application code. 
 
@@ -105,7 +104,7 @@ app.Run();
 {{< /tabs >}}
 
 
-### Register the workflow activities
+## Register the workflow activities
 
 Next, you'll define the workflow activities you'd like your workflow to perform. Activities are a class definition and can take inputs and outputs. Activities also participate in dependency injection, like binding to a Dapr client.
 

daprdocs/content/en/developing-applications/building-blocks/workflow/howto-manage-workflow.md

@@ -29,7 +29,7 @@ To terminate your workflow, run:
 POST http://localhost:3500/v1.0-alpha1/workflows/<workflowComponent>/<instanceId>/terminate
 ```
 
-### Get metadata for a workflow
+## Get metadata for a workflow
 
 To fetch workflow outputs and inputs, run:
 
@@ -40,4 +40,4 @@ GET http://localhost:3500/v1.0-alpha1/workflows/<workflowComponent>/<workflowNam
 ## Next steps
 
 - Learn more about [how to manage workflows with the .NET SDK](todo) and try out [the .NET example](https://github.com/dapr/dotnet-sdk/tree/master/examples/Workflow)
-
+- [Workflow API reference]({{< ref workflow_api.md >}})

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-architecture.md

@@ -125,7 +125,7 @@ Dapr Workflows use actors internally to drive the execution of workflows. Like a
 
 As discussed in the [workflow actors]({{< ref "workflow-architecture.md#workflow-actors" >}}) section, workflows save their state incrementally by appending to a history log. The history log for a workflow is distributed across multiple state store keys so that each "checkpoint" only needs to append the newest entries.
 
-The size of each checkpoint is determined by the number of concurrent actions scheduled by the workflow before it goes into an idle state. [Sequential workflows]({{< ref "workflow-overview.md#task-chaining" >}}) will therefore make smaller batch updates to the state store, while [fan out/fan in workflows]({{< ref "workflow-overview.md#fan-outfan-in" >}}) will require larger batches. The size of the batch is also impacted by the size of inputs and outputs when workflows [invoke activities]({<< ref "workflow-capabilities.md#workflow-activities" >>}) or [child workflows]({{< ref "workflow-capabilities.md#child-workflows" >}}).
+The size of each checkpoint is determined by the number of concurrent actions scheduled by the workflow before it goes into an idle state. [Sequential workflows]({{< ref "workflow-overview.md#task-chaining" >}}) will therefore make smaller batch updates to the state store, while [fan-out/fan-in workflows]({{< ref "workflow-overview.md#fan-outfan-in" >}}) will require larger batches. The size of the batch is also impacted by the size of inputs and outputs when workflows [invoke activities]({<< ref "workflow-capabilities.md#workflow-activities" >>}) or [child workflows]({{< ref "workflow-capabilities.md#child-workflows" >}}).
 
 TODO: Image illustrating a workflow appending a batch of keys to a state store.
 

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md

@@ -129,9 +129,9 @@ Behind the scenes, the Dapr Workflow runtime:
 
 In the fan-out/fan-in design pattern, you execute multiple tasks simultaneously across potentially multiple workers, wait for them to finish, and perform some aggregation on the result.
 
-<img src="/images/workflow-overview/workflows-fanin-fanout.png" width=800 alt="Diagram showing how the fan out/fan in workflow pattern works">
+<img src="/images/workflow-overview/workflows-fanin-fanout.png" width=800 alt="Diagram showing how the fan-out/fan-in workflow pattern works">
 
-In addition to the challenges mentioned in the previous pattern, there are several important questions to consider when implementing the fan-out/fan-in pattern manually:
+In addition to the challenges mentioned in [the previous pattern]({{< ref "workflow-overview.md#task-chaining" >}}), there are several important questions to consider when implementing the fan-out/fan-in pattern manually:
 
 - How do you control the degree of parallelism?
 - How do you know when to trigger subsequent aggregation steps?
@@ -173,7 +173,7 @@ The key takeaways from this example are:
 - The number of parallel tasks can be static or dynamic
 - The workflow itself is capable of aggregating the results of parallel executions
 
-While not shown in the example, it's possible to go further and limit the degree of concurrency using simple, language-specific constructs. Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and 40 complete but then the process crashes, the workflow will restart itself automatically and schedule only the remaining 60 tasks.
+While not shown in the example, it's possible to go further and limit the degree of concurrency using simple, language-specific constructs. Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and only40 complete before the process crashes, the workflow will restart itself automatically and schedule only the remaining 60 tasks.
 
 ### Async HTTP APIs