The card is showing a value that is out of date
Nothing is copied out of Attio on a schedule. There is no background job and no timer: every value on the card is fetched when somebody opens a request, and then kept warm so the next reader costs nothing. That is the whole design, and the price of it is a wait after an edit.
It is worth saying plainly: an edit made in Attio can take up to fifteen minutes to appear on a card, and an agent cannot force it sooner.
#How long each thing is kept
What | How long | Shared with |
|---|---|---|
A matched record and the rows built from it | Fifteen minutes | Everyone in that project looking at requests from the same customer |
A confirmed no-match, and a candidate list | Fifteen minutes | The same |
An object's attribute list, which is where field labels come from | One hour | The project |
Whether a viewer may see the card, and their Jira group membership | Fifteen minutes | That person |
A record's picture | One hour | The viewer's browser |
The values beside the field picker in settings | Never cached | Nobody |
Only good answers are kept. A failure, a rate limit, or a permission Jira would not confirm is used once for that view and then discarded, so one bad minute upstream never becomes fifteen minutes of an empty card.
#There is no refresh control on a working card
A "Try again" control appears in two places only: when the card is rate limited with nothing to show, and when it has errored. A card showing rows, a no-match or a candidate list has no way for an agent to force a re-read. Moving between the issue's tabs does not cost another lookup, and the card deliberately does not reload when the agent switches back to the browser window.
One warm answer per customer, not per agent. In company mode the lookup is keyed on the domain, so every reporter at the same customer shares one answer. A second agent opening a different request from the same company sees the same values, including the stale ones, rather than triggering a fresh read.
#A settings change is not subject to the wait
The warm answer is tied to the exact configuration it was built from, so an administrator never has to wait out the fifteen minutes to see their own edit. Changing any of these shows through on the next view of a request:
The record type, or the attribute reporters are matched on.
Whether the project matches the person or their company.
The ignored-domain list or the always-match list.
The fields on the card and their order.
A linked record's title, the attributes nested under a link, and whether it is shown inline or on hover.
The nominated picture attribute and the row the picture sits beside.
#Renaming an attribute in Attio is the slow one
Field labels on the card follow the attribute's live name in Attio, so a rename shows up without anybody revisiting the settings page. It comes from the object's attribute list, though, which is kept for an hour rather than fifteen minutes, so that is how long a rename or a newly added attribute can take to appear on the card and in the settings pickers.
#A few things worth knowing
Reloading the issue does not help inside the window. The answer is held in the issue view as well, so the reader gets the same values back.
Moving somebody into a Jira group does not let them see the card straight away, because group membership is remembered for fifteen minutes per person. Editing the group list in settings does take effect at once.
The preview beside the field picker in settings is always a fresh lookup, so it can show a value the card on a live request will not show for another quarter of an hour.
#Related
Fifteen minutes, shared. There is no button for it.
