How to read an entry
Every type below has the same parts.- Fields. What you can map. Field is the name the wizard shows in its destination list; Column is the canonical name Orgo uses internally and in the example file. Your own spreadsheet headers do not have to match either one: you point each column at a field yourself while mapping.
- Required. What the mapping must cover before Start import unlocks. Every group has to be satisfied, and inside a group any one alternative is enough.
- Already exists. How Orgo decides a row describes a record it already has. A match is skipped, not updated. Only Modify Users and Modify Contacts change records that are already there. Re-uploading a corrected sheet through any other type changes nothing for the rows that match.
- Custom fields. Whether this type can write to custom fields. Only the four people types can; for every other type the field list below is the whole vocabulary, and a column that is not on it can only be skipped.
- Example file. The Example CSV link on that type’s card, a small file with the canonical headers.
The types at a glance
Order matters when you run several types: each one can name records the earlier ones created, so chapters before members, products before price tiers, price tiers before payments. The import page lists the types in a workable order already.
Users
Creates member accounts.
The wizard shows these as one flat list rather than in groups.
Required:
email.
Already exists: the email address, compared without regard to case. A row whose email already belongs to a member is skipped. A row with a blank or unusable email fails rather than creating a member. Map the legacy id as well and a member carrying that legacy id counts as a match too.
Custom fields: yes.
Example file: import_users.csv, from the Example CSV link on the Users card.
Contacts
Creates contacts: people you hold details for who do not have a member account.
The wizard shows these as one flat list rather than in groups.
Required:
email.
Already exists: the email address, checked against both members and contacts. An email that already belongs to either is skipped.
Custom fields: yes.
Example file: import_contacts.csv, from the Example CSV link on the Contacts card.
Modify Users
Updates members who are already in Orgo. One of the two types that change existing records.
Required: one group, three alternatives. Map
email, or user_legacy_id, or phone_number.
Already exists: this type only ever works on records that exist. Each row is matched on email first, then legacy id, then phone number. A row that matches no member is tried against your contacts on the same details, and a contact is updated or created from it.
Custom fields: yes.
The wizard offers the full member field list here, but a modify run writes only the fields in the table above. Anything else you map, including
date_created, tags and the fee price legacy id, is accepted and then goes unused. An empty cell writes nothing either, so a blank column cannot clear a value that is already stored.import_user_modify.csv, from the Example CSV link on the Modify Users card.
Modify Contacts
Updates contacts who are already in Orgo. The second of the two types that change existing records.
Required: one group, two alternatives. Map
email, or phone. There is no legacy id alternative here, because contacts carry no legacy id of their own.
Already exists: each row is matched on email first, then phone. A row that matches nobody creates a contact, as long as it carries an email or a name.
Custom fields: yes.
tags and the member legacy id are offered by the mapper but not written by a modify run. An empty cell writes nothing, so a blank column cannot clear a stored value.import_contact_modify.csv, from the Example CSV link on the Modify Contacts card.
Product Payments
Creates payment records, and the payer, product and price tier each payment needs.
Required: two things.
The Product and Price tier groups are optional: a payment with no product is treated as a donation, so a payments file without product columns validates and imports.
Already exists: the payment legacy id when you map one. Without it, Orgo builds a fingerprint from the payer, product, price tier, amount, payment date and period, and a second row with the same fingerprint is skipped. That is what stops a re-run of the same file doubling every payment.
Custom fields: no.
Example file:
import_product_payments.csv, from the Example CSV link on the Product Payments card.
Products
Creates products and fees.
Required:
name.
Already exists: the product legacy id when you map one, otherwise the name, compared without regard to case.
Custom fields: no.
Example file: import_products.csv, from the Example CSV link on the Products card.
Product Prices
Creates price tiers under an existing product.
Required: one group, two alternatives.
Already exists: the price tier legacy id when you map one. Without it, the product plus the tier name plus the amount to the cent. The amount is read to two decimals, so
10 and 10.00 are the same tier.
Custom fields: no.
Example file: import_product_prices.csv, from the Example CSV link on the Product Prices card.
Local Centers
Creates chapters.
Required:
name.
Already exists: the chapter legacy id when you map one, otherwise the name, compared without regard to case.
Custom fields: no.
Example file: import_local_centers.csv, from the Example CSV link on the Local Centers card.
Units
Creates units and groups.
Required:
name.
Already exists: the unit legacy id when you map one, otherwise the name, compared without regard to case. Chapters, groups and role groups are left out of that name check, so a unit can share a name with one of them.
Custom fields: no.
Example file: import_units.csv, from the Example CSV link on the Units card.
Roles
Creates roles, including the membership types people can hold.
Required:
name.
Already exists: the role legacy id when you map one, otherwise the name, compared without regard to case.
Custom fields: no.
Example file: import_roles.csv, from the Example CSV link on the Roles card.
User Roles
Gives members their roles, optionally inside a unit, for a period of time.
Required: three things.
The Unit group is offered but never required.
Already exists: the member, the role, the unit and the start date together. The same person can hold the same role twice as long as the start dates differ.
Custom fields: no.
Example file:
import_user_roles.csv, from the Example CSV link on the User Roles card.
Companies
Creates company records.
Required:
name.
Already exists: the company legacy id when you map one, otherwise the name, compared without regard to case.
Custom fields: no.
Example file: import_companies.csv, from the Example CSV link on the Companies card.
Company Members
Links members to the companies they belong to.
Required: two things.
Already exists: the company and the member together, among memberships that have not ended. Somebody already in the company is skipped.
Custom fields: no.
Example file:
import_company_users.csv, from the Example CSV link on the Company Members card.
List members
Adds people to one static list. This type is not on the import page: you start it from the list itself, so the list you are importing into comes from where you started rather than from a column in the file.
Required: one group, four alternatives. Map
email, or user_legacy_id, or phone, or name.
Already exists: membership of the list itself. Somebody already on the list is counted as already there rather than added twice. A row with no email is also matched against your existing contacts by name before a new contact is created.
Custom fields: no.
This is the one link type with no match preview. What a row resolves to is decided during the run, so a preview would not tell you the truth.
import_user_list_members.csv, from the Download example CSV link in the list’s import panel.
Events
Creates events.
Required:
name and datetime_begin.
Already exists: the event legacy id when you map one. Without it, the name plus the start time to the minute, so two events of the same name at different times are two events, and the same name at the same minute is one.
Custom fields: no.
Example file: import_events.csv, from the Example CSV link on the Events card.
Badge Types
Creates the categories badges are filed under.
Required:
name.
Already exists: the badge type legacy id when you map one, otherwise the name, compared without regard to case.
Custom fields: no.
Example file: import_badge_types.csv, from the Example CSV link on the Badge Types card.
Badges
Creates badges under a badge type.
Required: one group, two alternatives.
Already exists: the badge legacy id when you map one, otherwise the name, compared without regard to case.
Custom fields: no.
Example file:
import_badges.csv, from the Example CSV link on the Badges card.
Badge Assignments
Awards badges to members.
Required: three things.
Already exists: the badge, the member and the day of the award together, plus the award legacy id when you map one. The same badge can be awarded to the same person more than once, which is why the date is part of the key, and why it is required: a file without it, re-run on another day, would double every award.
Custom fields: no.
Example file:
import_badge_users.csv, from the Example CSV link on the Badge Assignments card.
Related
- Data Import - what the wizard is and the steps it runs through
- Preparing your file - formats, headers, dates and the example files
- Mapping columns - the mapping screen and what blocks Start import
- Custom fields in an import - mapping onto existing fields and declaring new ones
- Linking records - how a row finds the member, product or event it names
- Custom Fields - the fields an import can write to
- Lists & Segments - where a List members import starts
- Merging Duplicates - cleaning up records an import doubled

