A signed contract is the most sensitive document a company holds
A signed contract carries the price you negotiated, the term you accepted, the clause that lets you walk away, and the identity of the people who signed it. It is the document a director shows to two or three people in the company, and to nobody else.
The useful questions, though, do not require opening it. Do we have a completed envelope with this client. How long has that one been waiting for a signature. Who on our side sent it. How many recipients still have to sign. The Docusign connector is built to answer those and to stay away from the rest, like the other sources in the connector catalogue.
Docusign offers no read-only authorisation, so read-only is written into the connector
Most tools offer an authorisation that only allows reading. Docusign does not. The narrowest one it exposes also allows sending and signing, which means any integration plugged into Docusign technically holds the right to act on your envelopes.
The connector treats that gap as a coding problem rather than a warning to tuck into a documentation page. It exposes one verb only, reading. And before it opens any connection at all, it inspects the path it is about to call and refuses any path naming a specific document, an archive, a combined bundle or a signing certificate.
There is therefore no method able to download a signed PDF, and a coding mistake that built such a path would be stopped before the call. The content of your contracts is not filtered after being read, it is never read. The same discipline covers the document's fields: the values entered in them, the ones carrying the amount and the term, are never requested from Docusign. The engine's other outbound rules are described on the security page.
The envelope and its state, never the document
On a signature source, the boundary runs between the existence of a contract and its content. Here is where it sits, as it is written in the connector.
Field values are excluded for a precise reason: that is where the negotiated amount, the commitment term and the notice period can be read. The subject of the outgoing message is excluded for another, just as concrete: it is the free-text field where a salesperson writes the context of the deal.
What becomes of an envelope when its status changes
Every row is checkable in your own Docusign account, by opening the history of one envelope.
| Envelope status in Docusign | What the record becomes in your Kastel |
|---|---|
| Sent, waiting for a signature | A record exists, and its status says it is waiting |
| Completed, every recipient has signed | The same record moves to the completed status, with the completion date |
| Voided by the sender | A status change, never a disappearance. The record is rewritten with the void date |
| Declined by a recipient | A status change as well. The refusal stays readable by the same people |
| Deleted in Docusign | The record is marked as gone at the source and kept, until an administrator decides to erase it |
A void and a refusal are management facts rather than erasures, and the connector treats them as such. Deletion calls for one extra precaution: the comparison that spots a vanished envelope only runs when an administrator has asserted that the account is enumerated in full. Without that assertion nothing is flagged as gone, because a user who cannot see everything would produce false disappearances.
A contract is never readable company-wide
Docusign sets no read permission at the level of an envelope. The account is the boundary, and the connection acts on behalf of one designated user, whose envelopes it sees. There is therefore no original permission to inherit, unlike a shared file that already carries the list of people with access.
The connector refuses the easy answer, which would be to make contracts readable by everyone. Two routes exist, and only one is active at a time. Either your envelopes carry custom fields, and an administrator maps a field value to a department, envelope by envelope. Or no value is mapped, and the whole account is filed under one legal department, provided an administrator has named it and that department genuinely exists in your organisation.
Three situations leave an envelope on hold. A field value can be mapped to no department at all. Two values on the same envelope can point at two different departments, and the connector would then rather not choose on your behalf. A department can be named in the configuration and absent from your organisation. With no setup at all, that covers every one of your envelopes, and it is the intended behaviour on the first pass.
What each connected AI can then reach follows from that decision and from nothing else. How your Kastel decides who reads what is worth reading before you plug in a source at this level of sensitivity.
What this connector does not do
It does not manage your contracts. It knows neither their expiry date, nor their term, nor their obligations, and it will not warn you before an automatic renewal. All of that lives in the document, and the document is not read. A contract lifecycle tool does that job, and this connector does not replace it.
Your Kastel knows that an envelope exists and what its document is called. It does not know who signed it, since recipient names are never read. If the filename does not name the counterparty, your Kastel does not know it, and we would rather write that here than let you find out.
The connection acts on behalf of one designated user and sees only the envelopes that user sees. An envelope sent from another account, or invisible to that user, never comes in. The read scope therefore depends on an administrative choice you make when you plug the source in.
An envelope deleted in Docusign is not erased from your Kastel. It stays in your Kastel under a gone-at-the-source note, open to the same people as before, and erasing it remains an administrator's gesture. On contracts, keeping is the cautious behaviour, and the disappearance is itself a management fact.
Ask us your questions before you plug in your account.
Electronic signature is the kind of source where we would rather answer precise questions than let you guess from a web page. Tell us what you want an AI to know about your contracts, and we will tell you plainly where this connector stops.
Get in touch
