#Nonprofit Success Pack20 utenti parlano di questo argomento

Hi Preeti, adding a late option since the thread mentioned Skyvia and 

Apps Script. 

Disclosure: I work at TwinStack, and we ended up building a free 

AppExchange app for this after hitting the same requirement on 

nonprofit projects. 

Harry's point about Apps Script is right, and that is essentially the 

approach that works when $0 is a hard requirement. The form posts 

directly to your org, so there is no middleware to pay for. The 

downside is that someone has to build and maintain the OAuth handling, 

error retries and token refresh. 

We packaged that up so admins do not have to: 

Free with no submission cap, and no third party in the data path, 

which tends to matter for nonprofits collecting client or beneficiary 

information. 

One NPSP-specific note worth knowing before you install. It captures 

submissions to its own Form Response object rather than writing 

straight to Contact. That is deliberate: household accounts and 

affiliations mean an integration that guessed where to write would 

get it wrong. You route it with a record-triggered Flow instead, which 

also means the raw submission is preserved for audit and grant 

reporting. 

Happy to help if you try it and get stuck.

 A custom object sounds like a good approach, especially if you want donor profiles to become searchable and reportable rather than keeping them as Word files. I’d also use Salesforce relationships to pull existing contact and giving data instead of duplicating it. For external nonprofit or organization research, something like the Nonprofit Check Plus API could potentially help automate verification and enrich profiles before Apsona merges everything into a final document. The key is designing the data model first, so you don’t end up recreating the same information in multiple places.

Congrats on getting Give Lively wired up! I would steer away from deleting these, deletion is fragile, the sync usually just recreates them on the next pull and you lose the registration link. Treat it as a categorization problem instead. A few layers, best first: 

1. Fix it at the source mapping if you can. Check whether Give Lively's Salesforce mapping lets you route free/0-dollar registrations to just a Campaign Member (or a non-donation object) instead of creating an Opportunity. If that toggle exists, it is the cleanest fix, the junk never gets created. 

2. If the integration creates the Opportunity regardless, do not fight it, reclassify it. Put free/ticket registrations on a dedicated Opportunity Record Type (e.g. 'Event Registration' or 'Ticket'), separate from your 'Donation' record type. Then two things fall into place: 

- Exclude that record type from NPSP donor rollups so it never inflates lifetime giving. NPSP lets you exclude specific Opportunity Record Types/Types from rollups (NPSP Settings > Donations for the legacy rollups; with Customizable Rollups you exclude via a filter group). That directly fixes the 0-dollars-counting-as-donations problem in your donor totals. 

- Your donation reports and dashboards then filter to Record Type = Donation (or Amount greater than 0), so the free registrations drop out cleanly. 

3. Track the free attendance where it belongs, as a Campaign Member on the event Campaign (which it sounds like you are already doing). That is the right home for 'attended,' and it keeps your engagement reporting intact without touching giving numbers. 

Net: a dedicated record type + exclude-from-rollups + an Amount>0 (or record-type) report filter gets you clean donation reporting without deleting anything or losing the registration history. If free tickets keep coming through as donations even after that, revisit the Give Lively field mapping, that is where the record type gets stamped on the way in. 

If this helps, please mark it as the Best Answer so it is easy for the next person to find. Thanks :)

Hi Babak - that 'Workflow Rule Filter:' with no name is the classic uninstall blocker, and the reason your Flow/Trigger review came up empty is that it isn't a Flow or a trigger - it's a classic Workflow Rule, which is a separate metadata type you haven't looked at yet. 

What's happening: somewhere you have a Workflow Rule whose criteria (the 'filter') references a Recurring Donation field from the package. The uninstall error points at the filter but can't surface the parent rule's name, which is why it's so hard to trace. 

How to find it fast: 

1. Retrieve the Workflow metadata for all objects and grep for the field. Via CLI: sf project retrieve start -m Workflow (or retrieve the Workflow type in Workbench), then search the .workflow files for the Recurring Donation field's API name (it'll be in the npe03 or npsp namespace). That pinpoints the exact rule immediately - far faster than clicking through Setup. 

2. Prefer the UI? Go to Setup > Workflow Rules (not Flows) and review every rule - and crucially the inactive ones too, since inactive workflow rules still block an uninstall. Check each rule's criteria for a Recurring Donation field, plus any Field Updates that target one. 

3. Don't forget cross-object rules: the blocking rule might live on a different object but reference the Recurring Donation field in its criteria or a field update. 

Once you find it, remove the field from the rule's criteria (or delete/deactivate the rule if it's obsolete), then retry the uninstall. 

Two things that trip people up: (a) it's Workflow Rules specifically, not Process Builder or Flow, so the metadata type to retrieve is Workflow; and (b) inactive rules still count. The CLI-retrieve-and-grep in step 1 is by far the quickest way to end the hunt. 

Hope that cracks it!

Go to Setup > Custom Settings > "Manage" next to "Data Import Settings" > Edit. In the "Contact Matching Rule" field, you can type your desired matching behavior. The valid values, I. believe, are: 

• Firstname,Lastname,Email
• Lastname,Email
• Firstname,Email
• Firstname,Lastname
• Email
• Firstname,Lastname,Phone
• Contact Duplicate Rules

 If you are working with a mail house/print service provider and intend to continue using them, make sure to send your list with the account id so you can match them up after the fact.  Having said that, using a Mail house and moving your address quality initiatives downstream prior to mailing is the absolute worst place to manage data quality.  IMO, data quality is best managed at the record of truth proactively.   This includes building a custom app or using a managed package like NCOA 4 Salesforce which is available now and in the process of getting in the app exchange.  The process handles the entire data set (not just what you are mailing) and works with a few clicks.  You can choose how to import and avoid duplication.  Happy to show it to you or can see a common demo: Typical NCOA 4 Salesforce demo to a nonprofit organization 

Hey Michelle - few notes here:  

Apple Pay isn't Stripe only - Square supports it through there web payments SDK, so you don't have to switch providers if you already have Square - yes you would need to have a Square account to use it for payment processing.  

I'm assuming your goal here is to be able to accept donations from an Experience Cloud site? With that, there are two options - embedding a Square checkout page on your site, or just having a link to an external Square checkout page.  

If trying to embed on your site, Square would work, but I think you are going to have trouble with Apple Pay. My understanding is that Apple requires that verification file to be served at one exact URL path, and Salesforce's multi-tenant platform doesn't let you just put a file there. There are workarounds (a URL rewriter Apex class, or a CDN in front of a custom domain), but it's real developer work and it tends to be fragile.  

So if you are trying to embed on your site (using the Web Payment SDK in an LWC), I would suggest using Square without Apple Pay. If just adding a link to a Square page, Apple Pay would work fine. The user experience for the second option would be a Donor clicks a button, is redirected to a Square page, pays with Apple Pay / Google Pay / Credit Card / etc, then is redirected back.  

Zapier would not be needed in either case. Square sends the webooks natively. You would just set it up on the Square Developer Dashboard and point it at a Salesforce endpoint. You would have to set up a public endpoint to receive the webhooks though - that would mean a RestResource Apex class exposed through your SF Site with get user acccess. You can add some sort of signature verification to ensure you are not accepting posts from any random sources. You could use Zapier if you wanted - to basically outsource this signature verification - but that would have a cost associated with each transaction.  

Hope this was somewhat helpful - I'm happy to talk through this further if you would like. 

Steve