DocuSign→HubSpot via Zapier: why W‑9 field values go missing (and how to fix it)
Zapier’s DocuSign trigger returns envelope metadata, not W‑9 field values. Why it happens, how to confirm it, and three fixes to get your data into HubSpot.
GiveButter to Salesforce Nonprofit Cloud via Zapier (Donors, Donations, Recurring Gifts)
Learn how to sync GiveButter donations to Salesforce Nonprofit Cloud via Zapier. Covers field mapping, donor matching rules, and recurring gift troubleshooting.
TABLE OF CONTENTS
Quick answer: can GiveButter sync to Salesforce Nonprofit Cloud via Zapier?
Yes—GiveButter can send donation and donor data to Salesforce via Zapier, but you'll get the best results when you (1) standardize key fields (especially address/state/country), (2) implement a consistent donor matching strategy (ideally using a unique GiveButter Contact/Donor ID), and (3) build simple, modular Zaps instead of one "mega Zap."
This guide walks through a practical object + field map for Salesforce Nonprofit Cloud, including one-time gifts and recurring gifts, plus the most common troubleshooting pitfalls.
What you'll build (recommended data flows)
Aim for 3–4 small Zaps (or Zap paths) instead of one complicated workflow:
- Create/Update Donor in Salesforce when a new GiveButter transaction happens
- Create Gift Transaction in Salesforce for each GiveButter donation
- Handle Recurring Gifts so you can connect installments to the correct recurring plan/commitment
- (Optional) Map Campaign / Fund / Designation fields for reporting
Before you start: decide on your matching rules
The core decision is: How do we know a GiveButter donor already exists in Salesforce?
Use this hierarchy:
- GiveButter Donor/Contact ID (best): store it in Salesforce as a custom external ID
- Email address (good, but shared inboxes can break it)
- Name + address (last resort; more duplicates)
Recommended Salesforce custom fields (minimum)
Add these to your Salesforce donor record (whatever your org uses for donor—commonly Person Account / Contact equivalents):
GiveButter Contact ID(Text) — mark as External ID + Unique if your process supports itGiveButter Last Synced At(Date/Time) (optional)
Add these to your Gift Transaction record (or equivalent):
GiveButter Transaction ID(Text) — External ID + Unique (if possible)GiveButter Campaign ID(Text) (optional)GiveButter Recurring Plan ID(Text) (optional, but very helpful)
This "ID-first" approach prevents duplicate donors and makes troubleshooting faster.
Object + field map (GiveButter → Salesforce Nonprofit Cloud)
Your exact object names can vary by org configuration, but the mapping pattern stays the same:
A) Donor (GiveButter contact) → Donor record in Salesforce
Map:
- Full name → Name
- Email → Email
- Phone → Phone
- Address line 1/2 → Street
- City → City
- State/Province → State/Province
- Postal code → Postal code
- Country → Country
Important: if your Salesforce org uses picklists for State/Country, you must normalize values coming from GiveButter (more on this below).
B) Donation / Transaction (GiveButter) → Gift Transaction (Salesforce)
Map:
- Transaction ID →
GiveButter Transaction ID - Transaction date/time → Close Date / Gift Date
- Amount → Amount
- Payment method → Payment Method
- Transaction status → Stage/Status
- Donor reference → Lookup to Donor record
- Campaign or Fund (if available) → Campaign / Fund lookup or text field
- Notes / Source metadata (optional) → Description or Source fields
C) Recurring gifts (GiveButter) → Recurring commitment + installments (Salesforce)
Recurring gifts are where most Zaps break—because "plan" data and "transaction/installment" data are often separate.
Best practice:
- Create/Update a Recurring Commitment record when you detect a new recurring plan
- Create a Gift Transaction for each installment and link it back to the Recurring Commitment
If GiveButter's Zapier trigger doesn't provide every recurring field you need (frequency is a common one), store what you have and plan a quick manual QA step on the first few records until your mapping is stable.
Build it in Zapier (simple, reliable Zap structure)
Zap 1: New GiveButter transaction → Find/Create Donor
Trigger: GiveButter — New Transaction
Step 1: Formatter (optional) — normalize country/state
Step 2: Salesforce — Find record (by GiveButter Contact ID if you have it, else by Email)
Step 3: Salesforce — Create/Update donor record
Step 4: Store the Salesforce donor record ID for later steps
Zap 2: New GiveButter transaction → Create Gift Transaction
Trigger: GiveButter — New Transaction
Step 1: Salesforce — Find donor (same matching rule as Zap 1)
Step 2: Salesforce — Create Gift Transaction record (use
GiveButter Transaction ID as your external ID)Zap 3: Recurring gift handling (when applicable)
Depending on available triggers, you can:
- Use Zapier Paths to branch when a transaction is part of a recurring plan
- Or create a dedicated Zap that runs when a recurring plan is created/updated
If recurring-plan triggers/fields are limited, start by:
- Writing the recurring plan ID to the transaction record
- Creating a Recurring Commitment record the first time you see a new plan ID
- Linking subsequent installments by that plan ID
Troubleshooting: the most common pitfalls (and fixes)
1) Country/state picklist mismatches (USA vs US vs United States)
Symptom:
- Salesforce errors when creating/updating address fields
Fix:
- Use Zapier Formatter or a lookup table to convert:
USA→US(or whatever your Salesforce picklist expects)- Full state names → state codes (or the reverse)
Also validate:
- Null/blank address values (don't overwrite good data with blanks)
2) Duplicate donors
Symptom:
- Multiple donor records created for the same person
Fix:
- Make
GiveButter Contact IDyour primary match key - If you can't, use Email match and add a "duplicate review" view in Salesforce
3) Overcomplicated "Copilot" Zaps
Symptom:
- Too many steps, nested searches, slow runs, hard-to-debug failures
Fix:
- Split into smaller Zaps
- Use a single "Find/Create" donor step and reuse that ID
- Prefer deterministic external IDs (transaction ID, contact ID)
4) Recurring gifts break mid-stream
Symptom:
- Installments create but don't link to the right recurring plan/commitment
Fix:
- Store the recurring plan ID everywhere (donor + transaction)
- Build a "find or create recurring commitment by plan ID" step
Recommended minimum QA checklist
Before turning everything on for the full org:
- Confirm 10 new transactions sync correctly
- Confirm 3 recurring donors create:
- 1 recurring commitment record (plan)
- 1 gift transaction per installment
- Confirm campaign/fund reporting looks correct (if you map it)
- Confirm no "USA/State" errors appear in Zapier task history
Want help mapping your exact object model?
If you want a second set of eyes on your Salesforce Nonprofit Cloud configuration—or you'd rather have someone build the Zaps with clean external-ID matching—book a discovery call: https://connex.digital/book/website
Related Posts
How a Small Fabric Manufacturer Stopped Losing Inventory to a Pencil — and Took Back Control of Its Zapier Stack
A small fabric manufacturer lost inventory to handwritten label corrections. Connex fixed their Zapier stack, migrated ownership, and automated notifications — saving ~$17k/yr.
Airtable to Supabase sync (new rows, updates, backfill) — a practical migration plan
A practical Airtable to Supabase sync plan for new rows, updates, and backfill, using stable record IDs, unique constraints, and UPSERT to prevent duplicates.
