Why the field label is misleading
The parameter is labeled "Organization Name or ID," which reasonably suggests either format works, but community reports of this exact error describe it firing on a value that is clearly a real organization name in the account, which indicates the field's actual accepted input is narrower than the label implies for the specific node version and operation in question.
This is a field-mapping expectation problem, not evidence of a broken credential or a nonexistent organization — the same organization is generally findable and selectable correctly through Pipedrive's own UI. The Person field on the same Deal Create/Update node follows an identical pattern and is worth checking simultaneously if you are populating both.
Resolve the organization to its numeric ID via the API
Rather than guessing, call Pipedrive's own organization search endpoint with the name string you have, and use the numeric id field from a matching result — this is the same lookup n8n's own "Search" operation performs, made explicit so you can inspect exactly what comes back before wiring it into the create/update step.
curl "https://your-company.pipedrive.com/api/v1/organizations/search?term=Acme%20Corp&api_token=your-token"
// Response items include: { "id": 12345, "name": "Acme Corp", ... }
// Use the numeric "id" — not "name" — in the Organization Name or ID field.
Resolve the organization to its numeric ID first
Add a Pipedrive "Search" or "Get Many" organizations step ahead of the create/update step, filtering by name, and extract the returned numeric id field from the matching result rather than passing the name string forward directly into the Organization field.
If multiple organizations can share the same name in your Pipedrive account, add a check for more than one result and decide how to handle ambiguity (exact match on an additional field, or flagging for manual review) rather than assuming the first result returned is always correct.
Once the numeric ID is confirmed, pass that ID — not the name — into the Organization Name or ID field on the deal or person create/update node, and apply the identical lookup pattern to the Person field if that is also being populated from a name string.
Verify the fix
- Run the workflow against a test organization name and confirm the search step returns exactly the numeric ID expected before the create/update step executes.
- Confirm the created or updated record in Pipedrive shows the correct organization linked, not just that the node reported success.
- If your data source can produce organization names that do not yet exist in Pipedrive, decide explicitly whether the workflow should create a new organization first or fail cleanly — do not let an unresolved name silently fall through to this error in production.
Sources checked for this guide
The community report below documents this exact field-value error against a Pipedrive organization that exists in the account; the search endpoint is Pipedrive's own documented API.
Frequently asked questions
The organization definitely exists in Pipedrive — why is the name rejected?
This field's actual accepted format is narrower than its label suggests for this node version — it expects the numeric organization ID, not the display name, even though the label says "Name or ID."
How do I get the organization's numeric ID inside the workflow?
Add a Pipedrive Search or Get Many organizations step before the create/update step, filter by the name you have, and pass the returned numeric id field forward instead of the name string.
Does the same problem affect the Person field on the same node?
Yes — Person Name or ID follows the identical pattern. If you are populating both fields from name strings, resolve both to numeric IDs via a search step before the create/update call.
What if two organizations in Pipedrive have the same name?
Handle that explicitly — check whether the search returns more than one result and decide how to disambiguate (an extra matching field, or routing to manual review) rather than assuming the first result is correct.