The current CSV wizard offers the types below. “Required” describes the pre-flight mapping requirements; individual rows and linked records still undergo backend validation. A field can come from a column or an appropriate static value.
| Entity | Required mappings / dependencies |
|---|---|
| Contacts | First Name or Email Address |
| Organisations | Name |
| Resources | Description |
| Tribute funds | Name |
| Payments | Amount, Currency, Status, Direction; include Date Paid and an owner when relevant |
| Touchpoints | Touchpoint Timestamp, Touchpoint Type, Direction; include Contact or Organisation in a pipeline |
| Recurring payments | Amount, Currency, Frequency Unit, Frequency Interval, Collection Day of Month; Contact or Organisation step |
| Fundraising activities | Name, Activity Type |
| Fundraising pages | Title, Fundraising Activity; creating a new page also needs a Contact owner step |
| Fundraising page members | Contact and Fundraising Page steps; optionally an external key |
| Memberships | External Key, Membership Type Name, Payer (external ID); member/payment references as appropriate |
| Sponsorables | External Key, Programme, First Name; select Contacts too, and map the same external key on both (see below) |
| Connections | From and To identifiers and one connection type mapping; both parties must already exist |
Common mapping fields
Contacts support names, address fields, email and alternate email, Phone, Mobile, Date of Birth, Is Child, Supporter Number, Subtype, source timestamps, linked organisation fields and communication consent. Full Address retains an unparsed address; it does not automatically fill the separate address fields.
For organisations, use Registered Address for the address shown in the application. The mapping catalogue also lists structured address fields, but these are not currently used by the organisation’s stored address. Organisation and resource mappings offer linked-contact fields.
The contact catalogue’s Linked Resource Description, Linked Resource Subtype and Linked Resource Connection Type do not currently create links because the corresponding backend field names differ. Use a supported resource/contact pipeline or a separate Connections import instead.
Sponsorables
A sponsorable is a person to be sponsored in a sponsorship programme. They are always a contact in Relationships, and their name, date of birth, address and contact details live there. The Sponsorables step carries only what a sponsor may be shown: First Name, Age Band (0-4, 5-8, 9-12, 13-17, 18+), Region (one of the programme’s regions), Interests (several values separated by |, up to 10) and Short Bio. Surname, date of birth and photos cannot be mapped here.
To import them:
- Select Contacts and Sponsorables. The Contacts step creates or finds the person; the Sponsorables step turns them into a Draft sponsorable.
- Map the field partner’s ID column as an External Key on both steps, under the same platform name. The Sponsorables step finds its contact through that key, so a different platform on each step means every row waits for a contact that never arrives and is then reported as failed. The ID is also what makes re-uploading the same file safe: a repeat creates nothing new.
- Choose the Programme as a static value from the picker. Only programmes that are configured and still open are offered. Importing needs the Write sponsorables permission as well as the importer’s.
Rows are imported as Draft sponsorables for review and approval; consent is recorded afterwards in the application. A row that cannot be imported is counted as failed and the reason is recorded against it: the programme is closed or not configured, the profile contains something that looks like an email address, phone number, web link, social handle or date of birth, the age band or region is not in the programme’s list, there is no first name, or the contact was not imported. The contact the Contacts step created is kept either way. Programmes whose sponsorables are groups cannot be imported from a file.
Consent
Email, Phone, Mail, SMS and WhatsApp consent fields use consent values such as ok, no and unknown. Select the applicable purposes separately in the mapping control. They do not take a comma-separated list of purposes as the consent value. Translate source codes with value mapping and preserve unknown consent as unknown.
Payment fields
Payment Status options are Paid, Pledged and Invoiced; Direction is Inbound or Outbound. Map Payment Method and Fundraising Activity when known. Breakdown fields include Purpose, Terms of Restriction, Amount and Percentage. Check these against the organisation’s configured funds and payment settings.
Touchpoint direction values are lowercase inbound and outbound, unlike payment direction values. Use the supplied static options or value mapping to avoid mismatches.
Custom fields and identifiers
Configured custom fields are available for contacts, organisations and resources. Multi-select custom values use | as a separator. Use Clear when blank only when an empty cell should remove a saved custom-field value.
Map source IDs using External Keys, including the platform name. Membership member external IDs are pipe-separated. Connections use separate From and To identifiers and a shared external-key platform; they can also resolve supported natural keys (contact email, organisation name or resource description).
See Prepare a CSV, Pipeline imports and the Importer API.