Opening data, and bulk changes after it, arrive by spreadsheet import, offered on the master lists themselves: Download template — a workbook with the exact columns, example rows, and an instructions sheet naming each list's natural key and rules — and Import. Both sit behind a per-list import permission, so who may import what is yours to decide (16.2).
The wizard walks three steps:
- Upload the filled workbook.
- Preview — every row is checked against your live data before anything is saved: codes that clash, references that do not exist, parents that fail. Errors come back with their line numbers, and the whole error list downloads as its own workbook for fixing. While any error stands, the commit button stays disabled — a rule of the framework, not a formatting preference. One exception is named on the preview itself: a row that merely repeats an earlier row's key is marked DUPLICATE. It does not hold up the import — at commit it is rejected and reported by row, the first occurrence is kept, and the rest of the file lands. A sheet larger than 10,000 rows is refused before it is read, by name and with its true row count; files that size belong to Data Migration (System Setup → Data Migration), which stages files of any size.
- Commit — the file is re-checked against live data one last time, then saved in a single transaction. If the save itself is refused — a database rule the preview could not foresee — the wizard stays on the preview, tells you plainly that nothing was saved, and names the reason. An import never fails silently.
Three laws make imports safe to re-run. All-or-nothing: a file with one bad row imports nothing — never a partial master. (Repeated rows are the one exception: the first occurrence is kept, each repeat is rejected and reported by row, and the valid rows commit.) Natural keys: rows are matched by the code the business knows — account code, product SKU, customer and supplier codes — in one of two modes: create skips rows that already exist, update refreshes them, so correcting a spreadsheet and importing it again converges instead of duplicating. Imports never delete: a row absent from the file is untouched, always.
The chart of accounts workbook is the special case: three sheets — groups, then accounts, then subledgers — validated in that order, with a failed parent blocking its children (they are reported as blocked, never orphaned), and a firm refusal of any balance column. Opening balances do not belong in a chart import; they arrive as opening entries and journals (7.6, 7.7), where they can be checked like any other posting. Bank statements import too, by their own two-sheet workbook (7.6).
What can be imported: the chart of accounts, products, customers, suppliers, tax codes, units of measure and their conversions, warehouses, branches, departments, product, customer and supplier categories, sales territories, contact titles, payment terms — and bank statements. Every import is itself recorded: who ran it, which file, how many rows were created, updated and errored, and the outcome.
The newer modules import by the same machinery, each from its own list page. Donors and donations (Donations module), CRM parties, leads and opportunities and the campaign register (CRM module), and purchase orders and goods receipts join the list. A few rules are worth knowing:
- Masters import live; transactions land as drafts. Imported donations, purchase orders and goods receipts always arrive as drafts, ready for a human to check, approve and post — an import never posts anything. Imported orders and receipts are matched by their document code: re-importing the same file skips what is already there instead of duplicating it.
- Module-gated imports follow the module. With the Donations or CRM module switched off, its imports do not appear on the list pages at all, and opening the import wizard for one directly says plainly which module to switch on first. Campaigns belong to CRM, so the campaign import follows the CRM module.
- Donations keep their currency discipline. A gift in another currency takes the rate on its row, or the rate table's rate for the gift date. A foreign gift with no rate in either place still imports — as an unrated draft whose posting will stop and say why until a rate exists. A rate is never invented. Campaigns are matched by their register code only, never by name; an unknown code stops that row with the reason named.
- Campaign targets freeze like everything else. The numeric target on an imported campaign freezes its functional equivalent on save, exactly as if you had typed it on the register. Spend is never imported — spend is entered on the register itself.
- Goods receipts receive against orders already in the system. Each receipt line is matched to a line of its purchase order by product; a product the order does not carry stops that row. The accepted/rejected split imports too — and wherever any quantity is rejected, the rejection reason code is required, just as on the receipt form.
- CRM parties stay parties. Importing parties never creates customers or donors and never links a party to one; linking is a deliberate act on the party's own page. Leads arrive as new leads — party, source and interest; pipelines, stages and values belong to opportunities, whose import carries them: the pipeline by its code, the stage by its name within that pipeline, and product lines whose prices become the lines' indicative prices.
- Bills of materials and work orders import too (Manufacturing module, from the Bills of Materials and Work Orders lists). A bill of materials is a master — it imports live, matched by its code — and a product carries exactly one bill of materials: a file naming a second one for the same product is refused by name. In update mode the file's lines replace the bill's existing lines; they are never added on top. Kit lines carry a quantity per finished unit; formula lines carry percents, and a formula's percents must sum to 100 or the bill is refused. Work orders are transactions, so they land as drafts, always, skipped by their code on a re-import: each names its product by SKU (manufactured products only), its branch and its issue and receive warehouses by code, and the bill of materials it will explode at release — leave the bill blank to use the product's active bill.
- Employees, projects and timesheets import too — employees from the Employees list (People module), projects and timesheets from the Projects and Time Entries lists (Time Tracking module). Employees and projects are masters: they import live, matched by their code. An employee row names its department and branch by code, and its supervisor by employee code — the supervisor must already exist, so import supervisors first or leave the column blank and set them on the record; an employee can never be their own supervisor. A project row must name its customer by code (every project belongs to a customer) and may name its manager by employee code. Timesheets are transactions with a rule of their own: every row lands as a draft time entry — an import never approves anyone's time, and never submits it either; submit and approval stay human acts on the entry. A timesheet row names the employee and the project by code and carries the date, the hours and a description of the work. Leave the billing rate blank and it is worked out exactly as the entry form works it out — the project's rate first, then the employee's own billable rate — and the overtime split is calculated on save, as it is for a typed entry.