Automating document intake

No one on your team clicks upload. The work that used to mean opening an email, downloading an attachment, naming it, and filing it against the right job now happens before anyone looks. A workspace processing 200 documents a week reclaims hours that were going to busywork, and nothing sits in an inbox waiting to be noticed. For the building blocks behind this, see core concepts.

What you need and how it's shaped

You need a workspace with at least one connected integration (Gmail or Drive) for file triggers. Time triggers need none. Every automation binds one trigger to one destination tuple across three builder nodes:

• Trigger: what fires it. Gmail filters by subject contains, sender contains, label, and read status (all set filters must match, AND-logic). Drive watches a folder, filtering by filename and MIME type. Time fires when a case sits idle in a mailbox for N days (no file needed); it only moves the case (no intake) to the Destination mailbox, on a daily schedule. Case Data automations react when watched case fields change (e.g. a Calendar reminder from a bid due date). See triggers.
• Destination: the mailbox the case lands in, plus the Document arriving files match (when extraction is off). Gmail automations can also set a Drive copy folder name: ingested files are additionally copied to that folder in the connected Google Drive (the app creates the folder on first use; move it anywhere afterwards). A matching existing case is moved here. A file already imported from the same source is skipped automatically (there's no duplicate setting).
• Extract Data (optional): a template that runs extraction inline. Picking it auto-resolves the document and its routing; the standalone Document selector hides. The node's Routing line states where each file's case ID will come from (read from the file itself, read off whatever delivered it, or a generated ID when the template has no ID field), and for a delivery-read ID it adds one line saying how that choice groups cases. An Edit in template shortcut sits underneath. Below that, a capture panel lists the template's delivery-reading fields and lets you add one in place: name it, pick the part, and optionally say what to take from it. Fields created here are ordinary template fields; they appear in the template editor and the Data tab like any other.

The capture panel matches the trigger. A Gmail automation shows From the email with a + Capture from the email button and offers Subject line, Sender address, and Message body. A Drive automation shows From Drive with + Capture from Drive and offers File name, Folder name, Date added to Drive, and Date last changed. If the template already carries a field reading the other intake's parts, that row still shows, with a note saying this automation leaves it empty.

Delivery is push-based: Gmail pipes new-message events in via Pub/Sub, Drive uses a Changes API webhook. Matches typically appear within a minute.

Walkthrough: vendor invoices from Gmail

Your AP team forwards every vendor invoice to a Gmail label Paperwork/Invoices; you want each as a case in the AP mailbox, extracted with your AP cover sheet template.

1. In Settings → Account, turn on the Gmail toggle row and grant access in the Google sign-in.
2. Click the Automations button at the bottom of the workspace sidebar (below the mailbox list), then New Automation.
3. On the Trigger node, pick Gmail, set Gmail label to Paperwork/Invoices. Leave Capture From Email at its default Files (sender and subject metadata are always kept).
4. On the Destination node, pick the AP mailbox.
5. On Extract Data, check Extract data with a template, pick the AP cover sheet template, and Done.
6. Click Save.
7. Forward a test invoice to the label. Within a minute, it appears in the AP mailbox.

TriggerGmail, label Paperwork/Invoices

DestinationAP mailbox

ExtractAP Cover Sheet template

Grouping Drive files onto one case

A Drive automation routes the same way a Gmail one does. When the extraction template's ID field reads a Drive part, the app reads that value as the file arrives and looks for a case already carrying it. A match takes the file, and if that case is not already in the automation's destination mailbox it moves there, with a line in its activity timeline recording the move. No match starts a new case under that ID. Only when nothing resolves does each file key its own case, which is what Drive intake did before.

The two useful keys behave very differently, so pick on purpose:

• File name groups files whose names yield the same value. With an instruction like "the reference number at the start of the name", every file carrying that number lands on one case. This is the usual choice.
• Folder name groups by the folder the automation watches. An automation watches exactly one folder, so every file it ever ingests joins a single case. That is right when the folder is itself the unit of work (one folder per job, one automation per folder) and wrong for a general drop folder, where it would pile a year of documents onto one case.

The app states this consequence where you make the choice: under the flow builder's Routing line, and under Delivery part in the template editor.

The date parts (Date added to Drive, Date last changed) arrive as real dates, so they sort and filter like any other date on the dashboard. They make poor identifiers: keying on one puts every file added on the same day onto the same case.

Patterns that hold up

Use one label per process: sharing a label across automations makes debugging hard, and only one automation processes each message with no way to pick the winner on overlap, so keep filters mutually exclusive. The capture pills (Body, Files) control what is stored beyond the always-kept sender and subject metadata; template fields that read the email resolve either way, so keep Body off unless you also want the full message text kept on the case (bodies add noise). Test one item before pointing a high-volume label at any automation, since the first version of any automation tends to have a misconfiguration.

Troubleshooting

Stopped firing. Open the card. An amber Auto-paused chip means the system disabled it; the banner explains why, usually OAuth expired, reconnect Gmail or Connected user removed from workspace. No chip and no banner, but nothing has arrived in days? Check that the connected account still shows as connected under Settings, then reconnect it: the app keeps the Gmail and Drive connections renewed on its own, so a quiet stop with no banner is worth a reconnect.

Matches but no case appears. Open the automation's Activity log under the canvas; the entry for that message names the failed step.

Wrong mailbox or document. The Destination node holds the mailbox; the document comes from the Extract template's link. Switch the template, or turn extraction off and pick the document directly.

Filed under the wrong case. When the Extract template has an ID field, intake reads that identifier (off whatever delivered the file, or out of the file itself) and routes the file to the matching case, or starts one. If a file lands on the wrong case, open the case, find the file in the activity timeline, and check the line under it: it names where the value was read and what it read as, such as Read from the email subject as EQ25998 or Read from the file name as J-4471, and No ID read when nothing resolved. Click the pencil to correct the identifier. If the corrected value belongs to another case, the app offers to move the file there; if no case has that ID yet, it offers to start one. You can also move a file from the Documents section's file menu (Move to another case or Start a new case from this file).

Everything starts a new case. A template with no ID field cannot route into existing cases, so every file opens a fresh case with a generated ID (shown with a muted auto tag). Add an ID field to the template so intake can attach files to the right job. A generated ID upgrades on its own the first time a run extracts a real identifier.

Attachments skipped. If Files is off in the capture pills, attachments are ignored. Attachments whose MIME type isn't in the automation's File types allowlist are filtered before ingestion. If the destination's category or extraction template can't resolve at run time, ingestion is skipped on purpose: fix the missing piece and the next message goes through.

Related

• Triggers
• The action pipeline
• Managing automations
• Process an Invitation to Bid: see it in action