Giving data model detection is not yet available to customer orgs — it does not appear as a toggle on the Beta Features page (/beta) today. The description below documents the intended behavior for Salesforce admins who understand NPSP, Nonprofit Cloud, Education Cloud, or Health Cloud; check with your Blackthorn representative for current availability. The underlying bridge fields are not yet shipped in the managed packages — they degrade gracefully when absent.
Forge can project giving (donation) data into several third-party or Salesforce-native data models used by nonprofits and educational institutions. Rather than forcing all donations through the bt_fundraising__ schema, Forge uses an adapter pattern: it detects which model is installed in your org and maps the bt_fundraising__Donation__c record to the appropriate objects and fields in that model.
How detection works
On connection (and periodically thereafter), Forge queries your org's installed sObjects to detect which packages are present. The detection result is cached per-tenant and re-evaluated when an admin reconnects the org or manually triggers a re-detect from the Admin page.
| Model | Detection signal | Adapter |
|---|---|---|
| NPSP (Nonprofit Success Pack) | npe01__OppPayment__c installed | NpspAdapter — maps giving to Opportunity + npsp__ fields |
| Nonprofit Cloud (NPC) | GiftTransaction sObject available | NonprofitCloudAdapter — maps to GiftTransaction, GiftCommitment, GiftDesignation |
| Education Cloud / EDA | hed__Program_Enrollment__c installed | EducationAdapter — maps enrollment context to hed__ objects |
| Kindsight Ascend | No fixed detection signal — Ascend has no published schema | KindsightAscendAdapter — every object and field API name is tenant-configured via Admin → Data Model → Object Mapping; the adapter throws a needs-configuration error until an admin sets the mapping |
| Health Cloud | CareProgramEnrollee installed | HealthCloudAdapter — enrollments map to CareProgramEnrollee; giving/recurring delegate to the same NPC GiftTransaction/GiftCommitment objects when present; there is no designation layer |
| None (default) | No third-party giving model detected | Native bt_fundraising__Donation__c only |
NPSP model
When NPSP is detected, Forge maps a donation to an Opportunity record and uses npsp__ fields for primary attribution and allocation. Recurring gifts map to npe03__Recurring_Donation__c. Payment instalments map to npe01__OppPayment__c.
| Forge concept | NPSP object | Key fields |
|---|---|---|
| Donation (one-time) | Opportunity (standard) | Amount, StageName, CloseDate, npsp__Primary_Contact__c |
| Recurring gift | npe03__Recurring_Donation__c | npe03__Amount__c, npe03__Installment_Period__c, npe03__Next_Payment_Date__c, npe03__Contact__c |
| Payment instalment | npe01__OppPayment__c | npe01__Payment_Amount__c, npe01__Paid__c, npe01__Payment_Date__c |
| Fund / designation | npsp__General_Accounting_Unit__c | Name |
| Allocation to fund | npsp__Allocation__c | npsp__Amount__c, npsp__General_Accounting_Unit__c, npsp__Opportunity__c |
Nonprofit Cloud (NPC) model
Nonprofit Cloud (API v57+) uses standard objects without a managed namespace. Forge's NonprofitCloudAdapter maps to these objects when the GiftTransaction sObject is present.
| Forge concept | NPC object | Key fields |
|---|---|---|
| Single gift | GiftTransaction | OriginalAmount, Status, TransactionDate, DonorId (Account-only lookup — no Contact-typed donor field on this object) |
| Pledge / recurring commitment | GiftCommitment | NextTransactionAmount, Status, NextTransactionDate, EffectiveStartDate, DonorId (no cadence field on this object — see GiftCommitmentSchedule) |
| Instalment schedule | GiftCommitmentSchedule | GiftCommitmentId, TransactionAmount, TransactionPeriod (the real cadence field), StartDate |
| Fund designation | GiftDesignation | Amount, GiftTransactionId |
| Allocation | GiftTransactionDesignation | Amount, GiftTransactionId, GiftDesignationId |
| Attribution source | OutreachSourceCode | Name |
Education Cloud / EDA model
When EDA (hed__ namespace) is detected, Forge can surface enrollment context alongside event attendance. When Education Cloud (EDC, namespaceless standard objects available in API v59+) is detected, Forge uses Program and ProgramEnrollment objects instead.
| Path | Object | Key fields |
|---|---|---|
| EDA | hed__Program_Enrollment__c | hed__Contact__c, hed__Program__c, hed__Status__c, hed__Enrollment_Status__c (no start-date field — CreatedDate is used instead) |
| EDA | hed__Course_Enrollment__c | hed__Contact__c, hed__Course_Offering__c, hed__Status__c |
| EDC (API v59+) | ProgramEnrollment | ContactId, ProgramId, Status, EnrollmentDate (there is no EndDate field on this object) |
Degraded mode and partial fields
Two bridge lookup fields on bt_fundraising__Donation__c connect a standalone donation to the giving record Forge creates in the third-party model: bt_fundraising__Giving_Model_Opportunity__c (for the sales_cloud/NPSP path) and bt_fundraising__Giving_Model_Gift_Transaction__c (for the Nonprofit Cloud/Education Cloud/Health Cloud path). Kindsight Ascend is out of scope for this bridge — it has no matching field. If the projection cannot complete, Forge degrades gracefully: it marks the projection as partial: true and continues without throwing an error.
The bridge fields (bt_fundraising__Giving_Model_Opportunity__c and bt_fundraising__Giving_Model_Gift_Transaction__c) already ship on bt_fundraising__Donation__c in the self-managed fundraising package — they are not placeholders. They apply only to standalone donations; there is no bridge field on bt_stripe__Transaction__c or conference360__Attendee__c.
Giving model admin settings
Admins can review which giving model Forge has detected, manually trigger re-detection, and configure mapping overrides from the Admin section under Giving Settings. Only users with the Blackthorn Events Admin permission set can access these settings.