What Attio for Jira does not do

The quickest way to judge an integration is to read what it refuses to do. This page is the refusals, stated before you find them, because a limit discovered during a pilot costs more than a limit read in advance.

None of what follows is a gap waiting to be filled in a later release. Each one is a decision with a reason, and the reasons are given.

#It does not write to your CRM

Every call to Attio is a read. The app identifies its key, lists the objects in your workspace, reads the attributes of the chosen object, searches for a matching record, and looks up the records that one links to. There is nothing in it that creates, edits or deletes anything in Attio, and it holds no write permission there at all. Resetting a project changes nothing in Attio either.

#It does not write to your issues

No comment, no field, no label, no issue update. The single thing the app writes in Jira is a small non-secret flag on the project recording whether setup is finished and which placements were chosen, and it holds nothing about the CRM: no workspace name, no record type, no hint about what the connection is to. That is deliberate, because anything stored on a project can be read by anyone who can browse it.

#It does not copy your CRM into Jira

Nothing is copied out of Attio on a schedule. There is no background job, no queue and no nightly sync. Every value is fetched when somebody opens a request and then reused for fifteen minutes, which means there is no store of customer data in Jira to worry about, and also that the card is only as current as that window.

#It is not a customer-facing feature

None of the three placements offers unlicensed access, so anonymous and unlicensed viewers see nothing, and nobody reaching a request through the customer portal ever sees the card. The Permissions step narrows the audience within the agents on a project; it cannot widen it beyond them, whichever of the four options is chosen.

#It does not hide fields from individual people

The Permissions step says it in the app's own words: "Everyone who passes this gate sees every attribute you chose on the previous step. Nothing on the card is hidden per person." The decision about what is safe to show is made once, in the field list, for everyone who passes the gate.

#Other things people expect and do not get

What people look for	What happens instead
A refresh button on the card	"Try again" is offered in two states only: an error, and a rate limit with nothing on screen. A card showing rows has no manual refresh and is reused for fifteen minutes.
A line saying how current the values are	The card carries no "last updated" line and does not name the Attio workspace, even though the app knows both. It is the chosen attributes and one "Open in Attio" control.
Picking the right customer from the card when several match	The card lists up to three candidates with a link to open each in Attio, and no way to choose one. It is telling you to go and disambiguate in the CRM.
A second attempt when the first lookup finds nothing	Exactly one lookup runs. Matching the person and matching their company never fall back to each other, so the card always answers the question the project asked.
Attributes of a record linked from a linked record	Linked records nest one level only. An attribute of a linked record that is itself a link to a third record is left out of the card.
A full preview of the card during setup	Previewing is real values shown beside each attribute in the field list, with the linked-record card and the customer's picture in that value column. Neither setup screen renders a complete copy of the card.
Searching or filtering a long attribute list	The Fields step splits attributes into "On the card" and "Everything else" and is otherwise a plain list in Attio's own order. An object with many attributes has to be scrolled.

#It does not tell an agent why a lookup came back empty

When a project matches companies, there are four ways to end up with nothing: the address had no usable domain, the domain is one the project ignores, no record holds it, or too many records share it. All four read the same on the card: "No Attio record matches this reporter." An agent cannot tell a reporter writing from a personal address from a customer genuinely missing from Attio, and neither can an administrator looking at the same issue.

Rate-limit wording always names Attio. The card's rate-limited copy is fixed and says Attio is rate limiting the app. When the slowdown actually came from Jira, the reader is still told it was Attio. Treat that sentence as "something upstream asked us to slow down" rather than as a diagnosis of which system did.

#It does not print the reporter's address

No state on the card ever shows the reporter's email address, the data the browser receives does not contain it, and a record with no name is never titled by its address either. Every sentence says "this reporter". The same rule applies to the domain: none of the messages about a domain that could not be matched names the domain, because a reporter's email domain identifies their employer.

#A few things worth knowing

The four-or-more rule behaves differently in the two match methods. Matching companies, four or more records shows nothing at all; matching people, four or more still lists three candidates.
Free-mail domains are ignored as a courtesy, not as the safety rule. The list can never be complete, and an ordinary business domain can fan out to many records too, so the real protection is refusing a domain that matches too much.
Attributes the app does not recognise render as an empty row rather than as raw data. If Attio introduces a new kind of attribute, a card built on it shows the label with nothing under it, which reads exactly like an empty field.