Three steps in one function: read, act, report. You read the first email, create a task from it, and send a confirmation email. The return is a dict telling the caller exactly what happened. What goes in that dict?
The email snippet you read, the task title you created, and maybe a status like "status": "sent" for the final report? So the caller sees all three steps?
Exactly. One key per step. The dict becomes the receipt — self-documenting, easy to print, easy to log:
report = {"email": title, "task": title, "status": "sent"}
So the function does read, write, write — three execute_action calls — and the dict aggregates the outputs?
One read, two writes, one dict. Guard the read (empty inbox returns an empty dict), then chain the two writes with the same snippet feeding both:
def multi_step_workflow() -> dict:
emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 1})
messages = emails.get("messages", [])
if not messages:
return {"email": "", "task": "", "status": "empty"}
title = messages[0].get("snippet", "")
toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {"title": title})
toolset.execute_action(Action.GMAIL_SEND_EMAIL, {"to": "me", "subject": "Workflow done", "body": title})
return {"email": title, "task": title, "status": "sent"}
If the task is created but the send fails, does the function still say "sent"? That seems misleading.
Good instinct. Today's version is happy-path — exceptions propagate so you see failures loud. The defensive version sets "status": "partial" when the send fails but the task succeeded. Week 4 covers exactly that wrapping pattern.
So this dict is a mini audit log for one run — every caller who stores these dicts gets a history of every automation firing?
One function, three steps, one receipt. Stack a hundred of these receipts in a file and you have a full workflow log. That's the shape of every serious automation.
TL;DR: One guarded read, two writes, one dict that documents each step.
max_results: 1, early-return on empty| Status | Meaning |
|---|---|
sent | Both writes succeeded |
empty | No email to act on |
partial | Defensive Week-4 value when one write failed |
A status field makes the receipt machine-parseable. Callers can filter a workflow log by status without re-reading the payload.
Three steps in one function: read, act, report. You read the first email, create a task from it, and send a confirmation email. The return is a dict telling the caller exactly what happened. What goes in that dict?
The email snippet you read, the task title you created, and maybe a status like "status": "sent" for the final report? So the caller sees all three steps?
Exactly. One key per step. The dict becomes the receipt — self-documenting, easy to print, easy to log:
report = {"email": title, "task": title, "status": "sent"}So the function does read, write, write — three execute_action calls — and the dict aggregates the outputs?
One read, two writes, one dict. Guard the read (empty inbox returns an empty dict), then chain the two writes with the same snippet feeding both:
def multi_step_workflow() -> dict:
emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 1})
messages = emails.get("messages", [])
if not messages:
return {"email": "", "task": "", "status": "empty"}
title = messages[0].get("snippet", "")
toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {"title": title})
toolset.execute_action(Action.GMAIL_SEND_EMAIL, {"to": "me", "subject": "Workflow done", "body": title})
return {"email": title, "task": title, "status": "sent"}If the task is created but the send fails, does the function still say "sent"? That seems misleading.
Good instinct. Today's version is happy-path — exceptions propagate so you see failures loud. The defensive version sets "status": "partial" when the send fails but the task succeeded. Week 4 covers exactly that wrapping pattern.
So this dict is a mini audit log for one run — every caller who stores these dicts gets a history of every automation firing?
One function, three steps, one receipt. Stack a hundred of these receipts in a file and you have a full workflow log. That's the shape of every serious automation.
TL;DR: One guarded read, two writes, one dict that documents each step.
max_results: 1, early-return on empty| Status | Meaning |
|---|---|
sent | Both writes succeeded |
empty | No email to act on |
partial | Defensive Week-4 value when one write failed |
A status field makes the receipt machine-parseable. Callers can filter a workflow log by status without re-reading the payload.
Create a free account to get started. Paid plans unlock all tracks.