Feed

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. 

I know this is a very old question, but just in case it helps someone. The External Data Source should first be granted to the individual user via permset/profile. That is all it meant by the bolded line. 

User should now see a banner they can follow to authenticate with that data source, or otherwise follow. 

If you get to the point where you are seeing an error like this

• AllSites.FullControl
• EnterpriseResource.Write
• MyFiles.Write
• Sites.Search.All

if you add all those, then resync the external source metadata and try again it should work

I don't have need for this so I've never solved it. An opportunity has one closed date. A payment has one date. GAU offers zero dates.

If I truly had a one off for this, I would break it into three opportunities with three closed dates and market so that we don't think people for them multiply and try to live with it. If it were an extremely routine thing, I would probably create 3GAU for the funding in different years and make the allocation that way. Reporting would obviously have to be driven by the GAU grouping and not necessarily the year given. I don't think NPSP or Salesforce has a clean answer for this type of thing.

Even financial folk don't have a great solution. They typically accrue all of it into one account separate out the future part into a liability and then transfer from the liability to current assets one year at a time. That's another option, I suppose. Inner one opportunity with the full amount and make 1/3 GAU allocation to the fund. Create two activities do a year from now and two years from now to allocate more of the Donation to the GAU. In the end, you have 100% of an allocated to the fund and it reports Properly. In the middle, the donation reports properly as a whole donation, but the GAU only gets credit for the "earned" portion. But it's two manuel tasks for someone.

--Terry

In my experience, CM segments don’t sync cleanly as fields because they’re evaluated views, so the practical pattern is to store preferences as explicit custom fields (or a child object) in Salesforce and then push those into CM as custom fields/tags, letting segments be built from that.  

If you need users to edit from the Contact record, have Salesforce be the source of truth and run a scheduled bi-directional sync on those preference fields. Skyvia can handle field-level two-way sync between Salesforce and Campaign Monitor, while keeping segmentation logic in CM where it belongs.

Greetings, @Ilias Chorafas

I am curious if you figured out a solution, since this matter was raised in February. Can you share your solution? 

If the problem remains, I’d like to better understand your situation  by having you answer a few clarifying questions: 

1. Are you trying to update existing gift commitments directly on the Gift Commitment object, or are you updating them via the related Gift record? 

2. When you mention “creating a new GCS and modifying the existing GT,” are you referring to using the Gift Commitment Schedule (GCS) related list or a custom automation/process? 

3. Approximately how many records are you trying to update at once, and are you looking for a point-and-click solution (like Data Import Wizard/Data Loader) or are you open to Apex/data manipulation tools? 

Thank you in advance-  

Katende

Try this 

1. From Setup, in the Quick Find box, enter Data Protection and Privacy, and then select Data Protection and Privacy.
2. Click Edit, select or unselect Make data protection details available in records, and then click Save.

 It's ticked in my NPC org, and Contact Point objects are visible in the Object Manager

@Louis Dawkins

My personal experience ... Gravity Forms is a pain in the butt, and it's hard to get good results from it. If you could switch to Form Titan or FormAssembly or something like that, you'd have a much better time in general.   

If I had one of those tools, I would allow a group signup. Then the group registration could have a primary contact, and all of the other volunteers could be parented under that contact. Then create a separate custom object for registrations.  

Side note -- My preferred method for handling forms in general (even with expensive form tools) is to integration to a custom object in Salesforce, and then use Salesforce Flow to manage everything else.  

So for your situation, the solution could look like: 

• Custom Object: Form Submission
  • RecordType: Gravity Forms - Volunteer Registration 
  • In addition to the form fields, also create a 'conversion status' field. And then run asynchronous or nightly automation to create Contacts where necessary. This would give you full control over the conditions. The 'conversion status' would change to complete if a contact was created successfully. You could even create a queue of records where conversion status is set to 'manual review' by the Flow due to conflicts.