The Setting I Missed That Broke Pipedrive for a Week

Table of Contents

1. Pipedrive field permissions silently broke stage updates in Zaps

I spent a whole Thursday chasing what I thought was a misconfigured filter in Zapier. The Zap was supposed to move a deal in Pipedrive to the next stage after a form submission. It fired green, no errors — other steps happened — but nothing updated in Pipedrive. At least, not visibly. Turns out, the stage change triggered in the Zap, but was silently ignored by Pipedrive because of a field permission setting buried in the Pipedrive web UI under a specific user role I’d changed two days earlier.

What tripped me up was this: even though the API key had the right scopes, Pipedrive field-level permissions still blocked the update. There wasn’t even a 403 response — something in the background accepted the call, but Pipedrive’s UI refused to reflect the change. The integration user didn’t have permission to update the Deal “Stage” field. End result: no error in Zapier, data just… didn’t move.

I only found it after running a diff on API logs by hand and noticing that the only thing not updating was fields marked “Custom or Restricted”. It’s not mentioned in the docs — had to ask their support team on a whim. If your Zap uses a Pipedrive account with custom roles or permissions, double-check Updates to core objects are actually allowed per field, not just per object type. UI lets you save the connection, but doesn’t test mutation rights.

“If a field is read-only for that user role, updates via API are invisibly ignored.” — Pipedrive engineer via email

2. Streak CRM webhooks occasionally drop events during tab switches

This one hurt during a live screen share. I had a Streak CRM pipeline set up with a webhook that triggered when a box hit a stage. The webhook fed into Make.com. It was supposed to filter for stage = Client Ready, then push data into a DocuSign template. Simple. Mostly worked. But sometimes, switching tabs in a Chrome session — weirdly — caused events to not fire at all.

After way too much testing, I traced it to the Streak browser extension. If a user switched tabs too quickly after dragging a box across stages, the webhook event never triggered or was sent blank. It only happened when someone dragged a box and immediately navigated away from Gmail before Streak’s sync caught up.

You can trigger this on purpose if:

You move a box between stages via drag-and-drop in the Gmail UI
You immediately close the tab before the page visibly refreshes
The webhook shows as successful but contains no fields

This is not documented. I ended up forcing Box stage changes via script through their API to prevent race conditions. Streak’s system logs show the event as “sent” — but the payload’s a skeleton. Better to bypass the front-end UI if your automation depends on reliability.

3. Delay loops in HubSpot cause phantom deal stage overwrites

HubSpot’s workflows let you insert delays between steps — which is normally fine — unless you forget that other automations can still run during that delay window. I had one where a user fills out an onboarding form, which sends the deal into “Activation.” But we also have a sales rep field that, when empty, prompts an internal assign workflow — which also writes to the deal if a rep’s selected.

Problem: the wrong rep got assigned on cold accounts because one of the workflows had a 1-hour delay before assigning rep = SDR1 — but that delay let another workflow slip in and assign SDR2 prematurely. I only saw it because a rep complained she was getting weird alerts on stale deals. Wasn’t until I opened the workflow history feed that I saw overlapping labeled events. The logs showed both assignments, but no warning about race conditions.

Quick lesson

HubSpot executes delays concurrently, not synchronously. This means:

Delays pause only that specific branch — others can still act
Workflows triggered by the same event don’t check global write locks
You can get silent overwrites if two workflows act on the same field
Delays longer than 15 minutes are particularly risky for ownership fields

I ended up splitting the ownership logic out and using a Zap that pushes to Airtable first, lets our lead router decide, then copies that into HubSpot via API with overwrite protection logic.

4. Bigin by Zoho rejects empty string values during PATCH requests

Bigin is the CRM I thought would be fun to try because it looked lightweight — and it is — but their API has some head-scratchers. The main one: if you attempt to clear a custom field via API using something like "custom_Field": "", the request silently fails. I lost two days to this.

The underlying issue is that Bigin treats empty strings not as “clear this field,” but more like “do nothing.” And sometimes — oddly — it triggers a validation error on a completely different field you didn’t touch. No mention of this in their API docs. The only thing that worked was omitting the field entirely from the payload.

Real example of what silently did not clear the field:

{
  "Lead_Source": "",
  "Contact_Email": "person@example.com"
}

Working version:

{
  "Contact_Email": "person@example.com"
  // Lead_Source excluded entirely if null
}

I confirmed this via trial and error with support. There’s no boolean switch or null handler like in Airtable. If you want to clear a field, you literally have to not talk about it like it’s Fight Club.

5. Freshsales tags get overwritten during form enrichment workflows

Freshsales is better than expected, honestly. But when you’re using enrichment tools like Clearbit or Apollo to prefill fields into new leads, don’t rely on Freshsales tags to stick. The enrichment workflows — even when they don’t touch tags — can replace a contact’s tags if the incoming payload doesn’t include the current ones.

It took me forever to prove it. I had tags like “demo-interested” on a lead that got enriched by a webhook step in Make.com. After enrichment, the tag disappeared. Why? Turns out the enrichment POST replaced the entire tags array with the new payload. If your webhook doesn’t explicitly send back the tags you want preserved, Freshsales overwrites them with null. No logs. No alerts. Data just vanishes.

Couple things that helped throttle that damage:

Fetch the current contact record first and merge tags instead of replace
Never send an explicit empty array for tags
Use PATCH carefully — avoid PUT unless you want a full overwrite

Also, Freshsales does not deduplicate tags. Multiple “Demo” tags will show up identical in the UI, even though they’re separate objects under the hood. I ended up using a tiny Kv store in Make to track tag state between flows. Absolutely not worth it, but unavoidable.

6. Capsule CRM Zap field mapping does not persist custom fields

Capsule’s Zapier integration looks normal, until you try to update records with custom fields — especially multi-select ones. I built a flow to update Deal records based on an Airtable view. The custom field appeared in the dropdown in Zapier initially, but within a few hours, it disappeared from choices and caused the Zap Editor to throw a validation error.

Refreshing the Zap didn’t help — I had to reconnect the Capsule account and recreate the entire field mapping. Happened three times in one week. Definitely some kind of sync timeout or stale schema cache in the Zapier app directory.

Also, Capsule separates user-created fields from system fields in a way that occasionally causes them not to show at all during webhook creation. In raw webhook payloads, custom fields sit under a nested structure Capsule calls “particulars.”

So if you’re working with Capsule custom fields in Make or directly via webhook, expect something like:

"particulars": [
  {
    "particular": "Industries: Fintech"
  }
]

That’s right — custom fields are mashed into a string array with no fixed schema. Good luck parsing that consistently.

7. Close.com app-to-app integrations fail in sandbox environments

Close (formerly Close.io) has great API docs — but when you spin up a sandbox account to test something like lead scoring via an internal dashboard, you’ll find half your integrations fail silently. I set up a staging Zap that pulled new Opportunities into a Notion database. Worked fine in production. In sandbox: Zap fired, logged as successful, but literally no data appeared.

Took a while, but I found out sandbox Close accounts don’t allow third-party integrations to access actual contact data, even if tokened correctly. The API sends back empty field arrays — no error, just missing content. Their support mentioned it’s a “security-by-default” configuration. Makes sense, but it would’ve saved hours if that was printed during the first auth test.

If your Close.com sandbox Zap is running with no visible effect, log the full payload early. I caught it eventually when I saw this in the webhook response:

{ "contacts": [] }

I had to move everything back to production with test leads to simulate real behavior. Just don’t trust anything you see in Close test environments unless you’ve added fake but complete data manually.