A field placed on a template is empty until it is told where its value comes from. Binding it is what turns a layout into a document that fills itself.
The catalog
Every field you can bind to is listed in one searchable catalog, built from what the platform actually knows about that kind of record.
For a deal template that means the company, the contact, the deal's own values and terms, your own organisation's details, and anything your organisation has added as a custom field.
Custom fields are included automatically. If your organisation tracks something the platform does not ship with, it is bindable here without anybody adding support for it.
Why the list is grouped the way it is
The data model organises fields by which record they belong to: client, deal, employee, invoice, company, system, custom.
The palette does not show them that way. It regroups them at the moment of display into the categories somebody placing a chip actually thinks in: identity, address, contract terms, and so on.
That is a deliberate refusal to let the data model leak into the interface. A person laying out a contract is thinking "where does the address go", not "is an address a client attribute or a company attribute", and making them learn the answer would be making them do the system's job.
The counterparty group renames itself to match the template. A People template calls it candidate details; a Sales template calls it client details. Same fields, and the label matches the document in front of you.
Signature fields belong to a signer
A signature field is bound to a role rather than to a person: the client signs here, your organisation signs there.
The actual people are named later, when the document is sent, which is what lets one template serve every customer.
Get the roles right in the template and the send step becomes a two-field form.
Company fields
Your own organisation's details are in the catalog alongside the counterparty's: legal name, registered address, registration numbers, and whatever else has been configured.
Bind them rather than typing them. Company details change more often than people expect, through a move, a re-registration or a rename, and a bound field updates everywhere while a typed one becomes forty templates to hunt through.
What happens at send time
Every bound field is resolved against the record, and the result is checked before anything goes out.
A field that cannot resolve is flagged rather than left blank. That check exists because the failure it prevents is severe: a contract that goes out with an empty value where the price should be is worse than one that never went.
Common causes are a record missing a value, a field bound to something that does not apply to this record type, and a binding orphaned by a rename in the editor. All three are visible before sending, and all three are quick to fix.
Automatic placement
Uploaded documents can be scanned for likely field positions, so a PDF with an obvious signature line gets a suggestion rather than requiring every chip to be placed by hand.
Treat it as a first pass. It saves time on a long document and it is a starting point rather than an answer, so check what it proposed before publishing.
When a field will not resolve
Four causes, in rough order of how often they occur.
The record is missing the value. Most common by far, and the fix is upstream: fill it in on the deal or the person.
The field is bound to something that does not apply. A deal field on an employee template will never resolve.
The binding was orphaned by a rename in the editor. Re-bind it.
The field was never bound at all, which is easy to do when placing many at once.
The resolution check before sending names which field failed, so this is a diagnosis of seconds rather than a hunt.
Designing bindings well
Bind, do not type. Any value that exists on a record should come from the record. Typed values are the ones that go stale and the ones that end up wrong.
Prefer the specific field. Where both a general and a precise field exist, take the precise one. General fields tend to be assembled from other fields and are harder to correct when they read oddly.
Test against a real record, not a tidy one. The record with a long legal name, a missing middle field and an address in a different format is the one that reveals the problems.
Watch for empties. A field that is often blank on real records will often be blank on real contracts. Either make it required upstream or take it off the document.
The counterparty label
One small behaviour that confuses people the first time.
The group holding the other side's details renames itself to match the template type. On a Sales template it says client details; on a People template it says candidate details.
Same catalog underneath. The label bends so the person laying out an offer letter is not asked to think of a candidate as a client, which is exactly the kind of small friction that makes an internal tool feel like it was built for somebody else.
Fields that are not from records
Not everything on a document comes from your data.
Things the signer fills in are placed as ordinary inputs and left unbound: a date they choose, a reference of theirs, a checkbox they tick.
Things that are always the same should be typed into the document rather than made into fields. A field bound to nothing is a field that will one day be blank.
Things about the moment, like the date of signing, are handled by the system rather than by you.
The test for whether something should be a bound field: does the answer live in a record, and could it change. Both yes means bind it. Either no means it is text or an input.
The wider point
This is the reason Documents lives inside the platform rather than beside it.
A separate signing tool receives a finished file and knows nothing. Everything in it was typed by somebody, which means everything in it can be wrong, and nothing in it updates when the underlying fact changes.
Here the document is a view of records that already exist. That is why there is no reconciliation step, no export, and no version of a contract that quietly disagrees with the deal it belongs to.
Did this answer your question?
No, ask a person