Skip to main content
Import turns CSV files into Orgo records. It is how you migrate from another system, load a historical archive, or push a bulk correction across thousands of profiles without touching them one at a time. Built for organisations arriving with years of data in another tool or in spreadsheets. Replaces the manual re-typing, and the “can you just run this SQL” request. The page is at Settings → Customization → Import (/tenants/import), titled Data Import System. Every import endpoint requires ADMIN_TENANT. Data Import System page showing the recommended import order as numbered steps, each with a Choose CSV button and an example file download

​
How the page works

The page is a numbered list, not a wizard: each entry is one import type. No column-mapping screen, no options dialog, no dry run. The file you upload is the instruction.
1

Download the example CSV

The download icon on each step gives you a file with the exact column headers that step reads.
2

Choose CSV

.csv and .txt, up to 50 MB. Comma, semicolon and tab are detected automatically, and a UTF-8 byte order mark is stripped. A larger file is refused on the spot with “File is larger than the 50 MB import limit”; split it and run the parts one after another.
3

Start Import

Validation and processing run in the background, in batches, so a large file keeps going after you close the tab.
4

Watch the progress

A live percentage, refreshed every three seconds, with running counts of successful, failed and skipped rows. The counts move one batch at a time rather than one row at a time, so a file small enough to fit in a single batch stays at 0% until it finishes.
5

Read the errors

Expand the row in Import History for per-row failures: row number, message and raw row data. The first 20 are listed, with the total count underneath.
Orgo does not email you when an import finishes. Keep the page open, or come back to the history table.
Validation runs before any row is written: Orgo looks for the header row in the first 10 lines and checks the required columns. If they are missing, the import fails naming the columns it wanted and the ones it found, and nothing is created.

​
What you can import

Run the steps in the order below: each one can reference records the earlier ones created. Steps whose module is switched off do not appear at all. The *_legacy_id columns are the glue: your old system’s identifiers, stored on the Orgo record, are how a later file says which event an attendance belongs to. Keep them stable across all your files. Where a step accepts several column shapes, give it legacy ids if you have them, or human columns like event_name and event_datetime, and Orgo creates or links the event, product, price tier and attendee for you. Companies and Company Members check their required columns row by row rather than upfront, so a file with the wrong headers starts, then fails every row.

​
Creating versus modifying

The first sixteen steps only create: a row matching an existing record counts as skipped and the record is left alone. Users match on user_legacy_id first, then on email. Contacts whose email belongs to an existing member are skipped by design. The last two steps, under the Modify existing records heading, update in place:
  • Modify Users matches on email, then user_legacy_id, then phone_number, in that order. Modify Contacts matches on email, then phone.
  • An empty cell leaves that field unchanged. Only columns you fill in are written.
  • A row that matches nothing falls back to creating a contact, provided it carries at least an email or a name.
  • Usernames, passwords, permissions and API tokens can never be written by an import.
Imported members get no email and no usable password: the import writes a placeholder nobody knows. Someone imported with their own address signs in with the email one-time code from the login page, or through a password reset. A row whose email already belongs to somebody else, and a row with no email at all, gets a generated placeholder address that cannot receive mail, so those members cannot sign in until you correct the address.

​
Custom fields

Any column that is not a recognised system column for that step becomes a profile custom field. If none with that name exists, Orgo creates one (text, visible on the profile) and stores the value, so custom fields need not exist before the import. A column named custom_field_123 writes to the existing custom field with that id instead, which is useful when two of your fields share a label.

​
Rolling back

Every completed import has a Rollback button in Import History, until you use it once. For the create steps, rollback deletes the records that import made, in reverse dependency order, so nothing is left pointing at a missing parent. For Modify Users and Modify Contacts, Orgo stored a before-image of every row it touched: rollback replays those values, including custom fields, then deletes any contacts the fallback created. The whole rollback is one transaction, so it either completes or changes nothing.
Rollback of a modify import restores the values as they were at import time. If another import or an admin changed those records afterwards, those later changes are reverted too.
Import History table listing past imports by type and status, including a Processing import with its percentage, a Failed import, and Completed and Rolled Back imports, with results counts that show failed and skipped rows alongside the successful ones and a Rollback button on the completed imports Statuses you will see: Pending, Validating, Processing, Completed, Failed, Rolled Back. The history keeps the 50 most recent imports.

​
Troubleshooting

Header validation. The message lists the columns the step needs and the ones it found: check for a title row above the headers and for renamed headers, then upload the corrected file.
Skipped means the record already exists, the expected result when you re-run the same file. To update those records instead, use Modify Users or Modify Contacts.
Progress is written when a batch finishes, so a minute or two at 0% is normal on a file that fits in one batch. The slow case is a Local Centers, Units or Users file whose town column names places Orgo has not seen before: each new name is looked up against an external place-name service one row at a time. Leave it running and reload the history table. If it is still Processing after fifteen minutes with no counts, the batch did not finish and nothing was written: split the file into smaller parts and run them one after another.
The header did not match a system column for that step. Built-in names are snake_case (first_name, phone_number, birth_date, town_residence), not camel case. Compare against the example CSV, roll the import back, fix the header, run it again.
Yes, but not from this page. Open the list and use the CSV import inside it. See Lists & Segments.