How an issue is matched to an Attio record
An agent opens a request and wants one thing before they read a word of it: who is this, and what are we to them. The card answers that from a single piece of information, the reporter's email address in Jira. Everything else on the card, and every sentence it shows when it has nothing, follows from what the app does with that address.
There are two ways to use it. A project either looks up the reporter's own address, which finds the person, or only the part after the @, which finds the company they belong to. The choice is made on the Matching step of setup and changed later on the Matching tab of project settings, described there as "How a reporter is found in Attio, and how linked records are titled."
#What the app has to go on
Jira does not put a reporter's email address in the issue itself, so the app has to ask for it separately. It reads the issue as the person viewing it, takes the reporter from Jira's answer, and then asks Jira for that person's address as the app. The order is fixed and it matters: a viewer who cannot open the issue never reaches the address read, and the reporter is never taken from anything the browser sends.
Reading a reporter's address needs a Jira permission that Atlassian classes as sensitive, and a site administrator has to approve it. Until they have, every card in every project says that no email address is available. This is the permission that makes the product work at all: without it there is nothing to match a record against.
The address is never shown to anybody. No screen in the app prints the reporter's email address, nothing sent to the browser carries it, and it is never written to a log. Every sentence the card writes says "this reporter" rather than naming them. A record with no name is never titled by its email address either.
#Two ways to match, and only one of them runs
Setting | What is compared | What the card shows |
|---|---|---|
Match the person | The reporter's whole email address | The person who raised the request |
Match their company | Only the part after the @ | The company that person belongs to |
The Matching step says as much under each option. Under "Match the person": "The reporter's own email address is looked up, so the card shows the person who raised the request." Under "Match their company": "Only the part after the @ is looked up, so every reporter at a customer resolves to the same record. Free-mail domains are never matched."
There is no fallback between them. A project that matches the company and finds nothing does not quietly show the person instead, and the reverse is also true. The answer on the card is always about the thing the project was configured to look for, which is the only way an agent can tell what question it answered.
Matching the person is the default, and it is what every project set up before company matching existed is still using. The settings page states which is in force under the connection line, as either "This project matches the reporter to a person by their email address." or "This project matches the reporter to a company by their email domain." That line is read from what is saved, not from edits you have not saved yet.
#Choosing what the address is compared against
Two settings decide what the address meets at the other end: the record type, which is the Attio object your customers live in, and one attribute on that object. The address is tidied before it is compared, trimmed of surrounding spaces and lower-cased, because Jira hands addresses back with stray whitespace often enough to turn a customer who is plainly in the CRM into a no-match.
Matching | Attribute types offered | What is left out, and why |
|---|---|---|
Match the person | Email and Text | Domain, because matching a person on a domain would resolve every colleague at a company to the same record |
Match their company | Domain and Text | Email. Text is offered because plenty of workspaces keep a domain in an ordinary text field |
The record type comes first. Until one is chosen the attribute picker is disabled: "Attributes are read per object, so the record type has to be chosen before there is anything to match against."
Attributes archived in Attio are never offered, so a card cannot be built on an attribute that can no longer receive a value.
The first time the list loads with nothing chosen, the app pre-selects the likeliest attribute: an Email attribute when matching the person, a Domain attribute when matching the company, otherwise the first usable one. It never overwrites a choice you made by hand, and it picks again when you change the match method.
An object with nothing usable on it says so rather than offering a bad choice: "This object has no email or text attribute, so there is nothing to match a reporter against. Add one in Attio, or choose a different record type."
The same screen also carries titles for linked records, which is why its description mentions them. Those settings decide how a link to another record reads on the card, and they have nothing to do with finding the reporter.
#Whether one record is guaranteed
When matching the person, the Matching screen reports whether Attio enforces the chosen attribute as unique, because that decides whether an agent can ever be asked to choose. If it does, the screen says: "Two records cannot share the same value, so a reporter can only ever match one record. The card will never ask an agent to choose."
If it does not, the screen says so plainly: "Attio does not enforce uniqueness on this attribute and there is no setting that changes that. When a reporter matches several records, the card lists them and lets the agent open the right one rather than guessing." Attio cannot enforce uniqueness on a standard object's email attribute, so on People this is the message you should expect to see.
Changing what you match on clears the rest of the setup. Switching between matching the person and matching their company clears the record type, the attribute matched on, every field on the card, the linked-record titles, the nested attributes and the picture nominations. A confirmation names what will go before anything is thrown away, and confirming puts you back at the record type question. The two domain lists are the exception: they survive the switch. Changing the record type on its own clears the match attribute and the fields as well, and moves you to the Matching tab.
#A few things worth knowing
A match attribute that stops being usable is invisible to the people who will notice it first. If the attribute a project matches on is deleted in Attio, or changed to a type that cannot hold what is being compared, project administrators get a message naming the setting to fix and agents see nothing at all.
There is no refresh on a working card. A "Try again" control appears only when the card is showing an error or a rate-limit message, and an answer is reused for fifteen minutes, so a customer added to Attio this morning can take that long to appear on a request somebody has already opened.
The two domain lists do nothing when a project matches people. Switch a project from companies to people and a reporter on a free-mail address is looked up like any other, because the domain is never examined on that path.
#Related
One address in, one question answered.
