Turning emails into Notion database rows that stay useful

Some email is conversation, and an inbox handles that fine. The rest is records: receipts, job applications, support requests, booking confirmations. Records have fields, and fields want a table where you can sort by date, sum a column, and filter by status.

Notion databases are a comfortable home for those tables. The team already lives there, views are free, and a row can hold both structured properties and a page of context. The trick is getting email into rows without copy-pasting, and without recreating your inbox inside Notion.

That second failure is the common one. A database that receives every email is just an inbox with columns. Most of what follows is about deciding what makes a row, and what a row should contain.

A receipts log is the easiest win. Merchant, amount, date, and an invoice number cover most of what you check at tax time, and every row arrives already filled in. Sum the amount column per month and you have a spend report nobody had to build.

An applicant tracker suits small teams hiring without an ATS. Each application email becomes a row with name, role, source, and a stage property you move by hand. The email body lands in the row's page, so context travels with the record instead of living in someone's inbox.

A support log fits products where requests arrive by email. Requester, topic, status, and a received date give you a queue the whole team can work, instead of a label in one person's mailbox.

Pick one shape and run it for a month before adding another. Each database teaches you something about your senders (which merchants label totals clearly, which applicants paste their letter into the body), and the second build goes faster for it.

Every property must pass one of two tests: it can be extracted automatically from the email, or a human will reliably fill it by hand. Properties that fail both become columns of blanks, and blank columns teach people the database is half-maintained.

Four to six properties is a good ceiling. A date, an amount or a stage, the counterparty, and one select field for category cover the receipts log and the applicant tracker alike. Everything else is prose and belongs in the row's body, where search still finds it.

Resist per-edge-case properties. The one refund you received this year does not need a refunded checkbox on every row; it needs a sentence in that row's page.

Notion shows the title property in every view, every link, and every mention, so it carries most of the information load. A column reading Fwd: Your receipt forty times over is a table you cannot scan.

Build the title from extracted fields instead: merchant plus amount for receipts, name plus role for applicants, requester plus topic for support. The pattern of who, what, and how much almost always produces a line worth reading.

A transformer produces exactly this shape: CSS selectors or regex pull the fields out of the message into clean JSON, and one of those fields can be a preassembled title. The Notion channel then maps fields to properties and the title writes itself.

Dates belong in a date property rather than the title, with one exception: compact views sorted by title read better with the date in parentheses at the end. The example below does both, and the duplication costs nothing.

Decide per use case how much of the original email the row should carry. The support log wants the full body in the page, because the next person on the ticket needs the exact wording. The applicant tracker wants the cover letter text and nothing else.

The receipts log usually needs no body at all. The row holds the fields, and the original stays findable in your email pipeline, where retention runs from 7 to 365 days depending on plan. For records you must keep for years, accounting invoices say, download the PDF into real document storage and link it from the row. A Notion page is not an archive of record.

Whatever you choose, keep the Message-ID or the pipeline's email id in a small text property. When someone asks where a row came from, the answer is one lookup instead of an argument.

The pipeline shape is: a dedicated address, rules that admit only record-shaped mail, a transformer that produces the fields, and Notion as the delivery channel. On HideMy.world that is configuration rather than code: create receipts@yournick.hidemy.world, hand it to every service you pay, and attach a rule like subject contains receipt or subject contains invoice.

The transformer maps each sender's template to the same output fields, so the database sees one schema regardless of who sent the email. Test it by uploading a saved .eml file and checking the JSON before a single row is written.

Duplicates are handled upstream by Message-ID, so a merchant that re-sends a receipt does not create a second row. That matters more than it sounds, because deduping inside Notion after the fact is manual and miserable.

Feed the database only from automated, record-shaped senders. General correspondence stays in email, where replies live. The moment a human conversation becomes a row, someone has to maintain two places, and they will quietly stop maintaining one.

Add a status property only if someone actually works the queue. A status column nobody updates is worse than none, because it asserts things that are false. For a pure log like receipts, skip status entirely and add a per-quarter view instead.

Audit the feed occasionally. If a view has not been opened in a month, stop feeding it rather than letting rows pile up. A small database you trust beats a complete one you ignore.