Connecting...

Person or Deal: Where Should a Folio File?

When you connect a CRM and start sending folios, there's a quiet decision waiting for you in the template builder: when everything comes back — the field values, the document summaries, the files themselves — which record in your CRM should it all land on? The client's own record is the obvious answer, and for most templates it's the right one. But it isn't the only one.

This is a decision about where your team looks. It's not a technical setting, and there's no wrong answer that costs you data — but picking the one that matches how your practice actually works saves everyone a hunt later.

Why It Matters

Every folio produces a small pile of evidence: the answers a client typed, the plain-language summaries FolioReady's AI writes for each document, and the documents themselves. That pile has to live somewhere your team will think to look.

If your team works client-by-client — "pull up the Hendersons, what have we got?" — then the client record is where they'll look, and that's where the pile belongs. If your team works engagement-by-engagement — "where's the Henderson refinance up to?" — then the deal is the thing they open, and a pile sitting on the client record is one click further away than it should be, every time.

That's the whole decision. It's about matching the record your team already opens.

Where you set it

Open a template in the builder, go to Settings, and set Document Target. A new template starts with no CRM target — the No CRM sync option — so nothing is written to your CRM until you choose where it should land. Pick the client's own record for most templates, a related record like a deal for transaction-shaped work, or any other object your CRM exposes. You can change it at any time.

One Template, One Target

The Document Target applies to the whole template, and it moves everything together — field values, document summaries, and mirrored files all land on the same record.

That's deliberate. The alternative — field values on the client, documents on the deal — means anyone looking for the full picture has to know to check two places, and sooner or later someone won't. A folio's paperwork arriving in one piece is worth more than the flexibility of splitting it.

Filing Against the Client

This is the right choice more often than not.

Pick it when the folio is about the person rather than about a particular piece of work: onboarding paperwork, annual KYC refreshes, identity documents, updated contact details. These are facts about the client that stay true across every engagement you'll ever have with them, and they belong on the record that represents the client.

It's also the right choice if you're not using deals in your CRM in any serious way. If your pipeline is light or your CRM is mostly a contact list, filing against the client keeps everything in the one place you actually check.

Filing Against the Deal

Pick this when the folio exists because of a specific piece of work, and would be noise on the client record afterwards.

A mortgage application, a fund transfer, a specific onboarding round, a compliance pack for one transaction — these have a start and an end. The documents matter enormously while the work is live and become historical the moment it closes. Filing them against the deal means the next person to open that deal sees exactly what was collected for it, and the client record doesn't slowly fill up with paperwork from six different engagements.

The test is simple: if someone asked "what documents do we have for this piece of work?", would you want to answer from the client record or the deal? Answer that honestly and you've made the decision.

A deal is the common example, but it isn't the only non-client target. The Document Target lists every object your CRM exposes — so if your workspace defines its own objects, you can file a folio against one of those the same way. The choice is always the same underneath: which record does your team open when they go looking?

How the Deal Gets Chosen

FolioReady is deliberately conservative here, and it's worth knowing why. Two rules:

It never creates a deal. Your pipeline is yours. FolioReady writes into deals that already exist in your CRM — it will never add one on your behalf, because a deal appearing in your pipeline that nobody created is a genuine problem, not a convenience.

It never guesses which one. When you create a folio from a deal-targeted template, FolioReady looks at the deals your CRM already has linked to that client:

  • One deal — it's selected for you, and you'll see it named on the folio's Target step. There's nothing ambiguous to resolve.
  • Several deals — you pick the right one before the folio goes out. FolioReady shows you the candidates rather than choosing.
  • No deals — the folio is created anyway. You choose the deal later, from the folio's own page.

Silently picking the wrong deal would put a client's mortgage documents on their pension review. Asking you is cheaper than that mistake.

What Happens Before the Deal Is Picked

A deal-targeted folio with no deal chosen yet doesn't fail, and it doesn't block your client. It waits.

You can send it. Your client can open it, fill it in, and upload their documents exactly as normal — they see nothing different, and nothing about their experience depends on this. Everything is collected and held safely in FolioReady.

The moment you pick the deal, everything that was waiting goes through at once: the field values, the document summaries, and the files. Nothing is lost, nothing needs re-requesting, and you don't have to remember to push anything.

💡 Waiting is not an error

If you see a folio holding for a deal, that's the system doing its job — refusing to guess rather than filing your client's documents against the wrong piece of work. Pick the deal when you know it, and everything catches up on its own.

Where This Works Today

Deal targeting is available with Attio. If you're on Attio, you'll find Document Target in the template builder's Settings and the deal picker on the folio itself.

Once a deal is linked, the folio names it — and so does your folio list, so you can see at a glance what each request is filed against. If someone later detaches that deal from the client in Attio, the folio flags it: it keeps syncing to the deal you chose, but you'll know the link has changed.

On the other supported CRMs, folios file against the client record — which, for most templates, is what you'd choose anyway. If deal-level filing is something your practice needs on a different CRM, tell us; it shapes what we build next.

If You Switch CRMs

A Document Target is a record in a particular CRM, so if you change which CRM FolioReady is connected to, a template still pointing at the old one has nowhere valid to file. FolioReady flags this rather than writing to the wrong place: the template shows a yellow (stale) badge in your template list, and any folio it produces holds its sync — nothing is lost — until you open the template and pick a target in the new CRM.

You'll only see this if you actually switch CRMs. Reconnecting the same one leaves your targets untouched.

Practical Recommendations

Most of your templates should stay on the client. Onboarding, KYC, annual reviews, anything about the person rather than a project. Don't change what's working.

Use the deal for transaction-shaped work. If the template exists to support one application, one transfer, one case — file it against the deal. Your team will find it where they're already looking, and your client records stay readable.

Set it before you send, not after. The Document Target applies when a folio is created, so choose it while you're building the template. Changing it later only affects folios created from that point on.

If you're unsure, leave it on the client. That's the default for a reason. You can always create a second template for the deal-shaped work and leave the original alone — templates are cheap.

💡 Quick answer

Is this folio about the person or about a piece of work? Onboarding, KYC, identity — file it against the client, and leave the default alone. A mortgage, a transfer, a specific case — file it against the deal, and pick which deal when the folio is created. FolioReady never creates a deal and never guesses which one, so if it's unclear it will wait and ask rather than file it wrong.

Related