How long Attio changes take to appear
Somebody has changed something and the card has not caught up. The answer depends entirely on where the change was made: edits inside Attio wait out a cache, and edits inside the project's Attio settings do not wait at all.
Nothing is copied out of Attio on a schedule. There is no background sync, no queue and no timer: values are fetched when an agent opens a request and then kept warm for a while so the next reader costs nothing. Everything below follows from that one design choice.
#The short answer
What changed, and where | When it shows |
|---|---|
A value on a record, edited in Attio | Up to fifteen minutes |
An attribute renamed or added in Attio | Up to one hour |
The record type, the matching attribute, the fields, the linked-record settings, the picture settings, the matching mode or either domain list | The next time a request is opened |
The required permission on the Permissions tab | Immediately |
The list of restricted groups on the Permissions tab | Immediately |
A person added to, or removed from, one of those Jira groups | Up to fifteen minutes |
A person gaining or losing the required Jira permission | Up to fifteen minutes |
A placement switched on or off | Immediately |
Somebody's project administration, for the settings page itself | Immediately |
A record's picture, once a viewer has seen it | Held in that viewer's browser for an hour |
A name on the site-wide connections page | Up to twenty-four hours |
A new or removed connection, on the site-wide connections page | Up to about half a minute |
#The fifteen minute window
Once a request has been opened, the matched Attio record and the rows built from it are reused for fifteen minutes. That answer is shared: a second agent looking at another request from the same customer in the same project costs no call to Attio and no call to Jira at all. The cost of that is plain, and worth stating up front. An edit made in Attio can take up to fifteen minutes to show on a card, on every request for that customer.
The window is deliberate rather than incidental. Jira's app request quota is shared across every site that installs the app, and a card that reads from scratch on every view is not affordable at any real number of installations. Fifteen minutes also bounds how stale a CRM edit can look, which is the other half of the trade.
There is no refresh control on a working card A Try again control appears only when the card errored or was rate limited with nothing to show. A card that is displaying rows gives an agent no way to force a re-read, and it deliberately does not refresh when the window regains focus. An agent watching a colleague edit a value in Attio will keep seeing the old one until the window passes.
#The one hour window
The list of attributes for an Attio object is kept for an hour, per project, and the same applies to each linked object whose attributes are being shown. Labels on the card follow the attribute's current name in Attio without anybody visiting the settings page, but they follow it on this slower clock: renaming an attribute in Attio, or adding one, can take up to an hour to show up on the card and in the settings pickers.
#Settings changes never wait
The warm copy of a record is tied to the exact configuration it was built from, so changing that configuration discards it. Changing the record type, the matching attribute, whether reporters are matched as people or as companies, either domain list, the chosen fields, a linked-record title, the attributes nested under a link, whether a linked record is shown inline or on hover, the picture attribute or the row the picture sits beside all show through on the next view of a request.
The values shown beside the field list on the Fields tab are never cached at all, so an administrator watching a change take effect sees the configuration they saved a moment ago rather than the one it replaced.
#Permission answers, and the fifteen minute lag
Whether a viewer may see the card, and whether they can read the request, are remembered for fifteen minutes per person per request, and Jira group membership is remembered for fifteen minutes per person. Editing the audience in project settings applies at once; moving a person into or out of a group in Jira does not. The check that guards the settings screens themselves is never cached and is asked of Jira live on every action.
#Nothing degraded is ever kept
Only good answers are stored. A failure, a rate limit, or a permission Jira would not confirm is used for that one view and then discarded, so one bad minute upstream never turns into fifteen minutes of an empty card. Three answers are worth keeping: a matched record, a confirmed no-match, and a list of candidates.
A reset clears every cached record, object definition and permission answer the project owns, which is why a project that reconnects to a different Attio workspace cannot be served the previous workspace's data.
#A few things worth knowing
A label and its value are on different clocks. Rename an attribute in Attio and change its value in the same sitting, and the new value can appear on the card long before the new label does, because one waits fifteen minutes and the other waits an hour.
Adding somebody to a restricted Jira group does not let them see the card for up to fifteen minutes, even though editing the group list in project settings applies straight away. Two changes that feel like the same change behave differently.
Removing a person's access in Jira can leave the card visible to them for up to fifteen minutes, while removing their project administration locks them out of the settings page at once. If you are revoking access in a hurry, that gap is the one to plan around.
#Related
Fifteen minutes for Attio, an hour for its labels, and no wait at all for your own settings.
