#Nonprofit Cloud12 discutindo

@Mckenzie Freeman there isn't one native merge that walks the whole household graph in bulk.

Nonprofit Cloud keeps the household as a Party Relationship Group on an Account, the people as Person Accounts, and email, phone, and address on Contact Point records. A normal Account merge gets blocked when both households already have a Party Relationship Group, because that group is unique per account. The supported path is the Party Relationship Group merge, and that is still one pair at a time. There's an IdeaExchange request for bulk merge of household accounts that have those group records, which is the wall you're hitting.

Person Account merge is a second step, and it does not merge or reparent Contact Point records. The losing person's email, phone, and address can be left behind, so someone still has to decide which contact points survive. A dedupe app can find the duplicates. I wouldn't assume Plauti collapses the group, the person, and the contact points in one transaction just because it can merge accounts.

For a mass cleanup I'd split it. Match and merge the people first, then merge the Party Relationship Group onto the winning household, and review the contact points that didn't follow. The people doing the group merge need Merge and Split Groups on a cloned Group Membership permission set. If you're in the thousands, the group merge API takes a primaryAccountId and a secondaryAccountId, still one pair per call.

Good scenario to pin down before you build, because the behavior you want is actually the opposite of Salesforce's default consent precedence, so it is worth being deliberate here. 

How native precedence works: when you evaluate consent through Salesforce's Consent API (the Apex Consent.getConsent aggregation), the MOST SPECIFIC record wins, in this order: 

ContactPointConsent (a specific email) beats ContactPointTypeConsent (all email for the individual) beats PartyConsent (the whole donor, i.e. your 'Global Consent'). 

What that means for your scenario: because ContactPointConsent is more specific than PartyConsent, an explicit opt-in on Email A takes precedence over a party-level (Global) opt-out. So Global Consent does NOT natively act as a hard stop that overrides the granular per-email consents, the granular record wins. Your intended model ('manage per contact point, Global = full suppression override') is therefore not what the standard precedence gives you out of the box. 

To actually get 'Global = hard stop,' enforce it as an explicit gate in your own eligibility logic rather than relying on native precedence: 

1. First check PartyConsent (Global). If it is Opted Out for that purpose, suppress everything, full stop, and do not evaluate anything else. 

2. Only if Party is not a hard opt-out, fall through to ContactPointConsent per email for the granular decision. 

Put that logic wherever you determine send eligibility (a Flow/Apex helper, or your segment filter if you send from Data Cloud / Marketing Cloud) and centralize it so every channel uses the same gate. 

Two things to keep straight: 

- Consent is always per DataUsePurpose (Marketing vs Transactional), so compare Global vs contact-point consent within the same purpose, do not let a Marketing opt-out suppress a transactional receipt. 

- Since you are deliberately inverting the default precedence, document it and keep the 'Party opt-out overrides all' rule in ONE place, so a future admin does not wire a send straight off ContactPointConsent and accidentally email someone who globally opted out. 

Net: granular-per-contact-point + global-hard-stop is a reasonable and common design, but you have to implement the 'global wins' override yourself, because the native Consent API precedence is specific-wins and will not enforce the hard stop for you. 

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

We recently launched NCOA 4 Salesforce that automates the move update process using the NCOA database.  We're currently going through the process to put it into the App Exchange.  That said our API is used extensively with output from Epic, Cerner and Pharma fulfillment so it meets the highest security levels (including Azure Government).  We completely automate the entire process, you can build flows to do an upcert or insert a new address.  For non-profits we allow unlimited usage for the first year.  This service is cloud agnostic so it can accommodate any use case including person accounts. 

Here's the wiki if you want technical details: 

Security details: 

The pricing is $5000 and includes the Nexus Connector and TEC Mailing's Verify and Confirm API.  It usually takes less than 30 minutes to set up and is currently unlimited Use.   

Happy to schedule a call.  

What people are saying: 

"NCOA 4 Salesforce has been a great tool for us at Mercy For Animals. We needed to reduce undeliverable mail, lower costs of processing for our physical mail, and have this operate within Salesforce. While many vendors can verify addresses, NCOA 4 Salesforce is unique because it verifies and provides updated addresses natively within Salesforce. After a simple configuration, the product now processes over 100,000 addresses each month with a single click. This means our records are always updated with CASS-verified and NCOA-processed data. They’re ready for use with each mailing. Keeping our data current does more than save money, it also improves the accuracy of our segmentations for events, local organizing, and targeted campaigns. NCOA 4 Salesforce is an invaluable tool for maintaining data quality and physical mail ROI." 

 Aaron Anderson, Salesforce Administrator at Mercy For Animals 

The error suggests that "Account" in your formula is wrong. The documentation suggests that the lookup to the Account record on Gift Transaction is "Donor": https://developer.salesforce.com/docs/atlas.en-us.nonprofit_cloud.meta/nonprofit_cloud/npc_fundraising_api_objects_gifttransaction.htm

Try Donor.Send_Mailed_Acknowledgement_Letter__pc and see if that resolves the issue for you.