diff --git a/tutorials/workflow/python/challenges-tips/versioning_workflow.py b/tutorials/workflow/python/challenges-tips/versioning_workflow.py
index c7d19401..6637325e 100644
--- a/tutorials/workflow/python/challenges-tips/versioning_workflow.py
+++ b/tutorials/workflow/python/challenges-tips/versioning_workflow.py
@@ -13,9 +13,25 @@ def versioning_workflow_1(ctx: wf.DaprWorkflowContext, order_item: str):
     
     return result_a + result_b
 
+@wf_runtime.activity(name='activity_a')
+def activity_a(ctx: wf.WorkflowActivityContext, order_item: str) -> int:
+    """
+    This activity processes the order item and returns an integer result.
+    """
+    print(f'activity_a: Received input: {order_item}.', flush=True)
+    return 10
+
+@wf_runtime.activity(name='activity_b')
+def activity_b(ctx: wf.WorkflowActivityContext, order_item: str) -> int:
+    """
+    This activity processes the order item and returns another integer result.
+    """
+    print(f'activity_b: Received input: {order_item}.', flush=True)
+    return 20
+
 """
 This is the updated version of the workflow.
-The input for activity_b has changed from orderItem (string) to resultA (int).
+The input for activity_b has changed from order_item (string) to result_a (int).
 If there are in-flight workflow instances that were started with the previous version
 of this workflow, these will fail when the new version of the workflow is deployed 
 and the workflow name remains the same, since the runtime parameters do not match with the persisted state.
@@ -29,4 +45,20 @@ def versioning_workflow_2(ctx: wf.DaprWorkflowContext, order_item: str):
     result_a = yield ctx.call_activity(activity_a, input=order_item)
     result_b = yield ctx.call_activity(activity_b, input=result_a)
     
-    return result_a + result_b
\ No newline at end of file
+    return result_a + result_b
+
+@wf_runtime.activity(name='activity_a')
+def activity_a(ctx: wf.WorkflowActivityContext, order_item: str) -> int:
+    """
+    This activity processes the order item and returns an integer result.
+    """
+    print(f'activity_a: Received input: {order_item}.', flush=True)
+    return 10
+
+@wf_runtime.activity(name='activity_b')
+def activity_b(ctx: wf.WorkflowActivityContext, number: int) -> int:
+    """
+    This activity processes a number and returns another integer result.
+    """
+    print(f'activity_b: Received input: {number}.', flush=True)
+    return number + 10
\ No newline at end of file
diff --git a/tutorials/workflow/python/child-workflows/README.md b/tutorials/workflow/python/child-workflows/README.md
index b00a8c75..c6eb7de5 100644
--- a/tutorials/workflow/python/child-workflows/README.md
+++ b/tutorials/workflow/python/child-workflows/README.md
@@ -4,7 +4,7 @@ This tutorial demonstrates how a workflow can call child workflows that are part
 
 ## Inspect the code
 
-Open the `ParentWorkflow.cs` file in the `tutorials/workflow/python/child-workflows/child_workflows` folder. This file contains the definition for the workflows and activities.
+Open the `parent_child_workflow.py` file in the `tutorials/workflow/python/child-workflows/child_workflows` folder. This file contains the definition for the workflows and activities.
 
 The parent workflow iterates over the input array and schedules an instance of the `child_workflow` for each of the input elements. The `child_workflow` is a basic task-chaining workflow that contains a sequence of two activities. When all of the instances of the `child_workflow` complete, then the `parent_workflow` finishes.
 
diff --git a/tutorials/workflow/python/child-workflows/childworkflows.http b/tutorials/workflow/python/child-workflows/childworkflows.http
index 81017efb..4ee6b7e5 100644
--- a/tutorials/workflow/python/child-workflows/childworkflows.http
+++ b/tutorials/workflow/python/child-workflows/childworkflows.http
@@ -1,6 +1,6 @@
 @apphost=http://localhost:5259
 
-### Start the ParentWorkflow workflow
+### Start the parent_workflow
 # @name startWorkflowRequest
 POST {{ apphost }}/start
 Content-Type: application/json
diff --git a/tutorials/workflow/python/external-system-interaction/README.md b/tutorials/workflow/python/external-system-interaction/README.md
index 1d66af88..e0718b45 100644
--- a/tutorials/workflow/python/external-system-interaction/README.md
+++ b/tutorials/workflow/python/external-system-interaction/README.md
@@ -74,7 +74,7 @@ graph LR
 
     ```json
     {
-        "id": "{{orderId}}",
+        "id": "b7dd836b-e913-4446-9912-d400befebec5",
         "description": "Rubber ducks",
         "quantity": 100,
         "total_price": 500
@@ -92,7 +92,7 @@ graph LR
     The app logs should look similar to the following:
 
     ```text
-   == APP - externalevents == Received order: Order { Id = b7dd836b-e913-4446-9912-d400befebec5, Description = Rubber ducks, Quantity = 100, TotalPrice = 500 }.
+   == APP - externalevents == Received order: Order { id = b7dd836b-e913-4446-9912-d400befebec5, description = Rubber ducks, quantity = 100, total_price = 500.0 }.
     ```
 
 6. Use the POST request in the [`externalevents.http`](./externalevents.http) file to send an `approval-event` to the workflow, or use this cURL command:
@@ -108,7 +108,7 @@ graph LR
 
     ```json
     {
-        "order_id": "{{instanceId}}",
+        "order_id": "b7dd836b-e913-4446-9912-d400befebec5",
         "is_approved": true
     }
     ```
diff --git a/tutorials/workflow/python/external-system-interaction/external_events/app.py b/tutorials/workflow/python/external-system-interaction/external_events/app.py
index 5ebe0713..f0009e4d 100644
--- a/tutorials/workflow/python/external-system-interaction/external_events/app.py
+++ b/tutorials/workflow/python/external-system-interaction/external_events/app.py
@@ -14,6 +14,8 @@ app = FastAPI(lifespan=lifespan)
 
 @app.post("/start", status_code=status.HTTP_202_ACCEPTED)
 async def start_workflow(order: Order):
+    print(f"Received order: {order}")
+
     """
     The DaprWorkflowClient is the API to manage workflows.
     Here it is used to schedule a new workflow instance.
diff --git a/tutorials/workflow/python/fan-out-fan-in/README.md b/tutorials/workflow/python/fan-out-fan-in/README.md
index 01a150e2..8806c3a1 100644
--- a/tutorials/workflow/python/fan-out-fan-in/README.md
+++ b/tutorials/workflow/python/fan-out-fan-in/README.md
@@ -76,11 +76,11 @@ graph LR
     The expected app logs are as follows:
 
     ```text
-    == APP - fanoutfanin == GetWordLength: Received input: word.
-    == APP - fanoutfanin == GetWordLength: Received input: is.
-    == APP - fanoutfanin == GetWordLength: Received input: the.
-    == APP - fanoutfanin == GetWordLength: Received input: shortest.
-    == APP - fanoutfanin == GetWordLength: Received input: which.
+    == APP - fanoutfanin == get_word_length: Received input: word.
+    == APP - fanoutfanin == get_word_length: Received input: is.
+    == APP - fanoutfanin == get_word_length: Received input: the.
+    == APP - fanoutfanin == get_word_length: Received input: shortest.
+    == APP - fanoutfanin == get_word_length: Received input: which.
     ```
 
     > Note that the order of the logs may vary.
diff --git a/tutorials/workflow/python/fan-out-fan-in/fanoutfanin.http b/tutorials/workflow/python/fan-out-fan-in/fanoutfanin.http
index 1b6448f9..a6329439 100644
--- a/tutorials/workflow/python/fan-out-fan-in/fanoutfanin.http
+++ b/tutorials/workflow/python/fan-out-fan-in/fanoutfanin.http
@@ -1,6 +1,6 @@
 @apphost=http://localhost:5256
 
-### Start the FanOutFanIn workflow
+### Start the fanoutfanin_workflow
 # @name startWorkflowRequest
 POST {{ apphost }}/start
 Content-Type: application/json
diff --git a/tutorials/workflow/python/monitor-pattern/README.md b/tutorials/workflow/python/monitor-pattern/README.md
index 8ef68dd2..722927f2 100644
--- a/tutorials/workflow/python/monitor-pattern/README.md
+++ b/tutorials/workflow/python/monitor-pattern/README.md
@@ -62,13 +62,13 @@ graph LR
     The expected app logs are as follows:
 
     ```text
-    == APP - monitor == CheckStatus: Received input: 0.
-    == APP - monitor == CheckStatus: Received input: 1.
-    == APP - monitor == CheckStatus: Received input: 2.
-    == APP - monitor == CheckStatus: Received input: 3.
+    == APP - monitor == check_status: Received input: 0.
+    == APP - monitor == check_status: Received input: 1.
+    == APP - monitor == check_status: Received input: 2.
+    == APP - monitor == check_status: Received input: 3.
     ```
 
-    *Note that the number of app log statements can vary due to the randomization in the `CheckStatus` activity.*
+    *Note that the number of app log statements can vary due to the randomization in the `check_status` activity.*
 
 5. Use the GET request in the [`monitor.http`](./monitor.http) file to get the status of the workflow, or use this cURL command:
 
@@ -84,6 +84,6 @@ graph LR
     "\"Status is healthy after checking 3 times.\""
     ```
 
-    *The actual number of checks can vary since some randomization is used in the `CheckStatus` activity.*
+    *The actual number of checks can vary since some randomization is used in the `check_status` activity.*
 
 6. Stop the Dapr Multi-App run process by pressing `Ctrl+C`.
diff --git a/tutorials/workflow/python/monitor-pattern/monitor.http b/tutorials/workflow/python/monitor-pattern/monitor.http
index af24e00c..34d476ab 100644
--- a/tutorials/workflow/python/monitor-pattern/monitor.http
+++ b/tutorials/workflow/python/monitor-pattern/monitor.http
@@ -1,6 +1,6 @@
 @apphost=http://localhost:5257
 
-### Start the Monitor workflow
+### Start the monitor workflow
 # @name startWorkflowRequest
 @counter=0
 POST {{ apphost }}/start/{{counter}}
diff --git a/tutorials/workflow/python/resiliency-and-compensation/README.md b/tutorials/workflow/python/resiliency-and-compensation/README.md
index b3596f1e..af0fef73 100644
--- a/tutorials/workflow/python/resiliency-and-compensation/README.md
+++ b/tutorials/workflow/python/resiliency-and-compensation/README.md
@@ -59,7 +59,7 @@ graph LR
     --url http://localhost:5264/start/1
     ```
 
-    When the workflow input is `1`, the `MinusOne` activity will subtract `1` resulting in a `0`. This value is passed to the `Division` activity, which will throw an error because the divisor is `0`. The `Division` activity will be retried three times but all will fail the same way as the divisor has not changed. Finally the compensation action `PlusOne` will be executed, increasing the value back to `1` before returning the result.
+    When the workflow input is `1`, the `minus_one` activity will subtract `1` resulting in a `0`. This value is passed to the `division` activity, which will throw an error because the divisor is `0`. The `division` activity will be retried three times but all will fail the same way as the divisor has not changed. Finally the compensation action `plus_one` will be executed, increasing the value back to `1` before returning the result.
 
     The app logs should output the following:
 
diff --git a/tutorials/workflow/python/resiliency-and-compensation/resiliency_and_compensation/app.py b/tutorials/workflow/python/resiliency-and-compensation/resiliency_and_compensation/app.py
index 5143b209..5dc055c8 100644
--- a/tutorials/workflow/python/resiliency-and-compensation/resiliency_and_compensation/app.py
+++ b/tutorials/workflow/python/resiliency-and-compensation/resiliency_and_compensation/app.py
@@ -12,12 +12,12 @@ async def lifespan(app: FastAPI):
 
 app = FastAPI(lifespan=lifespan)
 
-@app.post("/start/{input}", status_code=status.HTTP_202_ACCEPTED)
-async def start_workflow(input: int):
+@app.post("/start/{wf_input}", status_code=status.HTTP_202_ACCEPTED)
+async def start_workflow(wf_input: int):
     wf_client = wf.DaprWorkflowClient()
     instance_id = wf_client.schedule_new_workflow(
             workflow=resiliency_and_compensation_workflow,
-            input=input
+            input=wf_input
         )
     return {"instance_id": instance_id}
 
diff --git a/tutorials/workflow/python/task-chaining/README.md b/tutorials/workflow/python/task-chaining/README.md
index 2754e6fd..651d09f8 100644
--- a/tutorials/workflow/python/task-chaining/README.md
+++ b/tutorials/workflow/python/task-chaining/README.md
@@ -58,9 +58,9 @@ graph LR
     The input for the workflow is a string with the value `This`. The expected app logs are as follows:
 
     ```text
-    == APP - chaining == Activity1: Received input: This.
-    == APP - chaining == Activity2: Received input: This is.
-    == APP - chaining == Activity3: Received input: This is task.
+    == APP - chaining == activity1: Received input: This.
+    == APP - chaining == activity2: Received input: This is.
+    == APP - chaining == activity3: Received input: This is task.
     ```
 
 5. Use the GET request in the [`chaining.http`](./chaining.http) file to get the status of the workflow, or use this cURL command:
diff --git a/tutorials/workflow/python/task-chaining/chaining.http b/tutorials/workflow/python/task-chaining/chaining.http
index 055bdf93..0f2ab230 100644
--- a/tutorials/workflow/python/task-chaining/chaining.http
+++ b/tutorials/workflow/python/task-chaining/chaining.http
@@ -1,6 +1,6 @@
 @apphost=http://localhost:5255
 
-### Start the TaskChaining workflow
+### Start the task_chaining workflow
 # @name startWorkflowRequest
 POST {{ apphost }}/start