A PandaDoc proposal is built before it is signed
PandaDoc is not only there to collect signatures. Proposals are assembled from templates, a product catalogue is wired in, and the document that reaches the client carries a pricing table that recalculates itself. That document therefore holds the negotiated price, the discounts granted and sometimes the length of the commitment, which is the part a company shares least willingly.
An AI does not need those figures to be useful here. Which proposals have been waiting three weeks for a signature. Which template gets used most often. How many deals expired without an answer. How many recipients are still missing on a document sent last week. Answering any of that never requires knowing a total.
So the connector stops at the record. Two reads exist, the list of documents in the workspace and the detail record of one of them. No third read goes down to the generated file, and the connector does not even hold an address to ask for it, because the download path is written nowhere in its code.
What a PandaDoc record holds, and what it never will
On a source that carries prices, every field counts. The connector names them one by one, and what follows is its own list.
A template's contents are not read either, only its name, as it appears on the documents built from it. As for metadata keys, they are excluded down to their labels, because a key is free text your integrations choose and a key can be an email address.
In PandaDoc, a folder is not a permission
The access key designates an entire workspace. Inside it, PandaDoc files documents into folders, and a folder looks a great deal like a read permission without being one. Its identifier says where the document is filed, it does not say who may open it. The connector therefore refuses to use it to decide anything at all.
There is consequently no original permission to inherit here, where a file dropped into a shared space would carry one. No document becomes readable until someone has designated, by hand, the department that will read the contracts. It has to be named, its name has to be a valid identifier, and the department itself has to be present in your organisation. If any of the three is missing, or if reading your governance fails, the documents stay on hold and no plugged-in AI reaches them.
No setting makes a proposal readable across the whole company, because that path does not exist in the connector. Since a PandaDoc key only covers one workspace, a group holding three of them wires up three connections, each carrying its own key and its own destination department. Choosing that department belongs to the governance of your context, not to the connector.
What happens to a record when the document changes state
Every row can be checked in your own PandaDoc account, by looking at a document's status and at what your Kastel says about it afterwards.
| In PandaDoc | In your Kastel |
|---|---|
| A proposal still in draft | A record with its name, its template and the draft status |
| The proposal goes out to the client | The same record, rewritten with its new status and dates |
| Every recipient has signed | The record rewritten, with the completion date and each recipient's state |
| The proposal is declined, voided or expired | The record rewritten with that state, never withdrawn |
| The document is deleted from the account | The record stays, marked absent from the source if reconciliation is enabled |
No change of state takes a document out of your Kastel, and deletion itself does not erase it. PandaDoc has no deleted status of any kind: a deleted document simply drops out of the list. What is observed is therefore its absence, and only if an administrator has asserted that the enumeration is complete. Knowing that a proposal was declined counts as much as knowing it was signed, so the refusal is written down like the rest.
A full inventory on every pass, with no shortcut
PandaDoc can filter its list on a modification date, and the connector does not use that filter. It does not surface deletions, so leaning on it would give a partial view, and a partial view would make never-enumerated documents look as though they had gone. Every pass therefore rereads the workspace's whole inventory. An unchanged document is not rewritten, and the department a document is attached to sits in its record, which is enough to catch up with a governance decision that changed no document at all.
Two precautions deserve naming, because they cost a little time and prevent gaps. When pagination repeats itself instead of advancing, or returns a page number it cannot read, the pass breaks off on a visible error rather than hand over an inventory with pages missing. And when a document's detail record does not come back, that document is replayed on the following pass rather than written by halves.
One last precaution concerns the shape of the answers. When PandaDoc returns an object where the connector expects a word, the field stays empty instead of being copied whole, which keeps an email address buried in a nested structure out of your Kastel. The same discipline applies to the other contract sources in the catalogue, with boundaries of their own, such as Dropbox Sign, where the team holding the key is the boundary.
What this connector does not do
It builds no document, sends no proposal and chases no recipient. The key requested from PandaDoc is a read key, and the connector holds no write verb towards your account.
A document's name and a template's name do come in, and both labels identify a contract. If your naming convention puts a client, an amount or a discount rate in there, that text comes in with the record. Which is precisely why a record waits for a department to be designated before anyone can read it.
The department you designate is taken on trust. The connector controls that the department figures in your organisation, without being able to control that it is your legal team. Naming a sales department would open contract reading to that sales department, with nothing in the connector standing in the way. The decision is yours, and it is visible in your governance.
A document deleted in PandaDoc does not leave your Kastel for that. Its record remains, marked absent from the source, with the same audience as before, for as long as no administrator has decided to erase it. And by default that reconciliation does not even run, because an enumeration nobody has vouched for would report live documents as gone. Removing the connection ends the reading without taking back what already sits in your Kastel.
Tell us what your proposals contain.
On a source that carries your negotiated prices, a conversation beats a web page. Describe your templates and how your teams use them, and we will tell you field by field what would come into your Kastel and what would stay at PandaDoc.
Get in touch
