Skip to main content
Built for the moment you are about to map a file and need the answer for one type, not a tour of the whole wizard. Jump to your type and read the entry. Replaces opening the example CSV and guessing what each header does.

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.
Example file: 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.
Example file: 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.
Example file: 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.