Hello! Thank you to all who joined our July ANZ Ask-Me-Anything yesterday on July 22nd. Special shoutout to our July panelists ~ @Gourav Sood @Nicole Aebi-Moyo @Daniel Klarnet!
Here's the recap -
Q: Working on an implementation for a US/India-based nonprofit — what's the best way to implement across both regions? Keep them separate?
A: Great org strategy question — and that's exactly how you should frame it: as an org strategy decision. A few key factors to work through:
- Data residency & data protection: Where does your data need to live, and what are the legal/compliance requirements in each country?
- Data visibility: Do you want the US and India teams to see each other's data? How much cross-exchange is needed?
- Shared business process: How much of your business process is the same across both geographies? If processes are highly shared but locations differ, two orgs may be the right call — but if you go that route, invest in a strong code maintenance practice so a single codebase deploys to both orgs consistently.
- Licensing: This will always be the second major impact factor after data residency.
This is a big, careful decision — take your time and assess thoroughly before committing to a direction.
Helpful resource:
Salesforce Enterprise Architecture: Multi-Org Strategy
Q: We're implementing NPC and plan to aggregate recurring gift (RG) transactions older than 24 months into yearly summaries. What's your suggestion around OOB gift commitment summaries — should we upload there and have donor gift summaries pull from that data?
A: Data migration at high volume is hard — here's how to approach it cleanly:
- Turn off validation rules before loading to avoid unnecessary failures during migration
- Clean and transform your data outside of Salesforce first — get it fully prepped before touching the org
- Use Bulk API for high data volume loads
- Load in sequence: parent records first, then child, then child of child — then run DPE after
- For the gift commitment itself: the last 24 months come in as individual gift records, but for historical data beyond that, you'll want to populate the gift commitment summary directly first, then populate the related records after
The concern to validate is around the total donation amount on the gift commitment — make sure your approach accounts for how that figure gets populated given what you're bringing in vs. aggregating.
Q: Follow-on — why did you decide not to bring in the full 25 years of data?
A: Storage costs, primarily. The decision was made to bring in cash donations without pulling in all 12+ transactions per donor going back decades. The goal is cost reduction — and having a data warehouse means that full historical detail isn't lost, it's just living outside Salesforce where it's more cost-effective to store at that volume.
Q: Is there an Australian charity successfully using NPC end-to-end — fully deployed — where you could make a donation and experience what it actually feels like? (Jess Mac, Jessica@blazeyourtrail.org)
A: Worth reframing the expectation here a little: NPC's biggest impact isn't necessarily on the donor-facing experience — it's on the internal experience. The front-end donation flow a donor sees is often driven by a third-party tool or Experience Cloud, not NPC directly.
Q: Follow-up: Why would you expect the experience to be different?
A: If what you're looking for is a comparison — a list of Australian charities using Salesforce vs. other CRMs to see the difference in experience — that's a great research angle. The distinction is less about what the donor sees on the surface and more about how the organization manages relationships, reporting, and programs behind the scenes. Happy to help dig into examples if that's useful!
Q: We just started using AFNP — any tips for getting into Outcomes Management without setting ourselves up for problems from the start?
A: Before touching the data model, make sure your non-technical frameworks are solid first. Do you have your outcomes, indicators, and program logic clearly defined outside of Salesforce? Getting that right on paper (or in a doc) first will make the configuration much cleaner.
Once you're ready to build:
Also — don't sleep on AI tools like Claude for working through data model questions, mapping logic, or even drafting your framework structure. It can be a surprisingly effective thought partner for this kind of work.
Q: Who starts with AI when you have something to tackle? (Question for the group)
A: Highly recommend starting here if you haven't already:
AI Fluency: Framework & Foundations
Q: What's your one tip for a great new user onboarding experience?
A: Get people involved from the very beginning — don't wait until go-live to introduce users to the system. Showcases, workshops, and sandbox access during the build phase go a long way. Identify your supporters and your skeptics early, and bring both into the process intentionally.
A few other things that make a real difference:
- Write all training materials from the business user's perspective first — not from the system's perspective
- At go-live, run open office hours where someone from the team is available to answer drop-in questions in real time
- Budget for fast follows — those small fixes and quick wins that users identify right after go-live matter a lot for adoption
- Point new users to Trailhead, how-to videos, and any internal resources you've built — the more self-serve options they have, the better
