Every Pipedrive record carries its own visibility setting
Pipedrive lets visibility be set deal by deal. A team that has been selling for a few years therefore ends up with deals reserved for their owner, others open to the whole company, and a handful attached to a visibility group created for a reason nobody remembers.
That mess stays bearable while Pipedrive circulates between humans, because an over-curious colleague gets noticed. It changes nature the day an AI reads the pipeline, since an AI reads everything it is handed, fast and without anyone noticing.
The Pipedrive connector therefore starts from the setting you already have, rather than asking you to redo it somewhere else.
Visibility is read before the owner
The connector looks at two things on every record, in this order. The visibility setting first, the owner second. The order matters, because the owner only serves to file the record if the visibility proves the owner is the only one concerned.
When Pipedrive declares a deal reserved for its owner and their followers, the connector resolves that owner into a person in your organisation, then files the deal in that person's department. An AI plugged in for someone in that department reaches the deal, and an AI plugged in for another department does not.
In every other case, the deal waits for an administrator's decision. A deal open to the whole company is therefore less readable by an AI than a deal reserved for its owner, which is surprising at first. The reason lies in what Pipedrive's settings mean, which depends on your plan and on whether visibility groups are switched on. The connector acts only on the setting whose meaning it can prove, and it refuses to guess the others.
Filing a group-visible deal in its owner's department would grant access to colleagues in that department who are not in the group. That is the kind of gap nobody notices until an AI puts it on display. On HubSpot the connector goes by the record owner alone, since there is no setting of this kind to inherit, and the HubSpot page covers that.
What the connector concludes, record by record
Every row can be checked in your own Pipedrive, by opening the record concerned and looking at its visibility setting.
| What Pipedrive says about the record | What decides who may read it |
|---|---|
| A deal reserved for its owner and their followers | The owner's department, resolved through their work address |
| A deal open to the whole company | No department, because its real audience is wider than the owner's |
| A deal attached to a visibility group | No department, because that group may span several departments |
| A note or an activity | No department, because Pipedrive gives them no visibility setting |
| A record with no owner, or whose owner no longer has an address | No department, because the source no longer points at anyone |
An administrator can decide record by record. They can also tighten visibility inside Pipedrive, and the next pass will file the deals concerned with no further intervention.
Notes and activities carry no visibility setting
Pipedrive gives a visibility setting to deals, persons and organisations. It gives none to notes or activities, which carry no visibility field a connector could read.
Their content is read all the same. A note comes in with its text, an activity comes in with its subject, its type, its due date, its location and its comment. This is the richest material in a CRM, and often the most indiscreet, since it is where a salesperson writes what they really think of the person across the table.
With no setting to inherit, all those entries wait for an administrator's decision. They are read, they are filed in no department, and no plugged-in AI reaches them before a person has ruled. It is this connector's widest refusal, and the only defensible one on content Pipedrive itself does not say who may see. The page on governing your context describes how that decision is taken and kept on record.
The four objects read, and the fields you added
The connector names the fields it writes, object type by object type. Here is that list, and what it leaves aside.
When a person holds several email addresses or several numbers in Pipedrive, only the entry marked primary is written. The others stay in Pipedrive.
A visibility change does not announce itself
Pipedrive stamps every record with its last-modified date, and the connector uses it to reread only what moved. A handover of accounts goes through that route. When a deal changes owner, its date moves, it comes back on the next pass and it is filed in the new owner's department, provided its visibility still allows it.
A visibility change, on the other hand, does not necessarily move that date, and a change of visibility-group membership even less so. A reconciliation pass therefore re-resolves who may read every tracked record, without looking at whether its content changed. Between two reconciliations, a record can stay filed where it was. When that refiling fails, the record stays tracked at its previous filing, never at a wider one, and it is picked up again on the next reconciliation.
This periodic reconciliation exists because Pipedrive layers two signals, the owner and the visibility, which do not move together. The Zoho CRM connector reads no second layer of that kind, so it does without a catch-up pass.
The same caution governs how lists are read. When a page of results announces more to come without giving the means to reach it, the pass fails loudly and the object type concerned drops out of the comparison, instead of concluding that the unread records have disappeared.
The read key is a token created at the level of your Pipedrive company, and it travels in a request header. Pipedrive's classic authentication puts that token in the address being called, which the connector refuses, because an address ends up in logs and in intermediate servers.
What this connector does not do
A deal's stage arrives as an identifier, never as the label you read in Pipedrive. A plugged-in AI will therefore tell two deals apart when they are not at the same point, without being able to name the stage they are in.
The fields your team created in Pipedrive stay out. The connector writes a list of fields settled in its code, and the qualification note you added last year is not in it. Adding them is possible, it has not been done, and we would rather write that here.
Catching up on a visibility change happens at the reconciliation pass, not the second you change the setting. A record can therefore stay filed where it was for that interval. The drift always goes the same way, towards the previous filing, never towards a wider audience.
A deal deleted or archived in Pipedrive is not erased from your Kastel. It now carries a gone-at-the-source note, it stays readable by the same people, and only an erasure an administrator decides removes it.
Compare the plans before you connect your pipeline.
The pricing grid says what the free core already holds, all its connectors included, and what each paid plan adds around it, in particular for an organisation that has to prove who has access to what and who approved it.
See pricing
