Archive curated newsletter issues to document store.
For each newsletter the firm cares about, move every new issue out of someone's inbox and into the shared document store as a clean plaintext file with a sane filename — so the team can search it, cite it, and find it years later without digging through Outlook. One Zap per sender, all four steps identical.
Reference build
The firm subscribes to a handful of newsletters that are worth keeping — not in someone's inbox, but in the shared document store where the whole team can find them, search them, and cite them in memos. This automation is the four-step pipe that moves each issue from Outlook into SharePoint as a clean plaintext file with a sane filename.
Shown here for one sender (Harvard Business Review). Each newsletter we archive is a clone of this Zap with a different search query and a different destination folder — same four steps.
What lands in SharePoint
One plaintext file per issue, in the newsletter's folder.
| Field | Value | Source |
|---|---|---|
| Filename | {cleanedTitle}.txt | Email subject, run through the JS sanitizer. Always .txt. |
| File contents | stripped email body | Output of Formatter's strip_html on body.content. |
| Destination | /Documents/{Newsletter}/ | Hard-wired per-Zap. HBR Zap writes to /HBR, SpaceNews to /SpaceNews, etc. |
| On conflict | rename | Appends -1, -2 instead of overwriting. Weekly digests with stable subjects don't clobber each other. |
Gotchas
The risky parts are filename hygiene, conflict handling, and resisting the urge to build a single "universal" archiver.
- 01One Zap per newsletter, on purpose. Each sender gets its own search query, its own destination folder, and its own paused/active state. Trying to handle all newsletters in one Zap means one bad sender or a SharePoint quota issue takes down the whole archive — and the search query gets unreadable. Keeping them separate also means you can pause 'SpaceNews' for a week without touching 'HBR'.
- 02The trigger is a search, not an inbox watch. Outlook's new_email_search fires when a message matching the query lands in the watched mailbox. The query is just a free-text string ('Harvard Business Review') — broad enough to catch subject-line and sender variations, narrow enough not to grab random forwards. If the newsletter rebrands or starts sending from a new domain, the query is what you fix.
- 03Strip HTML before anything else touches the body. Newsletters are HTML-heavy with inlined CSS, tracking pixels, and base64 images. Saving the raw .html is unreadable in SharePoint preview, takes 10× the space, and breaks downstream search. The Formatter step gives us plaintext; that's what gets archived.
- 04The subject line becomes the filename, but never raw. The JS step strips every non-alphanumeric character (no slashes, colons, quotes, em-dashes), collapses runs of whitespace, and trims. SharePoint will accept a lot of those characters, but downstream tools (search indexers, OS sync clients) won't, and 'rename-on-conflict' can't dedupe filenames that differ only by punctuation.
- 05conflictBehavior = 'rename', not 'overwrite'. Two issues of the same newsletter can ship under the same subject (especially weekly digests with a stable title). Overwriting would silently erase last week's archive. Rename appends -1, -2 and we keep both.
- 06siteId and driveId are GUIDs, not paths. SharePoint's REST API doesn't accept 'Deal Team / Documents / HBR' — it needs the site GUID, the drive GUID, and the folder's drive-item id. We look these up once when wiring the Zap and paste them in; if SharePoint reorgs the site or someone renames the folder, the GUIDs still resolve.
- 07We archive plaintext, not the original email. No attachments, no headers, no reply-chain. The job is to make the newsletter's content findable and citable inside the firm's document store — not to be an email backup. If we ever need the original, it's still in Outlook.
- 08Adding a new newsletter is copy-paste, not redesign. Clone this Zap, change the search query, change the destination folder GUID, done. That's the whole maintenance story — and the reason we run separate Zaps per sender instead of trying to build a 'universal newsletter archiver'.
Swap matrix
Every layer is replaceable. The non-negotiables are a mailbox that can fire on a search query, and a document store that accepts API-uploaded files with a conflict policy.