Every setting, its tab, its default and who may change it

The addon owns 46 settings keys. Settings explains the ones you will actually want to change and why; this page is the whole list, in the order the screen puts them, so that "set aiSupportRetrievalFloor" turns into a tab and a control rather than a search.

The screen is /admin/ai/support/settings and needs access.ai.support.settings.

The five tabs

The tab id is what appears in a field definition and in a URL fragment; the label is what is printed on the rail. Two of them differ, which is the usual reason an instruction naming a tab sends somebody to the wrong one.

Tab order is the order you do it in, not alphabetical. Guardrails is first because nothing else on the screen has any observable effect until the assistant is switched on and has a budget.

Guardrails

Every control on this tab is a Super-Admin key, and the tab is hand-built rather than generated — the shared settings form has no protected-key concept, so a protected key rendered as an ordinary field would be a live control that rejects the save.

Those twelve are the complete Super-Admin list. Everything below this section is writable by any role holding access.ai.support.settings.

The last three are a different product from the nine above them. Those decide what an automated system says to your customers; these decide whether the admin surface is described to a model at all, and then whether it may offer a platform-wide write. Every catalogue behind them is filtered by the asking administrator's own permissions, so the assistant can never reach something the console would refuse — but that is a floor, not a reason to leave them off this list.

Channels

aiSupportOfficeHours and aiSupportOfficeHoursTimezone are the only two keys on the whole screen that are validated at write time. A schedule nothing can parse is rejected with an example rather than saved, and a schedule that is closed on every day is rejected too; a timezone the server's Intl does not recognise is rejected rather than silently becoming UTC and shifting every hour you told your customers. The read path deliberately fails silently, so this save is the only moment there is a person present to be told.

The Preview control under aiSupportProactiveEnabled is not a setting — see below, and Proactive support for what it shows.

Retrieval

Read top to bottom, this tab is the pipeline in order: which corpus is in scope, how a question is searched against it, what has to be true before an answer goes out, and the one thing that runs before any of it. aiSupportDeflectEnabled is last because it happens first and costs nothing — it is a search, not a model call.

Model

What ships is a tier, not a model id. These three used to default to named vendor models, which meant every install rendered a supplier's model id on the screen an operator opens most — the disclosure the tier vocabulary exists to prevent. A tier is also the more honest value: which model serves mashdiv-core is a routing decision made on the gateway, so an install asserting a specific model is claiming knowledge it does not have and pinning a choice that stops being current the moment routing changes. Nothing is lost on the self-managed path — an operator who brings their own key and names a specific model still gets exactly that model, and the mapping only catches the tier names.

On a gateway install the three values are additionally masked at the API boundary, not merely hidden by the form: the GET rewrites them to the tier name before the response leaves the server, because showIf is render-only and a raw value was otherwise readable from the network tab.

One discrepancy worth knowing about: on an install that has never saved this tab, the form seeds the three fields from its own copy of the defaults, and that copy is still the old bring-your-own-key one. It is a placeholder in an unsaved form, not a stored row — the engine reads the tiers above until you save something — but if the field disagrees with this table on a fresh install, that is why.

aiSupportEffort is shown on every install including the gateway — the gateway reads it per call. It is the cheapest lever on the screen, because thinking tokens are billed and are counted against aiSupportMaxTokens.

Data

aiSupportShareQuestionsEnabled is the only control on the whole screen that sends anything outside the install, which is why it has its own heading on the tab an operator opens when somebody asks what this feature transmits.

Four keys that are not on this screen

The two walkthrough keys are deliberately on the Actions console rather than here — they belong beside the catalogue they narrow, and unlike the three capability switches they are not Super-Admin gated, because a walkthrough cannot write.

The last two are a genuine gap rather than a design decision. Both are real and both are read on every turn, but no control in the product renders either one — they appear in no field definition, in no hand-built tab, and nowhere else in the admin app. The only ways to change them are the PUT at the top of this page, with a body such as {"settings":{"aiSupportDirectAnswerEnabled":"true"}}, or a row written straight into the settings table. Any instruction to "switch direct answers on" from the Settings screen is describing a control that does not exist.

aiSupportDirectAnswerEnabled is the largest cost lever the addon has when your article coverage is good, which is what makes the missing control worth naming rather than filing under polish.

aiSupportProactivePreview looks like a key on the Channels tab and is not one. It is a custom component with a field slot, so it can sit inline under the switch it demonstrates; nothing is ever written under that name.

Values are TEXT, and that is not a detail

The settings table stores value as LONGTEXT. Everything the admin form writes is String()-coerced on the way in, so a boolean arrives as the four characters false — and Boolean("false") is true.

Every boolean in this addon therefore goes through one coercion helper, which accepts exactly:

true   1   yes   on

trimmed and lower-cased, so TRUE with a trailing space is on. Anything else is false: enabled, y, -1, and an empty string.

Enums degrade to the safe value rather than to whatever was typed, which means a typo can never enable something:

Text keys degrade the other way. Seven of them are read with || rather than ??, so an empty value is discarded and the shipped default comes back: aiSupportModel, aiSupportRerankModel, aiSupportClassifierModel, aiSupportGatewayUrl, aiSupportGreeting, aiSupportOfficeHoursTimezone (back to UTC) and aiSupportOfflineNotice. Clearing one of those fields is not "set it to nothing" — an operator who empties the greeting to stop it being sent gets the shipped greeting back on the next read, with the field still showing empty in an unsaved form. The way to silence the greeting is aiSupportGreetingEnabled = false.

aiSupportOfficeHours is the deliberate exception: it is read with ??, because "no schedule" is a real answer there and restoring a nine-to-five underneath an operator would be a promise the product invented.

Numbers are clamped to a range. A value that does not parse as a number at all — enabled, abc, true — falls back to the shipped default. An empty value is not that case: Number("") is 0, which is a perfectly finite number, so an emptied numeric setting is 0 clamped to the key's minimum.

The four list keys are bounded too: aiSupportQuickReplies keeps the first six entries at 80 characters each, aiSupportWorkflowKeys and aiSupportAdminActionKeys the first forty at 64, and aiSupportGuideKeys the first sixty-four at 64. Lists are read as JSON when the stored text starts with [, and as newline-separated otherwise, so a hand-written row does not silently vanish.

Empty means different things on three of them, and the difference is deliberate: empty is none for aiSupportWorkflowKeys and aiSupportAdminActionKeys, because both gate something that writes and a catalogue that grows in an upgrade must not grant a capability nobody agreed to; empty is all for aiSupportGuideKeys, because a walkthrough writes nothing and a new one is a new explanation of a page you already ship.

A change is not instant everywhere

Two caches sit in front of these rows, and they behave differently. A change made through the PUT clears both: the addon's snapshot, the install profile and the route catalogue go first, then CacheManager.clearCache() empties the platform Map, reloads it from the database and announces the invalidation to every other process — by broadcast where one can be heard, and by a version stamp written into the settings table where it cannot.

A row changed outside the PUT — a direct database write, a migration, a script — is a different story on each side:

So "expect it within ten seconds" is true of AI Support behaviour and false of everything else. If you have edited a row by hand, re-save it from the screen — that is what bumps the version stamp and converges every process — or restart the backend.

Never put a credential here

That is also why no field on the settings screen is a password box. If you find yourself wanting one, the answer is an environment variable — see Install.