Mission Field Guide
Your CRM is a filing cabinet. Mission is your analyst. This guide shows the work behind every answer: the data your charity already collects, and the 150+ insights Mission builds from it on every supporter, surfaced and delivered to you automatically.
Mission joins gifts, memberships, events, volunteering, grants and campaigns into one record per person, then builds insight and audiences across all of it: look-alikes of your best supporters, lapsed givers who still volunteer, funders due a report. You can start from three columns, supporter ID, gift amount and gift date, but that is the floor, not the ceiling.
We don't know your organization the way you do, and this might not be a fit. We'd rather show you than tell you.
Pick a kind of record, like gifts or volunteer shifts. Orbit works out a number or a date for every supporter, right when you look. No formula to write. No new field to set up first.
Pick one to see the insight, audience or pathway that answers it. The chips show which parts of your data each answer draws on.
CiviCRM OFFSource fields from CiviCRM core tables: civicrm_contact, civicrm_contribution, civicrm_event, civicrm_participant, civicrm_grant, civicrm_campaign, civicrm_address, civicrm_email.
Blackbaud RE NXT OFFSKY API entity references: Constituent, Gift, Gift Split, Event, Participant, Campaign, Opportunity, Address, Email Address. Grant fields map to the Opportunity entity.
Salesforce NPSP OFFStandard and npsp-namespaced fields: Contact, Account, Opportunity, npe01__OppPayment__c, Campaign, CampaignMember, npsp__Address__c. Grants use Opportunity with Grant RecordType.
DonorPerfect OFFSource fields from the DonorPerfect queryable tables: DP, DPGIFT, DPADDRESS, DPCODES, DPLINK, DPUDF, DPPAYMENTMETHOD. No event, volunteer or grant tables exist in the standard schema.
HubSpot OFFSource fields from HubSpot standard objects: Contact, Company, Deal, Campaign, Marketing Event and Marketing Event Attendance State. Donations map to Deals in a giving pipeline. No grant object exists.
Givebutter OFFSource fields from Givebutter API v1: Contacts, Households, Transactions, Campaigns, Funds, Tags. No event record with dates or attendance, no volunteer object, no grant object.
Little Green Light OFFSource fields from LGL API v1: constituents, gifts, campaigns, appeals, funds, events, volunteer_times, memberships, groups, relationships. No grant object; events carry no fee, capacity or attendance status.
Nonprofit Cloud OFFSalesforce Nonprofit Cloud / Agentforce Nonprofit, the successor to NPSP. GiftTransaction, Person Account, Campaign, CampaignMember and Volunteer Management. Volunteer objects need Unlimited edition. Grantmaking models grants awarded, not grants received.
Bloomerang OFFBloomerang CRM REST API v2: Constituents, Households, Transactions and Designations, Interactions, Funds, Campaigns, Appeals. Events sit in Bloomerang Fundraising and volunteers in Bloomerang Volunteer, both separate products with separate APIs.
No published field-level schema, so this system cannot be mapped from documentation. Select to read the deployment note.
No published field-level schema, so this system cannot be mapped from documentation. Select to read the deployment note.
Everything the guide above shows, written out on one page: 20+ pathways, 25+ audiences, 150+ insights and the CRMs it covers.
Mission joins gifts, memberships, events, volunteering, grants and campaigns into one record per person, then builds insight and audiences across all of it: look-alikes of your best supporters, lapsed givers who still volunteer, funders due a report.
You can start from three columns, supporter ID, gift amount and gift date, but that is the floor, not the ceiling. Mission makes the donation id itself. The Instant Insights module built once on those three columns is free for life; a full Mission deployment is not.
Your CRM stores what happened. It shows you the past; it does not work out what the past means. A reporting tool like Power BI is a blank canvas: someone has to build every chart, and a chart is not a prediction. A data consultant project produces a report, not a system, and a few months later the report is stale. An AI prediction add-on predicts from whatever mess the data is in. Mission is a CRM companion: it sits underneath the tools you have, joins their data into one record per supporter, builds the insights once and keeps them current, and hands your team the list to act on. Nothing you use gets replaced.
Behaviours are built into Orbit. Pick a kind of record, like gifts or volunteer shifts, and Orbit works out a number or a date for every supporter, right when you look: when it happened (Recency), how many (Frequency) or how much (Value). There is no formula to write and no new field to set up first. Save a Behaviour in an audience, and every tile that counts the audience gives the same answer. The guide lists 10+ Behaviours and the 20+ audiences built from them. The gift Behaviours need only the three columns above.
Research: what we found in 42 charities' public board reports.
Every pathway on its own page: the pathways. Every audience on its own page: the audiences. Everything built for Mission, searchable, with a request button: Mission Resources. Learn Mission hands on: the course. The questions charities ask us first, answered: questions.
What it covers: Deep gift and event coverage. Grants are tracked through Opportunity records.
Gaps: No role-at-event concept, so volunteer insights do not compute.
What it covers: Broad gift, household and campaign coverage across a very large installed base.
Gaps: No volunteer object. No event fee or duration.
Note: Legacy. Salesforce ended feature development in March 2023 and stopped issuing NPSP to new nonprofits in December 2025. Existing orgs are supported with no end-of-life date, but new Salesforce orgs are on Nonprofit Cloud.
What it covers: Salesforce's current nonprofit platform and the successor to NPSP. Real volunteer objects, which NPSP never had.
Gaps: Volunteer Management needs Unlimited edition. Campaign start and end are dates rather than datetimes, so event duration cannot be computed.
Note: Grantmaking models grants awarded by a funder, not grants received, so Mission's grants module has no equivalent. Ask which Salesforce edition before promising volunteer analytics.
What it covers: The only system in this guide where donations, events, participants, volunteering and grants are all first-class tables. Every Mission insight computes.
Gaps: None for the Mission schema.
What it covers: Complete donor and gift history, which carries the entire Instant Insights layer.
Gaps: No event, participant, volunteer or grant table in the queryable schema. Campaign is a code on the gift rather than a record. Birth date is a user-defined field.
Note: Canadian DonorPerfect systems use the acknowledge preference on each gift for official receipting (receipt, acknowledge only, or neither), and Quebec Law 25 fields exist as user-defined fields on some systems. Mission has no field for either yet; ask which a Canadian prospect uses. Refunds are three linked gift records, not a credit note.
What it covers: Clean donation and household coverage, with Birthdate and Gender on the constituent record.
Gaps: No events and no volunteers in the CRM schema. No grant object.
Note: Bloomerang is three products. Events sit in Bloomerang Fundraising and volunteers in Bloomerang Volunteer, each with its own API, so that activity never reaches the CRM data model. Campaign detail beyond Id and Name is not published.
What it covers: The strongest non-CiviCRM fit. volunteer_times is a real object, and campaigns carry financial_goal with start and end dates.
Gaps: No grant object. Events carry no fee, capacity or attendance status.
Note: volunteer_times and events property keys are not published in full; confirm against a live account before build. Events carry no confirmed end datetime, so the three duration insights are off; if volunteer_times exposes hours directly, a schema variant could restore them.
What it covers: Donations map to Deals in a giving pipeline. Marketing Event attendance gives real event insights, and event datetimes allow duration to be computed.
Gaps: No grant object. No volunteer role. No event fee or capacity. hs_goal is deprecated, so campaign goal revenue is unavailable.
Note: Marketing Events are a Marketing Hub feature. Confirm the objects are provisioned before relying on event insights.
What it covers: Real Households object, a repeating emails array, and Contact.dob so donor age computes.
Gaps: No event record carrying dates or attendance status. No volunteer object. No grant object.
Note: Ticketing exists but is not an attendance model, so event insights are switched off rather than approximated.
Gaps: Fields, dropdowns and tabs are renameable by the client, so no two accounts share a schema.
The numbers your board asks for, gathered from every system and ready before every meeting.
Problem solved: Board-ready numbers before every meeting. Team: Finance and board.
Why it's hard today: Board numbers are often rebuilt by hand before each meeting, from the CRM, the finance system, a grants spreadsheet and a coordinator’s own counts. Some CRMs only report one month at a time, so a year-on-year comparison becomes a manual job.
Thank volunteers at the moments that matter, and notice when someone starts to drift before they are gone.
Problem solved: Drifting volunteers noticed in time. Team: Volunteers.
Why it's hard today: Volunteer hours often sit in a volunteer platform, a coordinator’s spreadsheet or a paper sign-in sheet. The CRM sees gifts, not shifts, so nobody is told when a regular volunteer stops coming.
Notice the members who have stopped coming, long before their renewal is due, and reach them while it still matters.
Problem solved: Quiet members noticed before renewal. Team: Membership.
Why it's hard today: The membership platform handles signup, renewal and payment, and often tells the member their membership has lapsed without telling staff. Visits sit in admissions or on sign-in sheets, so a regular who stops coming isn’t noticed until renewal.
Never miss a report deadline, and keep returning funders close between applications.
Problem solved: No more missed funder reports. Team: Grants.
Why it's hard today: Grant deadlines often live in a spreadsheet or a shared calendar that one person watches. When that person is away, a report deadline can slip past.
Every message respects each person’s wishes and reaches a real inbox, across every channel and every team.
Problem solved: No message to anyone who opted out. Team: Communications.
Why it's hard today: Contact preferences end up in several places: the CRM, the email platform, sometimes a membership or events system, and the contact counts often don’t match. An opt-out recorded in one doesn’t reach the others on its own.
Orbit finds the people already on your file who most resemble your best supporters, then Meta finds more of them beyond it.
Problem solved: More people like your best supporters. Team: Acquisition.
Why it's hard today: What makes your best supporters your best is spread out: gifts in the CRM, events in ticketing, shifts in the volunteer system. A model built on the CRM alone only learns from the gifts.
Every supporter sees an ask built from their own giving history, in every channel at once.
Problem solved: The right ask for every person. Team: Fundraising.
Why it's hard today: A personal ask needs the whole giving history. When gifts come in through several giving platforms, or older gifts sit in the finance system from before the current CRM, the ask is set from part of the record.
Google, Meta and LinkedIn always hold the right people: the ones you want to reach, and the ones you should stop paying for.
Problem solved: Ad spend aimed at the right people. Team: Digital.
Why it's hard today: Ad audiences need giving and event history in one place to know who to show and who to leave out. When that history is split across systems, the upload only reflects what one system can see.
What each campaign and channel really costs per new supporter, next to what those supporters give in their first year.
Problem solved: The real cost of a new supporter. Team: Leadership.
Why it's hard today: Gifts often don’t record where they came from. Even charities with analytics and ad accounts find that tagging hundreds of donation forms by hand gets abandoned, so cost per supporter becomes a guess.
Which channels win the first gift, and which keep supporters giving, side by side, every month.
Problem solved: Budget follows the channels that keep supporters. Team: Leadership.
Why it's hard today: Email results stay in the email platform, ad results in the ad platforms and gifts in the CRM. Without a source on each gift, nobody can say which channel brings supporters who stay.
Nine signals become one ranked list, and every person arrives with their whole story and the recommended next step.
Problem solved: This week’s calls, ranked and ready. Team: Fundraising.
Why it's hard today: The signals that say “call this person this week” are split up: gifts in the CRM, attendance in ticketing, hours in a spreadsheet. With no single list, the call list often comes from someone’s memory.
Each supporter’s own giving rhythm says when they are slipping. Act inside the window, not at year end.
Problem solved: Lapses caught early. Team: Fundraising.
Why it's hard today: Some CRMs only report one month at a time, so a supporter’s rhythm over the years never shows. The usual stand-in is one rule for everyone, such as no gift in 12 months.
The weeks after a first gift decide whether there is a second one.
Problem solved: Second gifts asked for on time. Team: Fundraising.
Why it's hard today: First gifts made on giving platforms without a live connection arrive in batches, so the thank-you waits until someone imports them and notices. Where the first gift came from often isn’t recorded at all.
Everyone who gave last year and hasn’t yet this year, ranked by value, timed to their own calendar, and seen in full.
Problem solved: A year-end list that builds itself. Team: Fundraising.
Why it's hard today: LYBUNT reports only count gifts the CRM holds. A gift made on another platform, or a supporter who came to events this year, doesn’t show, so the list can chase people who already gave or never left.
Find the supporters already behaving like major donors, using gifts, events and volunteering together, then cultivate before anyone asks.
Problem solved: Major donors spotted early. Team: Major gifts.
Why it's hard today: Major gift signals hide in different places: large gifts in the CRM, event visits in ticketing, and a company that gives a grant through one platform and matched employee gifts through another. Split up, it reads as several small relationships.
Ask for what they have already shown they can give.
Problem solved: Asks matched to what people can give. Team: Fundraising.
Why it's hard today: To ask for more you need someone’s largest gift. When history is split between an old CRM, the finance system and today’s CRM, the peak can sit in a system nobody checks anymore.
Some supporters already give like monthly donors, and some of them used to volunteer. Ask them to make it official.
Problem solved: Monthly donors found in your file. Team: Fundraising.
Why it's hard today: A supporter who gives most months, sometimes by cheque and sometimes through an online platform, looks like an occasional giver in each system on its own.
They already give their time. Thank them for it before you ask for anything else.
Problem solved: Volunteers asked to give, the right way. Team: Volunteers.
Why it's hard today: Volunteers are often tracked in their own platform or spreadsheet, apart from donors, so “which volunteers have never given?” is a question no single system can answer.
Turn the night of the event into the start of a relationship.
Problem solved: Event guests followed up while it matters. Team: Events.
Why it's hard today: Attendance often lives in a ticketing tool, a box office or a paper sign-in sheet that gets tallied into totals. The names stay on the sheet, so the CRM never learns which guests came.
Ask people in the month they usually give, and leave them alone in months they never do.
Problem solved: Asks timed to each person’s month. Team: Fundraising.
Why it's hard today: Finding each person’s best month means looking across every gift they’ve made, through every platform they’ve used. Gifts split across systems, and reports that run one month at a time, hide the pattern.
Before you ask a lapsed supporter for money, check whether they really left, then ask what changed.
Problem solved: Lapsed supporters asked what changed. Team: Fundraising.
Why it's hard today: A giver the CRM calls lapsed may still be volunteering or coming to events, logged somewhere else. Without that, the win-back appeal chases someone who never left.
Your most loyal supporters hear about their impact all year, across every way they are involved, not only when you need something.
Problem solved: Loyal supporters thanked all year. Team: Fundraising.
Why it's hard today: Stewardship often runs from a separate spreadsheet: who got a card, who got a call, who wants to be recognized and how. Kept apart from the gift history, nobody sees the whole year a supporter actually had.