How to resolve contact cases

The Contact cases page (/cases) lists the contact records the system could not sort out on its own. Everything it could sort out, it already did or has queued to do: matching a HubSpot contact to its MOM customer number, filling in a missing zip code, merging two HubSpot contacts that are plainly the same person. What is left on this page is the small set where two records might be one person, or one record might be two people, and only someone who knows the customers can say which.

Each case is one question. You answer it once and it stays answered. The next time the checker runs it remembers your answer and does not ask again.

Which number to keep when the answer is "same person": Picking the survivor.

Dormant records, and why the queue can look bigger than expected

The checker knows every MOM customer who ever ordered, not just the recent ones, so a customer who last bought in 2019 and comes back gets their old number instead of a new one. Records that are only old MOM entries arguing among themselves are not shown at all; they are kept as dormant cases (choose "dormant" under Show to see them) and appear in the queue only when one of those people places an order again.

Everything you do see involves someone active: a MOM record that ordered in the last two years, or a HubSpot contact with a deal now. Some of those cases are the old duplicate of an active customer that nobody could see before; answering them is what keeps a returning customer from ending up with two numbers. A record marked dormant in a case is one that has not ordered since the cutoff; the survivor is usually the one that has.

What you are looking at

Every case shows a small table of records, one row per record, pulled from up to three places:

The columns are what the checker used to connect them: the customer number, the name, the company, every email and phone it has seen for that record, the zip codes on its addresses, when the record was created, and whether it has ever bought anything.

Below the table, a line or two of evidence says why these records were put together: email=… means they share that email, name_zip=… means the same name at the same zip code, customer_number=… means they carry the same number.

A record's kind matters:

• person – a customer.
• recipient – someone MOM only ever shipped to on another customer's order (a program participant, a colleague who receives the box). They are not the buyer, and they are never merged into the buyer.
• org – a company record with no person's name.

Every case answers three questions

At the top of each case, in blue: What am I looking at? That is the scenario, one of the named situations below. Under the records: How did the checker get here? That is the evidence, written out as sentences ("these two share the email …", "same name at zip code …"). And What am I being asked to decide? The question, plus what each button would do in this particular case. Read those three before looking at the table.

There is a practice sandbox (button in the sidebar) with one made-up case for each scenario. Nothing you press there is saved.

The scenarios

The four kinds of case

Two numbers. The records look like one person, but MOM gave them two different customer numbers, usually because the customer was entered twice over the years, or once as a buyer and once as a ship-to. The question is: are these one person, and if so, which number should the customer keep?

What to check: same name and same organisation or zip is usually one person. A different first name at the same org email is usually two people. If one record has orders and the other does not, the one with orders normally survives. If both have orders, pick the one HubSpot already carries, or the newer one, and note why.

Shared email. One email address is on two or more MOM customers. Often it is an organisation's email address that several staff order through, or a manager ordering for a team. The question is: is this one person with two records, or several people who happen to share an email address?

What to check: the names. Different names at a shared address are different people; say so, and the email stays attached to whichever HubSpot contact already has it. Same name on both records is a double entry; pick the survivor.

Name conflict. The records were connected by something strong (a shared email, a shared number) but the last names do not match. Sometimes it is a name change or a hyphenated name; sometimes it is genuinely two people who shared a login or an email address at some point.

What to check: whether the names could be the same person (marriage, hyphenation, a typo). If yes, pick a survivor. If no, they are different people.

Stale number. A HubSpot contact carries a customer number that does not exist in MOM at all. Usually a typing error (an extra digit, a phone number in the wrong box) or a number from a customer record that was later deleted.

What to check: whether the MOM record in the case is clearly this contact. If so, pick the MOM number as survivor and the contact will be corrected. If nothing in the case matches, choose Different people; the bad number will be flagged separately.

The four buttons

Same person, keep survivor. Pick the customer number (or record) that should remain, then press this. What happens next, on the next run:

• HubSpot contacts carrying another number in this case are changed to the survivor's number.
• If two HubSpot contacts are in the case, the one with the survivor's number keeps its record and the other is merged into it. HubSpot keeps the merged contact's deals and emails; nothing is lost, and HubSpot can un-merge if it turns out wrong.
• Any missing details on the surviving contact (zip, address, a second phone) are filled from the other records.

This does not change MOM. If the losing number should also be retired in MOM, that is a separate step for whoever maintains MOM.

Different people. The records stay separate, permanently. The checker will never connect these particular records again, even if they still share an email. Use this whenever you are not confident they are the same person: keeping two records apart is cheap to fix later, merging two people is not.

Different customers, same organisation. Two real customers who belong to one company: a director and their assistant, or a company record and a person at it. The records stay separate for good, exactly as with Different people, and are also linked to each other as colleagues, which the company association will use later. If one of them is a person whose contact is carrying the company's number, pick the person's own number in the dropdown first and their contact is corrected to it.

Defer. Leave it open and move on. Nothing changes. Use it when you need to ask someone.

Fill in Decided by at the top of the page before you start, so the record of who answered stays with the case.

Field-by-field detail of what each answer does to the records, including the "two humans, one billable customer" situation: How merge works.

Worked examples

Two MOM records, same name, same church, one HubSpot contact. The HubSpot contact carries the newer number and has the orders. Answer: same person, survivor is the number HubSpot already carries.

Three MOM records at one @agency.org email with three different first names. Answer: different customers, same organisation (or different people if they are not colleagues). Each keeps their own record; the email address stays where HubSpot already has it.

One MOM buyer and one MOM recipient with the same name and address, both with numbers. The recipient row was created to hold a second shipping address. Answer: same person, survivor is the buyer's number.

HubSpot contact with customer number 2694934; MOM has 269493 for the same name and email. An extra digit. Answer: same person, survivor 269493.

What this page will not do

• It never deletes anything. Merges are HubSpot merges, which keep history.
• It never invents a customer number.
• It never changes MOM.
• It never touches records that are not in a case.

Finding your way around the queue

The round buttons at the top of the sidebar are the buckets, with a count in each. A case can sit in several at once, and answering it in one bucket answers it everywhere; the buckets only change what you are looking at.

• urgent — a HubSpot contact in the case is on an invoice or a deal. Do these first; they are what is blocking someone.
• recent — a MOM or website record in the case ordered within the last six months. These customers will be back soon.
• typos — the checker spotted values a keystroke or two apart. Usually quick.
• woo — a website buyer is involved.
• mom — a MOM record is involved.
• other — none of the above.

Under every case there is a Suggest a rule box. If a case makes you think "the checker should have handled this on its own", say how, and press the button. It files a note for the team (the same feedback the rest of APSync uses) and marks the case as having a suggestion. It does not decide the case; do that separately.

• Realm chooses the HubSpot portal; Show is open, decided, or all (decided cases keep a Reopen button).
• Scenario and Kind narrow the list to one situation.
• Sort by the newest record first (recent web buyers float up), oldest first, scenario, name, or by how many records are involved.
• Only keeps cases flagged as a possible typo, involving a website buyer, a ship-to recipient, a company record, or where every record has orders.
• Find is a forgiving search over names, emails, numbers and companies: "kathyrn" finds Kathryn, "27071" finds 270712.
• Fifty cases show at a time; press Show more at the bottom for the next fifty.
• A link of the form /cases?case=CASE-… opens one case on its own (the Revise button will use this).