Recent chats, Flows, and Settings

The three sheets in the chat panel's header, what your visitors see behind them, and what you have to write before shipping them.

The chat panel's header carries two controls on the left, Recent chats and Flows, and a Settings gear on the right. Each opens a sheet covering the whole panel, header included. The two on the left slide in from the left and the one on the right slides in from the right, so a sheet always appears to come out of the control that opened it. A Back control returns to the previous view; a separate Close control closes the sheet outright. Tapping the dimmed area behind it does the same as Close.

Recent chats and Flows are worth understanding before you ship, because one of them turns text you wrote for yourself into text your customers read.

Recent chats

A visitor's own past conversations, the last 20 from the last 30 days, newest first. Tapping one reopens it: the messages come back into the panel, scrolled to the latest message, and the visitor carries on from where they left off. New chat sits pinned at the bottom of the drawer, below the scrolling list, so it stays reachable no matter how long the list is.

The conversation the visitor has open is listed too, highlighted as the selected row. Tapping it closes the drawer and returns them to it.

Images a visitor sent earlier come back as a note saying how many there were, not as pictures. That is what the panel does for the turn happening right now too, so a reopened conversation reads exactly like a live one.

Each row is titled by what the visitor asked, truncated. ARCY never generates a title for a conversation: it would be an AI call you pay for, on text your visitor reads once. A conversation that opened with an image and no words is titled by its date instead.

Whose history is it

The list is scoped to the browser, through the anonymous id ARCY stores there, and never to the user id your app passes to identify().

This is a deliberate security decision rather than a storage convenience. Identity verification is optional, so on an install without it anyone could open a console on your own site and call identify() with someone else's id. If history were keyed on that, the next thing they would see is another person's transcripts, on your domain, in your widget.

Two consequences to plan around:

A visitor who signs in on their phone does not see the conversations they had on their laptop. Cross-device history is coming, and it will require identity verification.
A visitor who clears their browser storage starts empty. That is the same trade every cookie-less product makes.

There is nothing to configure. The drawer is always there.

Flows

Every flow you have exposed as an agent resource, with its name and its summary, one tap to run. Each row carries the same flow mark you see beside Flows in the dashboard sidebar, so a row reads as something runnable rather than as text.

Before this existed, a flow reached an end user only when the agent happened to propose one in conversation. An operator who had authored eight flows had no surface that showed them. This is that surface.

Three things to know

The control does not render at all when you have exposed nothing. Your visitors never open an empty drawer, and you do not have to hide anything.

Only the flows you exposed appear. It is the same switch that already decides whether the agent may offer a flow, so your internal flows stay internal. There is no second setting to keep in sync.

Tapping a flow runs it, with no confirmation step. A per-flow "ask before running" flag is coming; today, treat an exposed flow as one a visitor may start at any time.

Your flow names are end-user copy now

This is the change most likely to catch you out. A flow's name and summary used to be labels you wrote for yourself, in your own dashboard. They are now the text a customer reads before deciding whether to run something on their own account.

Go and read yours. "test flow 3" is fine in a builder and not fine in a product. Write the name as the thing it does ("Invite a teammate") and the summary as what will happen ("Adds someone to your workspace and sends them an email").

The summary is rendered with the visitor's own attributes, the same way the rest of the widget's text is, so Add someone to {{ user.company }} works.

A summary longer than one line is not lost. The row shows one line, and a visitor who hovers the row, or reaches it with the keyboard, reads the whole thing beside the sheet. Write the sentence that explains the flow rather than the fragment that fits.

Settings

Two controls: Language, where you have enabled more than one locale, and Dock to the corner.

Language

Visitors pick the language of the chat panel for themselves, from the languages you enabled on the Localization page. The row shows the language the panel is in right now; tapping it lists your enabled languages, each written in its own name (English, Türkçe), so a visitor looking for a language the panel is not currently speaking can still read the option they want.

The row only appears when you have enabled two or more locales. On a single-locale app there is nothing to choose between, so nothing renders. You do not have to hide it.

Picking a language changes everything the visitor sees and hears, not just the buttons: ARCY's own text, the greeting and placeholder you wrote, and the language the agent answers in all follow the choice. There is one language per session, not one for the interface and another for the content.

The visitor's choice wins over anything your app sends. ARCY resolves a visitor's language from five places, in this order:

What the visitor picked in this sheet
A locale_code attribute your app passed to identify()
contentLocale, passed to init()
The browser's own language
Your app's default language

Everything below the first line is a guess about the visitor, including the locale_code your app sends, which is your own record of what they once chose. The pick is the visitor telling ARCY directly, so it outranks all of it. If you want to move a visitor to a different language, do it in your product's own settings where they can see it happen.

The choice is remembered per browser, like docking, and never sent anywhere except back to ARCY as part of the next session. It survives reloads until the visitor changes it.

Dock to the corner

Pressing Dock to the corner shrinks the whole widget to a single round button in the bottom-right corner of the page. The bar across the bottom disappears. This is for the visitor who does not want an assistant in your product at all and does not want to keep dragging it out of their way.

That button is your welcome icon. The same upload, at the same size, as the mark on the welcome screen, so there is nothing extra to configure and nothing that can look different from what you already signed off on. Change either one in Customization and both follow. With no welcome icon uploaded it is ARCY's default mark on your brand colour.

Pressing that corner button brings the widget straight back and opens the chat, so nobody can get stuck. Nothing is lost while it is docked: their conversations are still in Recent chats when they return.

Three things to know:

The choice is remembered per browser. A visitor who docks ARCY finds it still docked on the next page and on their next visit. Asking them again on every navigation would be the irritation they docked it to avoid. It is stored in their own browser, like the widget's other per-browser state, and never sent anywhere.

It is their choice, not yours. There is no setting for this in the dashboard, and you cannot dock or undock a visitor's widget. If you want the widget smaller or further out of the way for everyone, that is Customization.

A running flow always undocks. The bar is a running flow's status surface and the only place its Stop control lives, so a flow can never run behind a corner button.

While a flow is running

The panel collapses and the bar becomes the flow's status surface: the flow's name, which step it is on, and a Stop control. Your visitor watches your own product being driven rather than reading about it behind a panel covering the thing that is moving.

If a step needs a value, the panel does not reopen. A compact question card appears just above the bar, with the flow's progress row and the composer both still visible, so the page the flow is working on stays in view. The question is the text the flow's author wrote, word for word. The card matches the field: a dropdown's options appear as tappable choices, a date or time field shows a picker, a checkbox asks Yes or No, and a password field shows a masked input whose value goes straight into the page and is never stored or sent anywhere. An answer that does not fit the field is refused with a short error and asked again, and while the question waits, answering it or pressing Stop are the only ways forward.

The flow keeps going across a page navigation, and when it finishes the bar shows a brief check mark before returning to normal.