Workflow Teardowns
Share:
Copy link
Copied!
For a long time my morning started the same way: open the laptop, find somewhere north of sixty unread messages, and spend the first half hour reconstructing what happened in the eight hours I was asleep before doing any work of my own.
An hourly background pass does that reconstruction now. It reviews the inbox, sorts each new message into one of four buckets, and puts what needs attention into a dashboard I open when I choose. I check it a few times a day instead of glancing at Gmail every twenty minutes.
It covers most of what I was paying Superhuman for. Superhuman makes the inbox faster to move through; this removes most of the reason to be in the inbox at all. The mail still lives where it always did. Claude handles the first pass of reading, sorting, and prioritizing before I open anything.
Key Takeaways
You check on your own schedule, not the inbox's. Instead of reviewing mail as it lands, you open an artifact when it suits you. Gmail becomes the backend Claude reads from rather than a screen you sit in front of.
What it requires:
A Claude account with Connectors, Scheduled Tasks, and Artifacts enabled.
A Gmail or Microsoft 365 account to connect.
An admin to enable the connector org-wide, if you want teammates running their own version. You can connect your own account without that; they can't.
The rules file has to exist before the task does. The scheduled task points at it by URL. A task created without a reachable rules file will still run, still label everything, and quietly do it from guesswork. Create the page first.
Keep read actions open and put a manual check on anything that writes, deletes, or drafts. Email is a realistic place for a prompt-injection attempt, where a malicious message tries to talk the agent into an action you didn't ask for. Requiring approval before anything changes is what caps the downside.
The rules file is what makes the workflow reusable. It's a plain markdown page that lives in the task folder and gets updated as you make corrections. Those corrections become instructions the next run consults, so you're not recalibrating from scratch every week.
The output lands in two places. Category labels get applied directly in Gmail or Outlook. The reviewable summary lives in the pinned artifact in Claude's sidebar. Nothing is moved, deleted, or exported.
Step-by-Step Workflow: Setting Up and Using Claude Email Triage
Setup runs about 15 to 20 minutes. Budget a few short correction passes over the first week before the categorization stops annoying you.
Every step below carries the same illustrative example, John Doe on Blue Chip's GTM Strategic Finance team, so you can see what each decision looks like against a real inbox.
1. Connect the inbox
Go to Settings → Customize → Connectors → Add → Browse Connectors, select Gmail or Microsoft 365, click Connect, and complete the authentication flow.
John connects his own Blue Chip inbox, not a shared team alias.
2. Set read/write permissions
On the connector's request screen, auto-allow read actions. Require manual confirmation for anything that writes, deletes, or drafts.
This carries more weight in John's inbox than most: it routinely holds customer-specific pricing terms and pre-close financial figures, so gating every write behind an approval is the conservative call.
3. Enable the connector org-wide, if you need to
Go to Organization Settings → Connectors and confirm your provider is listed. This is an admin-only toggle, separate from your own personal connection.
At Blue Chip, this is what lets the rest of the GTM Strategic Finance team stand up their own version once John's is working, instead of it staying a one-off.
4. Define the category taxonomy
Decide which buckets you want your mail sorted into. Urgent / To Do / FYI / Noise is a common starting point, and you can use whatever fits your inbox.
Two separate pieces get set up here, and they live in different places:
The category names go in the scheduled task prompt (Step 7), so the task knows which labels it can pick from.
The definitions, meaning what qualifies as Urgent for your inbox specifically, go only in the
## Category definitionssection of the rules page (Steps 5 and 6).
You don't repeat the definitions in the prompt.
Populating the definitions. Two options:
Write them yourself before the first run.
Let the first run infer them from how existing mail has already been labeled, then correct what it gets wrong.
The second only works if the inbox already has enough label history to learn from. Starting fresh means writing them yourself. Either way, treat the first version as provisional until a few real runs have tested it.
For John:
Urgent: a pricing deal that needs sign-off that day, a close-blocking issue from the Controller, a time-sensitive request from the CFO.
To Do: new deal-desk requests that need margin review, marketing budget requests, close work like variance explanations or accrual reviews.
FYI: journal-entry confirmations, marketing spend confirmations, deal-status updates that need nothing from him.
Noise: vendor pitches, conference invites, login codes, and similar mail.
5. Create the rules file before the task exists
This is the step people get backwards. The scheduled task needs a URL to point at, so the page has to be live before you write the prompt.
A task created without a reachable rules file will still run, still label your mail, and fall back on guesswork instead of your saved rules.
Create a Notion page or Google Drive doc, give it an unambiguous name like "rules.md — Email Triage," and copy the link.
John creates this in his personal Notion workspace rather than a shared team space. These are his own triage judgments, not a team-wide standard.
6. Seed the rules page with structure before the first run
An empty page is barely better than no page. Here's a working shape, drawn from a live example.
A document title and header: rules.md — Email Triage
A one-line statement of purpose at the top, saying what the file is and how it gets used:
"Rules file for the Email triage scheduled task. Rules, one per line, consulted on every run. Add new rules as they're provided."
This is what keeps the task treating the page as instructions rather than reference material.
## Sender rules — blanket rules keyed to a sender or a domain.
For John: "Any email from the Controller's address during close week goes to Triage/Urgent, regardless of subject."
## Category definitions — where the Step 4 taxonomy gets recorded, one sentence per bucket saying what belongs in it. The bucket names go in the task prompt; this section is what gives them meaning for this particular inbox.
If you're letting the first run infer them from label history rather than writing them yourself, leave the section thin and mark it derived from existing label history, confirm or correct, so a later reader knows these were inferred rather than instructed.
For John:
Urgent = pricing deals needing sign-off within 24 hours, close-blocking items, CFO time-sensitive requests.
To Do = deal-desk requests needing review, marketing budget requests, close tasks like variance explanations.
FYI = "journal entry posted" notices, marketing spend confirmations, deal status updates.
Noise = vendor pitches, conference invites, login codes.
## Run notes — mechanics rather than judgment. Start with the watermark rule:
Pick up mail received after the newest already-labeled message, found with a search on the four triage labels sorted newest-first.
This is what stops the task reprocessing the same mail on every run.
## Open questions — the one section you can't fill in before a run, because its contents are output rather than input: real ambiguities the task hits and should surface instead of guessing at.
Don't leave it blank, and don't omit it, since a header that isn't there is one the task won't think to write into. Seed it with a single line of instruction:
"Add any ambiguity encountered during a run here rather than guessing. Leave for the user to resolve."
A later entry in John's might read: "Does the Controller-urgency rule extend to automated notices from the close-management system, or only mail she sends personally?"
7. Create the scheduled task, pasting the rules-file link directly into the prompt
Go to Settings → Create Scheduled Task → New Task → Set up manually, name it specifically ("John's Email Triage," not something generic), and write the prompt with the actual URL inline. Include the four bucket names from Step 4.
A working version:
Naming the page in parentheses next to the URL takes two seconds and gives the task a way to recognize the right file if the link ever resolves oddly.
8. Pick a model, and skip the folder
Choose Opus, capable enough for triage calls without reaching for anything heavier. Leave the working-folder field empty.
That keeps John's hourly run firing whether or not his laptop is open, which is the point of scheduling it.
9. Set the run cadence
Cadence changes are manual. Nothing tightens it for you when close week arrives.
John's mail clusters around pricing-deal deadlines and the last few days before monthly close, so hourly during those windows and looser otherwise beats one flat interval.
10. Run the task once by hand, then correct what it gets wrong
Point it at a recent batch and review every call it makes.
This is where John's urgency line gets calibrated. A routine renewal quote and a time-sensitive competitive pricing deal look nearly identical in subject-line format, so expect the first pass to miss on exactly that distinction.
11. Build the review dashboard from the prebuilt artifact kit
Start from the kit rather than from scratch. Install sequence is in the next section.
It ships a working four-bucket dashboard you can use out of the box or adapt. Its default queries already match the Triage/* names from the Step 7 prompt, so the taxonomy lines up without renaming anything.
A huge thank you to Jason Staats for this artifact 🫶🏽
12. Roll out securely
Use Claude's Team or Enterprise plan rather than a personal account.
Before widening access, confirm with legal or compliance that routing this mail through an AI connector doesn't conflict with customer pricing confidentiality terms or Blue Chip's pre-close disclosure policies.
This check is real for John rather than procedural: customer-specific pricing terms are often confidential by contract, and close-week correspondence can carry material financial information ahead of external reporting.
Installing the Prebuilt Artifact Kit
It's a single zip, email-triage-artifact-kit.zip, holding two files:
CLAUDE.md— setup instructions written directly to Claude.email-triage-template.html— the artifact template itself.
Drag the zip into a Claude conversation and ask it to set the artifact up. Claude reads CLAUDE.md on its own and starts the sequence without you explaining the file's contents first.
When it prompts you, do not proceed with Demo Mode, or you'll be looking at a fictional dataset.
How Connectors, Scheduled Tasks, Artifacts, and the rules file fit together
These are four separate pieces of Claude, not one feature, and they're scoped differently.
The connector is account-level (your own connection) or org-wide (if an admin enables it in Organization Settings). It's the plumbing, shared across whatever you build on top of it.
The scheduled task is per-workflow. It's the engine that runs on a cadence and does the labeling.
The rules file is per-task memory, and in this setup it lives outside Claude entirely: a Notion page or Drive doc the task reaches through a connector, referenced by URL in the prompt itself. That's what makes it survive between runs, since each scheduled run starts in a fresh container that keeps nothing from the last one. A second task for a different mailbox wants its own rules page.
The artifact is a separate, pinned object in the sidebar, built in its own one-time conversation and reading live from the same connector. It isn't the scheduled task's conversation log. The run history is a record of what happened; the artifact is the interface you use.
The separation matters mostly when something stops updating. The fix is almost always in one of these four pieces specifically, not in "the whole system."
Published: