Not every capability in a workspace should be on for everybody the day it ships. Some change what agents see, some change numbers that people have been reporting on for months, and a few depend on configuration you may not have done yet.
Feature flags are how MyLiveChat handles that. Each flag is a named switch with a sensible system-wide default, and your site can override it. The model is small, but the third state is the part people miss.
A default, an override, and an effective value
Every flag has a system default that applies to all sites. Your site can set its own value on top of that, and the value that actually applies is called the effective value.
The override has three states, not two: on, off, and cleared. Clearing an override is different from setting it to off, because a cleared flag follows the system default from then on, including if that default later changes.
This is why the screen shows the default and the effective value side by side rather than one checkbox. If you only ever see the switch you cannot tell whether a flag is off because somebody turned it off, or off because it ships that way.
The practical rule: turn a flag off explicitly when you have decided you do not want it, and clear the override when you are undoing an experiment and want to go back to whatever the product considers sensible.
There is a notes field on each flag. It is the only record of why a switch was moved, and it costs a sentence. Write down who asked and when, because a flag flipped a year ago with no note is a flag nobody will dare touch.
Changes take about a minute
Flag values are cached for roughly a minute. A change is therefore not always visible the instant you make it, and the correct response to a flag that looks like it did nothing is to wait rather than to click again.
This matters most when you are testing. Flip, wait, reload the surface you expect to change, and only then conclude anything.
There is also a graceful fallback: if the storage behind the overrides is unavailable, everything falls back to system defaults rather than failing. That is the right behaviour, but it does mean a workspace can briefly behave as though your overrides were never set.
What the flags actually control
The set is deliberately small and each flag maps to something visible. Voice and video call icons in the widget and console are separate flags, so you can offer one without the other. Two ticket flags control the bulk-action toolbar on the ticket list and the merge button on ticket detail.
On the AI side, semantic search across help articles and reply suggestions for agents are each their own flag. Both ship off, because both call an AI provider and that is a cost and a policy decision rather than a default.
The rest cluster around tickets and follow-up: automatically issuing a satisfaction survey when a ticket is resolved, automatically tagging tickets that come back with a low score so they land in the normal triage queue, computing SLA timings from your business calendar instead of the wall clock, and minting a customer portal link when a ticket arrives with a requester email.
One flag controls whether token creation and revocation are emitted as outbound webhook events, which is how you get an audit trail of API access into a system of your own.
Why some ship on and others ship off
The defaults are not arbitrary, and reading them tells you what the risk of each flag is.
Things that only add a control to a screen tend to ship on, because the worst case is a button somebody ignores. Things that cost money on every use, such as the AI-backed flags, ship off, so nobody starts spending without choosing to.
The most interesting case is the business-calendar SLA flag, which ships off purely for continuity. Every existing team has been reading breach numbers computed against the wall clock, and turning calendar-aware timing on changes those numbers for everyone at once. That is a rollout decision, not a preference, and the surrounding detail is covered in the guide on business hours and holidays for ticket SLAs.
The portal-token flag ships off for a different reason again: it depends on setup that not every workspace has done. A flag whose feature is not configured yet is a flag that produces errors, not value.
Rolling one out without surprising anybody
Treat a flag change as a release. Decide what you expect to change, tell the people who will see it, flip it at a quiet hour, and check the surface it affects rather than assuming.
Flags that change agent-facing screens are best flipped between shifts, and mentioned at handover. Flags that change reported numbers need more warning than that, because the first person to notice will otherwise report it as a data bug, and you will spend an afternoon proving it is not.
Where a flag depends on configuration, do the configuration first and verify it in isolation. Calendar-aware SLAs with an empty calendar, or portal links with no email automation waiting for them, are both worse than the default they replaced.
Change one flag at a time. Two at once and an unexpected result tells you nothing about which one caused it.
When to leave them alone
Most workspaces should touch very few of these. If a capability is on and nobody has complained, that is a working system, and turning it off to tidy the screen is a change with a downside and no upside.
Unknown keys are rejected rather than stored, so a typo cannot create a phantom flag that appears to be set. But nothing stops a real flag being set for a reason that has since evaporated, which is what the notes field is guarding against.
Review the list occasionally rather than continuously. Once a quarter, read the overrides, check each still has a reason, and clear the ones that do not so the site drifts back toward the defaults the product maintains for you. The wider habit this belongs to is covered in the admin and account settings that surround it.
What to measure
For any flag that changes a number, capture the metric before you flip it. Calendar-aware SLA timing in particular will move your breach rate, and without a before figure you cannot tell an improvement from an artefact of the change.
For agent-facing flags, the measure is adoption. If the bulk toolbar has been on for a month and nobody uses it, the flag is not the problem and turning it off changes nothing that matters.
For the AI-backed flags, watch cost alongside use from the first day, because those are the two flags where leaving something on has a running price attached.
If a flag will not save at all, rather than saving and behaving unexpectedly, the cause may sit underneath the screen instead of in the flag: when your dashboard cannot reach your chat server walks through how to tell those apart.