Most changes to a chat widget are cosmetic and reversible. Switching which version of the embedded chat experience your account runs is neither, and there is a dedicated screen for going backwards: a rollback page that returns the workspace to the Classic UI.
It is a deliberately plain screen with one outcome, and it is worth knowing what it touches before you use it.
What saving actually does
Three things happen together when you save:
- The account is switched to the Classic chat UI version. This is an account-level setting, not a per-page or per-department one.
- The in-page template is normalised for classic compatibility. The embedded chat markup differs between versions, and a template written for the newer renderer will not behave correctly under the classic one, so it is adjusted rather than left to break.
- The cached version lookups are cleared, so the next page load serves the classic runtime instead of continuing to serve the newer one from cache.
That third step is the one people forget to expect, and it is the reason the change appears quickly rather than at some unpredictable point later.
The screen only goes one way
This page rolls back. It has no setting for the direction, no dropdown, and no way to move forward to the newer experience — saving it always means Classic. The comparison it shows you, current path against target path, is explanatory text rather than a choice.
There is a Back to Modern UI button in the footer, and it is worth being precise about what it does: it navigates you to the modern layout screen. It does not save anything and it does not undo a rollback. If you have already saved the rollback, going forward again is done from the other screen, on its own terms.
So the change is reversible — this is not a one-way door in the dangerous sense — but it is reversible somewhere else, not with an undo button here.
The confirmation checkbox is a real gate
There is a checkbox you must tick before the rollback will apply, and it is enforced where it matters — on the server. Save without ticking it and the request is rejected with a message asking you to select the checkbox; nothing is changed.
Worth knowing precisely how it behaves, because it is not quite the usual pattern: the Switch to Classic UI button is clickable whether or not the box is ticked. It is disabled only for the moment before the page finishes loading, and is then enabled regardless of the checkbox state. So an unticked click is not prevented, it is refused — you press the button, the request goes to the server, and you get the message back. The outcome is safe either way, but do not read an enabled button as confirmation that you have ticked the box.
When the save does succeed with the box ticked, the screen does not stay put: you are taken on to the advanced settings screen. That is expected rather than a glitch, but it does mean the rollback page is not where you land to verify the result.
It does not tell you where you are now
The most important limitation. The rollback screen does not display which version your account is currently on. It loads with nothing pre-filled, shows the same fixed comparison to everybody, and offers the same button whether you are already on Classic or not.
So do not use this page to answer the question what are we running? — it cannot. Establish that first, from the version your account actually serves, and only then decide whether a rollback is the thing you want. Saving a rollback on an account that is already Classic is harmless and simply changes nothing, but it also tells you nothing.
What a rollback does not touch
It is worth being equally clear about the blast radius, because the word rollback sounds more alarming than this action is. Saving it changes the UI version, the in-page template and the cached version lookups. That is the whole list.
Your chat history and transcripts are untouched. Your agents, departments and routing are untouched. Your canned responses, tags, knowledge sources and everything else you have configured are untouched. Nothing is deleted, and no conversation data is affected in either direction. What changes is which interface visitors are served and the markup it is rendered with.
What does change is the surfaces that only exist in the newer interface. The classic widget has no messenger home screen, so anything you configured there — the announcement card and quick links in particular — simply has nowhere to appear afterwards. The settings are kept, not deleted, and they come back if you are moved forward again; they are just invisible in the meantime. Worth knowing before somebody reports the announcement as missing.
The one thing to protect is a hand-customised in-page template, because that is rewritten to suit the classic renderer. If somebody on your team wrote that template, keep a copy of it outside the product before you save, and do the same before switching forward again later.
What to check before you save
A rollback is usually the right call when the newer experience is genuinely causing a problem you can describe — a layout conflict with the host page, a customisation that no longer applies, an integration written against the older markup. It is the wrong call as a reflex when something looks off, because the classic experience is the older one and you give up the newer renderer's improvements along with the problem.
Worth confirming first:
- Can you describe the fault? If the answer is that something feels different rather than something is broken, a rollback trades a real capability for a familiar appearance.
- Is it actually the version, or is it your own page? Host-page styling is a far more common cause of a widget looking wrong than the runtime is. It is worth ruling out before making an account-level change.
- Have you got a customised in-page template? It will be normalised on save. If it holds work you care about, keep a copy of it somewhere outside the product first.
- Does anything you have built read the newer markup? Custom CSS and scripts that target the embedded chat may need adjusting in both directions.
- Is now a quiet moment? This applies to the whole workspace and to every visitor, so make the change when a mistake is cheap rather than during your busiest hour.
Immediately afterwards
Load a real page on your real site in a fresh browser session, rather than trusting a preview, and open the chat exactly as a visitor would. Check that it opens, that a message sends and arrives in the console, and that the widget still sits where it should against your own page styling — the layout is the thing most likely to differ.
Then tell whoever is on shift. A support team that discovers the chat interface changed shape mid-conversation, with no warning, will report it as an outage, and that is a costly way to find out a colleague changed a setting. The same courtesy applies going the other way, and the general habit is covered in testing changes to your live chat.
The rollback screen sits with the rest of the configuration screens in your dashboard.