The module imports cover the lists most people move: people, giving, invoices, clients and so on. Advanced Import covers the rest. You choose the table, and map your columns straight onto it.
When to Use It
- Event registrations, attendees and ticket orders.
- Group members, one row per person per group.
- Work orders, assets, vendors' equipment, facilities records.
- Anything else you can see in Studio that does not have a module import of its own.
If a module import exists for what you are bringing in, use that instead. It knows things the generic path cannot, such as how a gift attaches to a donor or how invoice lines collect onto one invoice.
Running It
- Go to Imports → New Import and choose Advanced under “need more control?”.
- Search for the table you want. Type what the records are called, such as registrations or assets.
- If the table belongs to a parent record, pick it. Importing registrations, for example, asks which event they are for, and then fills that in on every row so your file does not need the column.
- Upload your file and map the columns. The field list is that table's real columns.
- Review and run.
Start From a Template Here Too
Once you have picked a table, the download button gives you a CSV whose headers are that table's own fields, so everything maps itself on the way back in. It is the fastest way to see what a table actually wants.
People Are Still People
If the table you are filling attaches to a person, mapping an email column matches an existing person or creates one, and links the row to them. You get one person record shared with the rest of Studio rather than a private copy inside that table.
What It Will Not Let You Touch
Billing, payment ledgers, integration credentials, audit trails and platform configuration are all walled off, and no amount of searching will surface them. Those are not data-entry tables, and a CSV is not the right instrument for them.
Reverting
Supported, and it works the same way as everywhere else. Studio records what it created and what it changed, so a revert deletes the rows it added and puts changed rows back as they were. People created along the way are kept, because People is shared with the rest of the product.
Two Things Worth Knowing
- Duplicate protection is conservative here. A row is matched to an existing one only on an obvious natural key, such as an email within the parent record you chose. If your file could contain the same record twice, check before running.
- Required columns are worked out from the table itself. If the review step will not let you continue, it is naming a column the table genuinely cannot do without.