Two Dropbox products, two separate connections
Dropbox Sign carries the Dropbox name and yet connects differently. These are two distinct connectors, with two distinct keys, talking to two distinct interfaces. The Dropbox Sign one still answers under the HelloSign name the product grew out of, and that is the only address this connector ever talks to.
The difference that matters is how reading gets decided. A file stored in Dropbox takes its audience from the members of the shared folder holding it, and that signal exists. A signature request has no equivalent, since it lives in no folder, the interface exposes no per-request read permission, and the team designated by the key remains the only boundary available.
The connector draws the cautious conclusion. Since the interface offers it no audience signal, it files nothing before an administrator has named the department authorised to read contracts. No setting makes a request readable across the whole company, and that lock sits in the connector itself rather than in a configuration file.
What your signers typed does not come back
A signature request is not simply a file to initial. Your documents carry fields that people fill in, an account number, a home address, an amount, a ticked box that amounts to a commitment. Dropbox Sign returns those answers with the request, and not one of them gets through the door. The fields the sender pre-filled stay out too, as do the subject and the message sent to the signers, whose free text often carries the context of the negotiation.
It also neither reads nor resolves any of the URLs Dropbox Sign attaches to a request, the one leading to the signed file, the one for the signing journey and the one for the request itself. A URL that is enough to obtain a document has no business sitting in content an AI will later reread, so it is written nowhere.
It does record the title of the request, whether it is complete, declined or in error, whether it was sent in test mode, the number of signers, then each signer's state with the date they signed. A plugged-in AI therefore knows which requests are dragging and which are wrapped up, without knowing what the document says or who signed it by name.
The trail of a signature, without the signed document
The connector names these fields one by one, and it reads no others.
If the field answers stay out, it is because they hold what a person wrote about themselves, and because they are the part of a request that most escapes whoever sent it. Knowing that a commitment exists and where it stands does not require knowing what was typed into it.
The four decisions that open reading up
None of them is taken by the connector, and none is taken on your behalf. They come in this order.
Supply a read key
The connector asks for a read key belonging to one Dropbox Sign team. It checks that the key genuinely authenticates before keeping it, and a key that fails that check is not stored at all. A company running several teams sets up as many connections, and a key never crosses the boundary of its team.
Choose between the account and the team
By default, the list only returns the requests of the account holding the key. Seeing the whole team's requests is an explicit move, and it needs a key with an administration role. That choice stays open because a team-wide enumeration is a broader read, and a broader read is decided rather than applied by default.
Designate the department entitled to read
An administrator names the department the requests will be attached to. That name must be a valid identifier and the department must genuinely exist in your organisation. If it is missing, if it is invented, or if your governance cannot be read, the requests wait, and no plugged-in AI reaches them.
Assert, or not, that the inventory is complete
Deletion reconciliation only runs once an administrator asserts that the enumeration really does capture every request. Until then, a request missing from the list is not treated as deleted, because an incomplete inventory would make requests still in flight look withdrawn.
A declined request stays, and so does a withdrawn one
A signature obtained and a refusal are both changes of state, and the connector rewrites the record in either case. A declined request therefore keeps its place in your Kastel, carrying the state that says it was declined. Every pass rereads all the requests, for want of a last-modified filter on the Dropbox Sign list, and an unchanged record is not rewritten for all that.
Cancellation, on the other hand, leaves no trace on the Dropbox Sign side, since a withdrawn request simply drops out of the list with no state to say so. What gets recorded then is the absence itself, once the inventory has been asserted complete, and it is noted beside the record rather than made to take the record away. The safeguards we put around these reads hold here as they do on the PandaDoc connector page, which applies the same rule with boundaries of its own.
One precaution of the same family deserves naming. Pagination that goes round in circles, or hands back an unusable page number, makes the pass fail, and an account that can no longer be enumerated is set aside rather than compared. Without that rule, a truncated read would pass for a complete inventory and lead to the wrong conclusion, that the unread requests had been withdrawn.
What this connector does not do
It sets no signature in motion. None of its calls writes into Dropbox Sign, the key it asks for only reads, and chasing a signer or retrieving a file is not among the things it can do.
A request's title does come in, and that is the field identifying the contract. A company that names a request after the settlement agreement it covers, and after the employee it concerns, puts that information into your Kastel along with the request. We say so rather than leave it to be discovered, and it is the reason a record stays out of reach until a department has been designated.
By default it only sees the requests of the account whose key it holds. A team whose signatures go out from several accounts will therefore only hold part of its requests until team scope has been switched on, and switching it on needs a key with a higher role. A team surprised not to find a request in its Kastel starts by checking that setting.
A request withdrawn from Dropbox Sign does not leave your Kastel. Its record stays there, with the same audience as before, and only an administrator can erase it. That reconciliation does not even run before an administrator has asserted the inventory is complete, so by default the disappearance is not so much as observed. Unplugging the key interrupts the reading without pushing a single written record out.
Your signature requests deserve a conversation.
On a source that carries commitments and details typed in by people, a web page is no substitute for talking. Tell us which accounts your signatures go out from and who should be able to consult them, and we will tell you exactly where this connector's reading stops.
Get in touch
