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, and so do Users and Contacts when you set Members that already exist to Update the mapped fields on the mapping screen. 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 (and Forms writes to the questions of its form); 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 file carrying the canonical headers for every column of the type, with a few demonstration rows. The same file is served by GET /imports/template/{type} for anyone working through the API.

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 lists these under five headings: Identity, Contact, Membership, Profession and Roles. Chapter. The local_center column is read: a chapter is found by its legacy id first, then by its name (capitals ignored). A chapter that does not exist is not created; the member is imported without one and the row carries the warning Chapter “X” not found, left empty. On organisations in the US that assign chapters by state, a member who ends up with a town but no chapter from the file is placed in the chapter of the town’s state, so a misspelled chapter name falls back to the state chapter and warns. Members created into a chapter get that chapter’s follow and local fee. Required: email. Already exists: the email address, compared without regard to case. A row whose email already belongs to a member is skipped, and the legacy id from the file is recorded on that member if they had none, so later files can find them. 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. With Members that already exist set to Update the mapped fields, a matched row is updated instead of skipped, field by field, exactly as in Modify Users. 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. With Members that already exist (the label is the same on a Contacts file) set to Update the mapped fields, a row that matches a contact is updated as in Modify Contacts; a row that matches a member is still left alone. 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 (Users does the same when set to update existing people). 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.
date_created is offered by the mapper but a modify run does not write it. An empty cell writes nothing, so a blank column cannot clear a value that is already stored. A value Orgo cannot use (an unknown chapter, a date it cannot read) leaves that one field unchanged and the row carries a warning.
A modify run that changes a member’s chapter, or a town that moves them to a different state chapter, applies the same effects as a manual move: ordinary memberships at the old chapter end and the follows and local fee switch. Positions with permissions are not ended. See Moving members between chapters.
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 are added to the contact, never removed. The member legacy id is 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. When a payments run finishes, or is rolled back, Orgo recomputes every member’s fee dates, since payments extend a membership. 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. A row that names no unit, for a role that belongs to a chapter, is placed in the member’s own chapter (a parent-chapter role goes to the chapter above it). A member with no chapter to place it in fails the row with Member is not part of any chapter. A unit named in the file always wins. 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. An imported membership is the person’s primary one, and a person has only one: a row for someone who is already the primary member of another company, in Orgo or earlier in the same file, is skipped with the note to add them as an associate from the company page. 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.

Event Attendance

Records who attended which event, one row per person per event. Required: two things. Already exists: the event and the person together. Somebody already recorded at the event is skipped, and so is a repeat of the same person and event inside the file. Custom fields: no. Use the event legacy id when you have one: it names the event unambiguously. Naming events by name is covered in Linking records, including why the spelling has to match exactly. A person with no email who is created from a name is created again on every run. Example file: import_event_attendance.csv, from the Example CSV link on the Event Attendance 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.

Forms

Loads the answers from a form export (a Google Forms or Typeform download, for example) as responses to one of your forms. It sits under Standalone imports, needs the Form Builder module, and does not depend on any other step. Each row becomes one response. Before you map, the card asks where the responses go: Import responses into a form you pick from the list, or A new form, which you name under New form name (pre-filled from the file name). The form is created when you press Start import. Every other column is a question of the form. In the mapping screen the destinations read Respondent, Existing question, New question and Skip: point a column at a question the form already has, or declare a new one, with the same types and value matching as profile custom fields (Custom fields). New questions are added after the form’s existing ones, in the order of the columns. Required: nothing. A file with no respondent columns imports anonymous responses. Already exists: nothing is checked, so running the same file twice records every response twice. The only rows skipped are those with no answers in them. Rolling back deletes the imported responses, removes the questions the import added if nothing else uses them, and deletes a form the import created if no responses remain. Example file: import_form_responses.csv, from the Example CSV link on the Forms card. There is no template download for Forms, because its columns are your own questions.