Saving changes to Attio settings
The settings page holds six tabs' worth of configuration and one save bar, and it does not behave the way a form usually does. Two things write the moment you touch them, everything else waits, and any successful save quietly replaces whatever is still unsaved elsewhere on the page.
None of that is dangerous once you know it. It is the source of nearly every "I changed that and it went back" report when you do not.
#The save bar
Edits sit in the page until you press Save changes. When something is pending, a bar appears at the foot of the window naming which areas changed, for example "Unsaved changes to fields." or "Unsaved changes to fields, permissions and placement.", with Discard and Save changes beside it. The bar sticks to the bottom of the window so it can be reached from anywhere in a long tab, and a small indicator near the heading reads "Saving", "Saved" or "Not saved".
The areas the bar can name are: record type, matching, ignored domains, always-match domains, fields, linked record fields, linked record titles, record pictures, permissions and placement.
A save carries only the settings that actually changed. It cannot overwrite a part of the configuration you did not touch, and two administrators working on different tabs collide only on what they each edited.
#The two things that do not wait
What | When it is written | How you trigger it |
|---|---|---|
The API key | Tested against Attio first, then stored if Attio accepts it | "Test and save this key" on the Connection tab, or Enter in the key field |
The placements | Immediately, on the toggle | Any placement switch on the Placement tab |
Everything else | On Save changes | The save bar at the foot of the page |
The Placement tab says so in its own description: "Where on the issue the card appears. Changes here take effect immediately." That is deliberate, because the placements are what switch the card on and off for everybody in the project.
Toggling a placement discards unsaved edits on other tabs A placement toggle writes straight away and then reloads the whole configuration from the server, which replaces anything still sitting unsaved on the other tabs. Save your work before you touch a placement.
Typing a test address on the Fields tab commits your pending changes The values beside the field list are looked up on the server against the stored configuration, so the page writes whatever is unsaved before it runs the lookup. Typing a test address therefore saves your pending edits even though the Save changes bar is still on screen. If that write fails, no lookup is made and the failure is reported rather than values being shown for settings you had already replaced.
#While a key is half-typed, everything else is held
As soon as there is text in the API key box, the save bar disappears and edits on the other tabs are held. The Connection tab explains it: "Changes on the other tabs are held until this key is tested and saved, or until you clear the field." It is what stops an untested key being stored as a side effect of saving something unrelated. Cancel empties the box and lets the rest of the page save normally again.
"Test and save this key" is unavailable until something has been typed. Leaving the field empty keeps the key the project already has, and the field always starts empty because the stored key is never sent back to the browser. A key that fails the test is never stored, so a bad paste cannot cost you a working connection.
#Saved, but the card is not switched on yet
Occasionally the settings store correctly and Jira refuses the small project update that makes the card appear. The page says so under that heading rather than leaving you looking at finished setup and an empty issue view:
"Your settings are stored. Jira would not let this app update the project, which is what makes the card appear on issues. A Jira site administrator may need to approve this app's new permissions in Admin Hub. Choose a placement again once they have."
This is not a failed save. The configuration is stored; the card is waiting on approval, and choosing a placement again is what publishes it once approval has happened.
#When a save genuinely fails
A failed save shows "That change could not be saved" with the reason and a Try again button, and your edits stay on screen so nothing is lost. During first-time setup the same failure appears as a red line in the wizard footer and the step does not advance.
#A few things worth knowing
Every successful save re-reads the whole configuration from the server and rebuilds the editing copy from it. That single behaviour is what makes a placement toggle, a key save and a Fields-tab lookup all capable of clearing unsaved work elsewhere on the page.
The save bar vanishing while you are typing a key looks exactly like a save. It is not one. Those edits are held, and clearing the key field brings the bar back with them still pending.
The green panel after a successful key test says the key is stored slightly before the write happens. If the write then fails you can be looking at the success panel and "That change could not be saved" at the same time, and the second one is the true answer.
#Related
Two settings write themselves. Everything else waits to be asked.
