Skip to main content

#Nonprofit Success Pack24 debatiendo

 NPSP Day Philadelphia - November 5 

 

Philadelphia! NPSP Day is coming to town on Thursday, November 5. If you're not familiar, NPSP Day brings nonprofit Salesforce users together to work through real challenges and swap practical ideas. It's for everyone, from longtime Saleforce experts to brand new accidental admins! 

 

At NPSP Day, you'll: 

  • Get hands-on with the Nonprofit Success Pack (NPSP)
  • Learn what's changing for nonprofits on Salesforce, including AI and NPC/AFNP
  • Help build the day's agenda around what matters most to the group
  • Ask questions and learn from peers doing the same work

We can't wait to reunite with the Philly community. Register today! 

NPSP Day Philadelphia - November 5 Philadelphia! NPSP Day is coming to town on Thursday, November 5.

#NPSP  #Nonprofit Success Pack

0/9000

We currently create our donor research profiles in Word and attach them as Files to Account records. The profile contains Contact info (name, email, phone, mailing address), some giving history, and data from external sources. We would like to transition this to Salesforce. My preliminary idea is a custom object with fields for data that doesn't already live somewhere else, then some sort of mail merge tool (we have Apsona) that merges it all together in one document. Has anyone built anything like this,or used a third party tool they recommend?  

 

We are on NPSP with no immediate plans to move to NPC.

@Nonprofit Success Pack #Nonprofit Success Pack

13 respuestas
  1. 25 sept, 6:01

    A custom object sounds like a solid approach, especially if you want the research data to stay structured and reportable in NPSP. You could relate it to the Account/Contact and use Apsona to generate the final profile document, while keeping the source data searchable and easier to maintain in Salesforce.

0/9000
When updating the default address on a Household account, the Mailing Address for the related Contacts is update as well. This works for most accounts...but I have identified a few that aren't working and I can't figure out why or how they are different from the accounts which work as expected.
10 respuestas
  1. 23 sept, 11:13

    Check the Household Account model settings. Some contacts may be marked as excluded. Run the address update batch manually. Also, look for validation rules blocking the change. The outcome is usually a simple checkbox. Fix that first.

0/9000

Does anyone have a solution for integration? Or would we need a third party like Zapier to handle transactions? I assume we'll need to have a Square account first too? Apple Pay seems to be only available if we have Stripe as a payment processor. 

 

#Salesforce Admin  #NPSP  #Nonprofit Success Pack  #Nonprofits

2 respuestas
0/9000

What is the expected mapping behavior of custom Recurring Donation fields to Opportunities when installment auto-creation is disabled

? 

 

For example, I want to map a custom 'Acknowledgment Status' field on the Recurring Donation to the 'Acknowledgment Status' field on Opportunities. If NPSP were set to auto-create the next installment, the Recurring Donation's Acknowledgment Status would get mapped to the new Opportunity. However, we have installment auto-creation disabled. So if the next won installment for a Recurring Donation comes in, say, through an online donation platform, would its Acknowledgment Status be inherited from the Recurring Donation:

  • When it's created?
  • In a batch overnight?
  • At all?
  • And would the Recurring Donation's Acknowledgment Status get copied to all child Opportunities, or just new ones after the field is updated?

Thank you for any insight you can provide! 

 

#NPSP  #Enhanced Recurring Donations  #Nonprofit Success Pack  #NonprofitHelp  #Nonprofit  #Recurring Donation

1 respuesta
  1. 17 sept, 11:58

    Hi Adam,

    The custom field mapping is applied when NPSP creates an installment Opportunity from the Recurring Donation. 

     

    So if Installment Opportunity Auto-Creation is disabled, NPSP won't automatically create the next installment just to apply the mapping. If an Opportunity is later created by an external donation platform, the Recurring Donation → Opportunity custom field mapping would not automatically populate that Opportunity unless the integration/process creating it explicitly applies the value. 

     

    Also, updating the Recurring Donation doesn't simply copy the value to every historical/closed Opportunity. NPSP's behavior around existing open installment Opportunities can update mapped values depending on the Recurring Donation processing/configuration. 

     

    For an online donation platform creating the Opportunity directly, I'd recommend checking the integration's field mapping or automation rather than relying on the NPSP Recurring Donation mapping. 

0/9000
Kai Williams ha preguntado en #NPSP

We have finally (YAY!) integrated Give Lively with Salesforce. And we've started using Give Lively events for some programatic events that are free but with an option to purchase a $10 ticket to support the work. We love having everything flow directly into Salesforce. However the many $0 opportunities that are being categorized as "donations" are confusing our reporting. My tentative solution is to delete these $0 opportunities as we typically don't consider attending this event as something that gets an opportunity - only a campaign member added.  Has anyone had a similar situation?  I'm thinking a flow that identifies and deletes $0 opportunities created by Give Lively 

 

#NPSP  #Nonprofit Success Pack  #Give Lively  #Events

2 respuestas
  1. 18 ago, 19:19

    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 :)

0/9000

Hi All! I need your help understanding how we can integrate Google Form ( the website form is a Google form) with Salesforce (NPSP) if the customer is not interested in paying for an integration tool like Zapier. 

regards,  Preeti

#Nonprofit

Success Pack

#Nonprofit Success Pack
7 respuestas
  1. 15 sept, 11:42

    Zapier is lovely, but it is not the only fish in the sea. You can use Google Apps Script to push data directly into Salesforce through the API. It takes a little coding, but there is no additional platform cost. Another option is a simple Web to Lead form if you only need basic data capture. What I think will be best is testing the script in a sandbox first. The setup can be a little fiddly, but getting it working is quite rewarding.

0/9000

Hi all,

Wondering if anyone uses Formstack to/from Salesforce. We have a weird issue arising. We have a Youth consent form for parents to sign for youth taking classes. They need to sign this at least twice a year if they are taking additional classes in a different month. We have it set up to pull the data from the record into the form if they have completed it before - totally fine.

We did not have it set up previously to update the submitted date on the contact record. Now I have that box checked on JUST that field. The checkbox is "Update existing Salesforce record matching this field value:"

I haven't hit this button on any other field so that we don't have blanks erasing previously provided information.

We now have an issue popping up where the birthdate is then changed to blank when the new form is submitted. It is not a required field and I do not have the box checked to update the field upon resubmission. The weird thing is that when I see a record where the birthdate was removed, I go to the form submission and the birthdate is there pre-filled in the form.

Any thoughts? I'm hoping the checkbox update for just the date field isn't causing the issue here. I'm going to reach out to formstack support to, but wanted to check in and see if anyone has run into this issue before.

4 respuestas
  1. 13 sept, 13:17

    We kept the form side separate and used Skyvia for the Salesforce update, with only the fields we actually wanted mapped for update. That gave us a lot more control than letting the form integration write back to the whole record.

0/9000

Hi, I understand the sales cloud has this integration for google analytics: https://support.google.com/analytics/answer/7584446?hl=en

and the upcoming Elevate add on will be able to integrate google analytics with NPSP but I do not know if non-profits have free/DIY alternatives to integrate Google and NPSP today. Has anyone achieved this? Would like to know how to send the gift information and user profile so Google Ads segmentation can benefit from the CRM info. It would also be good to know the pricing of Elevate, although I don't the group will be able to afford another expense right now (maybe later).

Thank you!

2 respuestas
  1. 7 sept, 13:08

    We used Skyvia (https://skyvia.com/connectors/salesforce) for the Salesforce side of a similar setup, mainly to get the CRM data out and into a place where we could work with it further. It won’t handle the whole Google Ads audience piece for you, but it can take care of moving the NPSP data you need without building the export yourself.

0/9000

Attempting to uninstall NPSP Recurring Donation in a Sandbox, was able to resolve all Component Type dependencies that were blocking the uninstall, except  last one which reads: 

Component TypeName Problem

 

Custom Field | Recurring_Donation | Can't uninstall package because an external component is referencing a component in this package. Remove the reference, and then retry uninstalling this package. Workflow Rule Filter: 

 

There is no name associated with the Workflow Rule Filter: 

which makes it difficult to track down. I have downloaded all meta.xml files and reviewed all Flows and Triggers etc but can not find any reference to NPSP components. 

 

#NPSP

 

 

#Nonprofit Success Pack  #Uninstall NPSP

1 respuesta
  1. 17 ago, 17:15

    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!

0/9000