Cookbook
Populate an empty workspace from what you already have
Your first session. You have a spreadsheet, an export, or a list in a document, and an empty workspace. At the end of this you have a populated CRM and a short list of the places your own data disagrees with itself.
The situation
You have just created a workspace. What you already have is a CSV your old CRM exported,
and it is messy in the ordinary ways: one company appears twice under two spellings, an
email is in capitals on one row and lower case on another, someone's job title changed
between exports, one domain has a www. on the front.
There is no import wizard to map columns in. Your agent reads the file and writes the records, which is why the mess does not have to be cleaned up first: an agent can read "Calder & Wren" and "Calder and Wren" and understand they are one company, and Indraft matches them on the domain rather than on how close the names look.
What must be true when you are done
- Every company and person from the file is in the workspace.
- Rows that describe the same organisation became one record, matched on domain and email rather than on name similarity.
- Every value is marked as imported, so later you can tell what came from a file from what a person actually checked.
- You have a list of the fields your source contradicted itself on, with both values.
- Running the same file again changes nothing.
The run
Give your agent the file and this instruction.
You
Read companies.csv and load it into Indraft.
Every row has a company and one person at that company. Use bulk_upsert so it goes in a few calls rather than one per row, and mark everything as imported, because you are relaying what the file says rather than asserting it yourself.
Then tell me which fields the file disagreed with itself about.
Two calls, one for the companies and one for the people. Ten rows in the file, and this is what comes back:
Agent
Ten company rows became five companies and ten contact rows became eight people. Nothing was refused and nothing was invented. The rows that collapsed did so because they share a domain or an email address, which is the only thing Indraft will merge on by itself.
Reading the conflict report
This is the part worth slowing down for, and it is the reason the import is worth running through an agent rather than a wizard. Six fields in the file said two different things, and rather than picking one quietly, the result named all six:
| Field | Your source also said | What the record kept |
|---|---|---|
| name | Meridian Freight Ltd | Meridian Freight |
| domain | www.northwind.co.uk | northwind.co.uk |
| name | Calder and Wren | Calder & Wren |
| industry | Legal services | Professional services |
| GRACE@brightlinefoods.com | grace@brightlinefoods.com | |
| title | Head of Procurement | Procurement Lead |
None of those is an error. They are six real questions about your data that nobody had asked yet. Is the company called Meridian Freight or Meridian Freight Ltd? Is Grace a Procurement Lead or Head of Procurement, and which export is more recent?
Within a single import the first value stands and every later one that disagrees is held. Sorting the file differently would keep a different value, which is why the report matters more than the rule: the choice is always in front of you rather than decided quietly by whichever row happened to be last.
Ask your agent to work through the list with you, and correct anything you want changed. A person's answer outranks an imported one, so a correction lands and stays: the next import of the same file will not undo it.
Verify the workspace
Three questions worth asking your agent before you move on.
- Did the right things merge? Ask it to list every company and read the list. Five companies out of ten rows should match your own sense of how many customers are actually in that file.
- Is anything empty that should not be? Ask for companies with no owner, or people with no email. Missing fields at this stage are missing in the source, and it is much cheaper to find that out now.
- Does the history look right? Ask for the recent changes. Every value carries who wrote it and that it was imported, and none of it is marked as confirmed, because nobody has checked it yet.
Run it again
Run the identical file a second time and nothing happens: every row matches what is already there, and the result says so. That is the property that makes this safe to repeat. Export again next month, run it again, and only what genuinely changed is written.
It is also what makes the conflict list worth acting on. Fix the two spellings in your source, run it again, and the list gets shorter.