Step 3: Choose how issues are matched
This is the step that turns a reporter into a record. The app reads the reporter's email address on the server and asks Attio for the record whose chosen attribute holds it.
#The two ways to match
Match on | What the app sends to Attio | Typical record type |
|---|---|---|
The reporter's email address | The whole address | The object holding people |
The reporter's email domain | Only the part after the @ | The object holding companies |
#Choosing the attribute
Once the record type is chosen, the app lists the attributes that could hold the value, labelled "Attribute holding the email address" or "Attribute holding the domain". Where Attio enforces an attribute as unique, the screen says so, which is a good sign you have picked the right one.
Domains are compared sensibly. Attio compares the registrable domain, so a reporter at mail.acme.co.uk still finds a company stored as acme.co.uk.
#Domains the project ignores
Matching a company by domain only makes sense for addresses that belong to a company. The app ships with a list of around 165 free-mail domains that are never looked up, because a reporter on one of those is not a customer at that domain. You can add your own domains to ignore, and you can force a domain to always be matched.
#A few things worth knowing
Switching between matching the person and matching their company clears the record type, the attribute, the fields and the rest of setup, because none of it belongs to the new choice.
A text attribute is compared whole, so it only matches a record whose text is exactly the reporter's domain. Attio's own domain attribute type is the more forgiving choice.
A reporter with no email address on their Jira account cannot be matched at all, and the card says so without ever naming them.
#Related
An address in, a record out.
