Build your first template

Set a template up once and autofill produces identical output every time you run it: a few minutes of setup buys a reusable document. Templates are live configuration, so editing a field and saving means the next run uses the new logic. There is no deploy, no rebuild. Everything revolves around fields: the AI only ever looks for the fields you declare, never arbitrary data. (New to the vocabulary? See core concepts.)

Your account already has a workspace, so there is nothing to set up first. Open Templates and click + New template, then pick how to start: Upload your form (the fast path: your PDF or Word file becomes the template's pages), Start blank, or From a document on file (reuse a document already uploaded to this workspace). Either way an unsaved draft opens in the editor with your document previewing. Name it, and add more pages any time with + Add in the document bar above the preview: another upload or a blank page. Each document becomes a tab, next to the always-present Data tab. Nothing is written until you click Create template.

What a field is

A field is one value the template knows how to produce. Pick a type from the toolbar (Text, Number, Date, Select, Signature, Checkbox, Image; the + holds Address, Batch, Options) and click where the value should land. A field appears with a default static input reading "SAMPLE VALUE" and a write zone marking where it prints. Name it (Invoice Number), and it is ready.

Every field stores its value in case data under a stable key, so renaming the display label only relabels the column, it never moves the data. The type is load-bearing: a date field forces the AI to return a parseable date, a number a number. Use the batch type for repeating rows whose count varies (line items, for instance) rather than declaring Item 1, Item 2 by hand. Types also power the dashboard views you unlock on a higher plan: address fields feed the Map view, date fields the Calendar, numbers the Analytics totals.

The types in brief: text is the single-line default that auto-grows to multiple lines once the value wraps or the zone is tall enough; number for prices, totals, fees, and counts; date always prints as MM/DD/YYYY; checkbox is a boolean; select picks one value from a fixed list; options renders a radio or checkbox choice on the page with single or multiple selection; address prints as one line or splits into parts (street, city, state); image is uploaded once and reused at fill time for logos, stamps, or scanned signatures; signature captures a drawn signature: clients sign from the portal, and you can draw one yourself wherever you answer questions (the Data tab or the review form). Signatures are adopted or drawn, never read out of documents, so the Extracted source is unavailable for signature fields.

Where a field gets its value

Each field has an input that says where its value comes from, picked under Value Source:

A question input asks the person running the template to type the value, answered directly in the Data tab's grid. An extracted input lets the AI read the value off the incoming document; you can drop read zones to point it at the region to look in, or leave it open and let the AI find it. A static input bakes in a constant, the same text on every run. Mix them freely: a cover sheet might use a static input for fixed boilerplate, an extracted input for the vendor name, and a question for one thing the AI can't know.

The fourth source is From case, for the second document in a sequence. It reads a value another document already put on the case, matched by the field's name, so a payment request can carry the owner name the first document supplied without asking again or re-reading it. Add a short instruction under it only when the name alone is not enough ("use the legal entity name"). These values are read fresh on every run and never saved as a separate copy, so a case update carries into the next run on its own. An ID field cannot use it, since a case cannot look up its own identity.

The fifth source, From the delivery, covers the case where the value never appears in the document at all. It reads a value off whatever delivered the file, on arrival, before the file is filed and before a case exists. Which values are available depends on the intake that delivers it:

• An email intake offers Subject line, Sender address, and Message body.
• A Drive intake offers File name, Folder name (the watched folder the file appeared in), Date added to Drive, and Date last changed. The two dates arrive as real dates, so they sort and compare like any other date value.

Pick one under Delivery part. For every part except the message body you can leave Take part of it empty to use the value as it stands, or write a short instruction saying which piece you want ("the reference number after the dash"). The message body always needs an instruction, because a whole email is never a field value on its own.

This is also the one source besides the document that an ID field can use: if your reference number lives in the subject line or in the file name, files route to the right case without anyone opening the document. Choose the part deliberately, because it decides how cases group, and the app spells the consequence out under the picker. Every email from one sender address joins one case, which suits a case per client and not a case per project. An automation watches exactly one Drive folder, so keying on the folder name puts every file that automation ever ingests on a single case, which suits a folder that is itself the unit of work and not a general drop folder.

A template can hold parts from both intakes. A field reading an email part is simply left empty when a Drive automation delivers the file, and the other way round, so nothing is invented for an intake that cannot supply it.

Deeper transforms (AI prompts, calculations, multiple keys per field) are the subject of smarter templates; for a first template, the input sources are all you need.

NameInvoice Number

Typetext

Keyinvoice_number

Input sourceextracted

Place it and save

The write zone is where the value prints. Drag it to position, resize from the corners, and the value stamps at those exact coordinates at fill time. Placement is precise by design (for the full mechanics, see placement on the canvas). When the fields are placed, click Create template to save. You can also ask the workspace AI chat to draft placements for you: describe each field in plain language and confirm what it proposes.

If the PDF already has form fields built in, you do not have to stamp over them: AcroForm fields (text, checkbox, radio, dropdown) are detected and listed in a "Detected fields" panel, in the order they sit on the page, with a Select all control for turning several on at once. The app reads the printed label next to each box and names it in plain language (the technical field name stays visible underneath, for reference). A choice field shows the printed captions from the form itself, and a radio group becomes one single-choice question instead of one entry per option. Enabling a field fills it by name (checking the box, picking the option, choosing the dropdown value) instead of typing on top. When a box matches information the workspace already collects (a client name, an address, a date of birth), it imports set to fill itself from the case: run the template on a case and that row arrives prefilled, tagged From case data, and stays editable before the run. These rows always use the case's current information, and the app does not save a separate copy, so a case update carries into the next run on its own. Boxes the workspace cannot know stay questions. Encrypted government forms (many DMV PDFs, for instance) are decrypted on upload so their fields stay fillable. Value origin is tracked once a case runs: an AI-extracted value is marked as such, a manual edit flips it to modified, and a re-extract overwrites AI values but leaves manual edits alone.

Flat PDFs (no built-in form fields) have a faster path than placing every field by hand: upload a completed example. Where the Detected fields panel would sit, the app offers "Upload a completed example." Give it a filled-out copy of the same form and it compares the two documents, finds every spot where a value was written, names each field from the printed label next to it, picks the value type (text, date, number, phone, checkbox, signature), and places the write zones where the example shows them. It also checks its own work: the app fills the blank with the example's values, compares the result against your example, and nudges any placement that landed off. The completion summary is honest about what it could not do: a page it could not read at all is listed as skipped, and a page it read only partly is named too, so filled spots that never became fields are something you are told about rather than something you notice missing later. The fields arrive in the editor as a normal draft, exactly as if you had placed them yourself. Review them on the canvas, adjust anything, then save; nothing is stored until you do, and one undo removes the whole batch. Fields matching workspace information import as From case data rows here too. Both digital fills and scanned, hand-filled copies work, though a typed digital copy places most precisely. Run it again with a better example and the fields from the last run are replaced rather than added a second time, including after you have saved, and anything you added by hand stays. Closing the modal while it works stops it there: the run drops its requests and nothing reaches the template.

More samples make the template better

One example builds the template; more examples teach it. After the first run, the same window offers Add more samples of this document, and the button on the document card changes to Add sample. Drop in other copies of the same form, one or many at a time, filled or blank, even when a copy runs longer than the original because a section spilled onto an extra page. The app lines the copy's pages up against the original, works out on its own whether the copy is filled (a badge on the row shows what it decided, and you can declare it yourself before the run), and reads any extra pages to understand what makes that copy different. Each sample also has a note box: anything you tell it there ("page 3 sometimes spills onto an extra page") guides the whole pass, and a note that states a lasting fact about the document is kept as your note in the template's learned knowledge.

Everything a sample teaches lands in your draft directly, and the row reports what happened: fields confirmed, new fields added, choice lists extended, and observations noted. A sample never moves a field you placed: when a value sits somewhere meaningfully different in another copy, the app turns on the template's reflow setting instead, so the position is found fresh at fill time, and the row says so. Values follow an evidence ladder. One example cannot prove whether a value changes, so a written field starts by stamping exactly what the example showed, and the template runs immediately with no questions to answer. Values the sender printed on the form extract from each arriving copy, and fields matching workspace information pull from the case. Then samples promote the rest: a value that changes between copies, or is sometimes left blank, is not a constant, so it switches to asking per copy on its own. Samples also spot one value written in several places: if the same date sits on three pages and all three change together in the next copy, they fold into one field that asks once and writes everywhere. Signatures always stay yours to sign.

Anything the samples cannot prove stays yours to set. If a date is really today's date, or the due date plus thirty days, the app will not guess it: open the field and set the value source or the expression yourself. How a field's output looks (color, bold, font) stays yours to set in the field's appearance settings; signature spots become signature fields on their own. Nothing is saved until you save the template, so the draft is where you look things over; to correct something, tell the AI assistant or edit the field on the canvas. A field you deleted stays deleted; if a sample finds that spot again the row says it was skipped. A file that is not a copy of the document at all is refused with a plain sentence. Each template can learn from up to 10 samples of a document, and two templates that fill the same form learn separately, each for its own scenario.

The app also keeps notes on what it learns: how the document is laid out, which values look optional, how dates are written. You can see these notes on the document's card inside the template under What we've learned about this document, and they make every later read of that document sharper. The notes belong to the template and are saved with it. To correct or add to them, just tell the AI assistant ("the number in the top right is the OMO number, it is on every copy"). What you say is kept as your note and always wins over what was learned from samples.

The comparison reads in both directions. Values the sender printed on the form before it reached you (a reference number, a due date, an address block) become extraction fields: each one carries a read zone at the printed value's location and a rule naming the printed label, so when the next copy of that form arrives on a case, the app pulls those values into case data automatically. The completion summary tells you how many fields extract this way. One consequence worth knowing: once a template has extraction fields, running it fills the arriving document itself rather than the template's own blank copy, and the summary says so when that changes.

The same thing works from chat, with nothing set up beforehand. Open the workspace AI chat, drop in the blank form and a filled-out copy of it together, and ask for a template. The app works out which of the two is blank, so the order you attach them does not matter, and builds the template through the same comparison described above. When it finishes it names the fields it created and calls out any placement worth a second look. Two things differ from doing it in the editor: a template built this way saves itself as soon as it is ready, so you review it in the editor afterwards rather than before saving, and if the two files carry the same content the app says so instead of guessing, which usually means one of them is not a completed copy of the other. Checks like that one all run before anything is saved, so a pair the app cannot use leaves nothing behind in the workspace, and a build that stops partway for another reason offers Try again on the spot.

Run a simple fill

To produce a finished paper, open the template, click the arrow next to the Run button, and choose Run with your documents.... In the run modal's Documents section, click Replace, upload a sample PDF, and click Run. The engine reads each extracted field off your file, resolves the static and question values, and stamps everything onto the write zones you placed. The filled PDF downloads automatically and shows in the preview. Runs use the last saved version, so with unsaved edits you are prompted to save first.

That is the whole loop on the free tier: one template, one paper, in hand. Each run is also saved as a temporary case for 14 days, so upgrading to Pro opens a dashboard that already holds your recent runs. The full run engine (real cases, the run modes, batch fills across many records) lives in running autofill, and it opens up once you grow into the cases pipeline on a higher plan.

Troubleshooting

• Extracted values are wrong or blank. Confirm the input source is extracted (a question input is never read from the file), then refine the AI instruction on it. An extracted field with no value yet stays blank.
• Text lands in the wrong place. Click the write zone and drag it, or resize from the corners. Placement is exact.
• No Run button. It appears once a template with source pages is selected; a form-only template has nothing to stamp.

Related

• Smarter templates
• Placement on the canvas
• Running autofill
• Process an Invitation to Bid: see it in action