Why providing both fields does not guarantee both link
| Scenario | Person's existing org | Org ID passed on deal | Reported outcome |
|---|
| Matching | Org A | Org A | Deal links to Org A (works as expected) |
| Conflicting | Org A | Org B | Deal often keeps Org A, ignoring the explicit Org B value |
| Person has no org | (none) | Org B | Deal links to Org B correctly |
Why the conflict happens
A person record in Pipedrive can itself have an associated organization already set. When a deal-create request includes both a person_id and an explicit org_id, community reports describe cases where the deal ends up linked to the person but not to the organization value that was explicitly sent — behavior consistent with the person's own default organization association taking precedence over (or conflicting with) the separately specified organization field in that request.
This produces confusing results specifically when the organization you are trying to link differs from whatever organization is already attached to that person in Pipedrive — the deal silently keeps the person's existing association instead of the one the workflow intended.
Check the person's existing organization link first
- Look up the person record directly in Pipedrive (or via a Get Person step in the workflow) and check whether it already has an organization associated — if it does, and it differs from what your workflow is trying to set on the deal, that mismatch is the likely cause.
- Test creating the deal with only the organization ID (no person) and separately with only the person ID (no organization) to see which one the deal actually retains — this isolates which field is winning in the conflict for your specific data.
- Check whether the person needs its own organization field updated first (a separate Update Person step) rather than expecting the deal-create call to override it at deal-creation time.
Fix by resolving the person-organization link before creating the deal
If the organization intended for the deal should also be the person's organization going forward, update the person's organization field explicitly before or as part of the same workflow run, rather than relying on the deal-create call to reconcile a mismatch implicitly.
If the deal genuinely needs an organization different from the person's own default (for example, a contact who works with multiple client organizations), test whether creating the deal and then immediately issuing a separate Update Deal call with the organization ID produces a more reliable result than setting both on the initial create call.
// More reliable two-step pattern when person's org differs from the deal's intended org:
// Step 1 — Pipedrive node: Create Deal
{
"title": "New Deal",
"person_id": 456
}
// Step 2 — Pipedrive node: Update Deal (using the ID returned from step 1)
{
"id": "{{$json.id}}",
"org_id": 789
}
Sources checked for this guide
The community report below describes this exact association conflict when both person and organization IDs are provided on deal creation.
Frequently asked questions
I set both Person ID and Organization ID on the Deal Create node — why did only one link?
A person's existing organization association in Pipedrive can take precedence over a separately specified organization value on the same deal-create request. Check whether the person already has a different organization linked.
Should I update the person's organization before creating the deal?
If the organization you want on the deal should also apply to the person going forward, yes — update the person record explicitly first rather than relying on the deal-create call to reconcile a mismatch.
What if the deal genuinely needs a different organization than the person's own?
Test creating the deal first, then issuing a separate Update Deal call to set the organization explicitly — this two-step approach has been more reliable than setting both fields on a single create call in reported cases.
Does this only happen on Deal Create, or also Deal Update?
The reported cases are specific to Create; if you see similar behavior on Update, apply the same diagnostic — check the person's existing organization link and test the two-step create-then-update pattern.
