Import & Export

Both products have their own Import / Export tab, because each imports a different set of entities: Equipt Settings → Import / Export and Landscapt Settings → Import / Export. Each tab is self-contained — an Export Data panel of entity tiles at the top, an Import Data panel of entity tiles below it. There is no cross-product import screen; Vendors (shared between Equipt and Landscapt) are imported from the Equipt tab only.

On an org without Equipt enabled, the Equipt-only tiles (Work Orders, Assets, Vehicles, Parts) are hidden from both the export and import panels — only Vendors, Requisitions, Products, and Purchase Orders remain, since those are shared with the PO backbone.

Export is real, and it is genuinely a full data export, not a template stub — each tile downloads a CSV of every current record for that entity (not just headers), in the same column order and naming as that entity's import template. Clicking a tile with no records in it does nothing (the export handler returns early rather than downloading an empty file).

Money fields are converted from stored cents to a formatted dollar string on the way out (e.g. Parts' unit cost, Purchase Orders' grand total). Everything else is written as-is from the record.

Safe to open in Excel or Sheets. A text value that starts with =, +, -, @ or a tab would be run as a formula by a spreadsheet, so the export puts a single quote in front of it (a client name typed into a public form as =HYPERLINK(...) shows as plain text instead of executing). Plain numbers, including negative amounts, are left alone. When you import a file, that protective leading quote is removed again (only in front of =, +, - or @), so an export round-trips cleanly.

1. Click an entity tile in the Import Data panel — this opens a file picker restricted to.csv.
2. The app reads your CSV's header row and tries to auto-map every expected column against it: exact match first, then a case/punctuation-insensitive match, then a table of common aliases (e.g. a column literally titled "Part #", "SKU", or "Part No" all auto-map to partNumber; "Qty" or "On Hand" map to quantityOnHand).
3. If every expected column matched automatically, it skips straight to the preview. If anything didn't match, a Map Columns dialog opens listing every expected field with a dropdown of your CSV's actual columns (or "Skip") — this dialog is effectively the field reference, since there's no separate template download.
4. Fields marked with a red asterisk are required for that entity. You cannot continue past the mapping dialog until every required field has a column assigned.
5. A preview step shows the first 5 mapped rows in a table and the total row count, plus an Import Error state if the file was empty, unreadable, or missing a required mapping. This is the only pre-commit check — there is no server-side dry run separate from this client-side preview.
6. Clicking Import N Rows sends every mapped row to the entity's import handler at once. A success or error banner appears above the Export/Import panels when it finishes.

Equipt (Settings → Equipt → Import / Export):

Landscapt (Settings → Landscapt → Import / Export):

Say you're bringing over 40 vendors from a spreadsheet with columns Supplier, Contact, Phone, Email, and Type.

1. Settings → Equipt → Import / Export → click the Vendors tile under Import Data.
2. Upload the file. name is the only required field for Vendors, and "Supplier" doesn't auto-match it (it's not in the alias list), so the Map Columns dialog opens with Name still unmapped.
3. Map Name → Supplier, Contact Name → Contact, Email → Email, Phone → Phone, Vendor Type → Type. Address, Website, and Notes have no matching column in your sheet, so leave them as "Skip" — they aren't required.
4. Continue to Preview — confirm the first 5 rows look right, then click Import 40 Rows.
5. Behind the scenes, rows import one at a time. Any row missing a name is silently dropped from the count entirely (not created, not reported as an error). For every remaining row, a vendor with that exact name already on file is updated in place with the new row's contact info, address, type, website, notes, and active flag — it does not create a duplicate vendor. Everything else inserts as a new vendor.

The same shape applies to Parts (keyed on partNumber instead of name) and most other entities — see the table in the next section for what's keyed on what.

The FAQ's short version — "the importer validates each row before committing" — is really two separate mechanisms:

• Required-field validation happens twice: once at the column-mapping step (you can't proceed if a required field has no column assigned), and again per-row at import time (a row whose required value is blank after trimming whitespace is dropped and counted as "skipped" — it never reaches the database, and it does not stop the rest of the batch).
• Duplicate handling is not a validation failure — it's a merge. Rows are inserted one at a time; when the database rejects an insert because of a unique constraint (Postgres error code 23505), the importer treats that as "this record already exists" and updates the existing row instead, rather than erroring or creating a second copy.
• For entities not listed as reporting row by row, any other database error (not a duplicate-key violation) is not swallowed — it throws, which stops the mutation and surfaces the error message in the preview dialog's error banner. Rows already committed earlier in that same batch stay committed; rows after the failure are never attempted. There is no all-or-nothing transaction wrapping the whole CSV.
• File format. The importer reads UTF-8, Windows-1252 (what Excel's “CSV (Comma delimited)” saves on Windows) and UTF-16 (“Unicode Text”) files, so accented letters and curly quotes come through intact. It detects whether columns are separated by commas, semicolons or tabs from the header row. Money cells may include $ and thousands separators ($1,250.50).
• Results summary. When some rows import and others fail, the dialog says so (for example “12 imported, 3 failed”) and lists the failing rows with the reason, rather than reporting success. Rows deliberately not imported because they match an existing record are listed separately as skipped (duplicates), not as failures.
• Vendors, Assets and Vehicles also report row by row: a row with a missing name or tag, an unreadable date or price, or a database error is listed as failed with the reason, and the rest of the file still imports.
• Estimates, Invoices and Payments are more forgiving about bad rows: one bad row is reported and skipped instead of stopping the import. Amounts can be typed the way Excel or QuickBooks writes them ($1,234.50), and dates can be YYYY-MM-DD or M/D/YYYY. A row is skipped, with the reason shown, if its amount or date can't be read, if no client matches, or if two clients share the name on the row (add an accountNumber column to say which one). Re-importing the same file creates the records again, so import each file once.
• Estimate import extras. amount adds one editable line, “Imported estimate total”, so the estimate carries its old total instead of $0. salesperson is matched to an employee by full name (a blank, unknown or duplicated name just leaves the rep empty). probability takes a percent such as 60 or 60%. externalRef is the estimate number in the old system; it is saved in the estimate's notes as “original estimate #”.

Purchase Orders import differently from every other entity — it's the one importer built for a denormalized export format (multiple CSV rows per PO: one row per line item, repeating the PO-level fields on every row) rather than one row per record. No column is marked required in the UI, because the importer groups rows by Purchase Order # itself — a row with no PO number is silently dropped from the group before anything is grouped.

1. All rows sharing the same Purchase Order # are grouped together; the first row in the group supplies the PO-level fields (Vendor, Status, Created On, Approved On, Completed On, Due Date).
2. Vendor is matched by name (case-insensitive) against existing vendors; if no match exists, a new vendor is created on the fly from just that name.
3. Rows are split by Line Type: PART lines become PO line items and drive the subtotal; PERCENT_TAXABLE lines set the tax rate (parsed out of the line name, e.g. "CT Sales Tax (6.35%)") and tax amount; AMOUNT_TAXABLE lines are summed into shipping cost. The PO's po_number is generated as PO-{year}-{csv PO #}, where the year comes from the CSV's Created On date, not today's date.
4. If a PO with that exact generated number already exists, the whole PO (and all its lines) is skipped — not merged, not updated, not counted as imported. Re-running the same export is safe; it won't duplicate POs.
5. For each PART line, the importer resolves a Products catalog entry by Part Number first, falling back to matching by item name only when no part number is given. If nothing matches either way, a new catalog entry is created (category defaults to maintenance_part). A line with neither a usable part number nor a name is skipped rather than inserted without a catalog reference — every PO line item must reference a Products catalog entry per this platform's data rules.
6. Quantities accept decimals (for example 2.5 gallons) and a blank cell means 1. Maintenance parts must be whole numbers, and text or zero/negative quantities are rejected. Every row that can't be imported — a duplicate PO, a bad quantity, a line with no catalog match, or a line the database refused — is listed with its row number and reason in the results summary instead of being dropped silently.
7. When the resolved catalog entry has a part number, the importer also syncs it into CMMS Parts inventory: it links to an existing Part with that product_item_id or part_number if one exists, or creates a new Part record at zero quantity on hand otherwise. Quantity on hand is not incremented by a PO import — that only happens through the separate Goods Receipt flow.

The Products catalog and Parts inventory each keep one name per part number — whichever name they saw first. If a later PO import uses a different name for a part number that's already on file, the importer does not overwrite the existing name and does not silently keep the newer one either — it leaves the catalog untouched and writes a name_conflict entry to that record's audit trail so the mismatch can be reviewed instead of lost.

This is intentionally conservative: if the two names really do describe the same interchangeable part, no action is needed — the catalog is still correct and the PO line still links to the right record. If they turn out to be two genuinely different parts that happen to share a part number by data-entry mistake, the audit trail entry is what tells you to go split them apart rather than assuming a later import quietly relabeled something.

The same check runs independently for the Products catalog entry and, when one is linked, the CMMS Part record — so a single conflicting import line can produce up to two audit trail entries: one on the product, one on the part.

• CSV only. No Excel (.xlsx), JSON, or other format is accepted by either the file picker or the underlying parser.
• No standalone template download in this panel. Use an export of the same entity (even with a couple of dummy rows deleted afterward) as your column reference, or rely on the Map Columns dialog, which lists every expected field.
• No pre-commit server-side dry run. The 5-row preview table is a client-side rendering of your mapped CSV, not a validation pass against the database — duplicate and error handling only happens once you click Import.
• Re-importing updates only what the file contains. For Equipt entities (Products, Parts, Assets, Vehicles, Work Orders and Vendors) a matched record is updated with just the columns present and filled in; blank cells and missing columns leave the saved values alone, and stock quantities change only through a recorded adjustment. See the table above for each entity's matching key.
• Import only creates or merges — it never deletes. There is no way to remove records via CSV; re-importing an export you haven't edited is a safe no-op for entities that dedupe by a stable key, but it will not clean up records removed from the source system.
• Requisitions import has no vendor auto-create logic the way Purchase Orders does — check your vendor names are already in the system (or import Vendors first) if you're bulk-loading requisitions with a vendorName column.

• Client import round trip. The client export has the same columns the import accepts (including status, client since, names, billing email, tags, parent account and crew notes), so exporting and re-importing changes nothing and creates no duplicates.
• Row numbers. Failed, skipped and warning rows are listed with the line number in your CSV file (line 1 is the header). Rows that imported with something to check, such as an unknown status, are listed as warnings.
• New tags. Tags in a client file that aren't in Settings → Tags yet are added there when your role can edit CRM settings, so you can filter and bulk-tag by them.
• Leads import report. The leads import lists every row that failed or matched an existing client, with its line number.
• Quoted text with line breaks. A quoted cell that contains both doubled quotes (""like this"") and a line break imports as one cell instead of splitting the row.