Screenshare only works with the Popup Widget embed. The Inline Bar and Playground embeds do not offer it. A caller on a phone call has no browser to share either, so the feature is never offered on a SIP/PSTN call, whatever an agent’s settings say.
Turning it on
Screenshare is off everywhere by default. Two separate switches both have to be on before any caller is ever asked to share:1
The organization opts in
In the Dashboard, go to Customers → Resellers and Organizations, open the organization, and expand the Screenshare card above the agent list (next to PII Redaction). Turn on Allow Screenshare for this Organization. It is off by default.The same card holds the rest of the organization-wide policy: Allowed Surfaces (Browser, Window, Monitor), Sampling Interval (1–30 seconds, default 3), Retention (default Off), and Frame Budget per Call (1–600, default 60). Set them, then press Save Screenshare Settings.The frame budget is additionally capped by the reseller account’s own ceiling, which is 200 by default and has no screen of its own. Setting a per-call budget above that ceiling saves normally but calls still stop at the ceiling — so a budget of 600 under a default account yields 200 frames, not 600.
2
The agent is switched on
Each agent has its own Enable Screenshare toggle, in the Dashboard under [Agent] → Edit Agent in the Screenshare panel. Turning on the organization’s policy does not turn screenshare on for any agent by itself — it only makes the capability available for agents in that organization to opt into individually. That panel also shows the organization’s current policy read-only, with a pointer back to the Screenshare card on the organization’s Agents page, so you can see there why a call might still refuse.In Connect, the same per-agent switch appears on the agent editor as Allow Screenshare from Web Embedded Agent (LiveKit agents only), in the Screenshare row. Connect has no organization-level controls — the policy above is Dashboard-only — and while Screenshare is locked in Feature Administration the toggle is hidden there too, exactly as it is in the Dashboard.
A Partner or Reseller can lock Screenshare for an organization from Feature Administration. While it is locked, both the Screenshare card on the organization’s Agents page and the Screenshare panel on the agent editor disappear, the API refuses to turn screenshare on, and no call in that organization is offered a share — including calls to agents that already had it switched on. Nothing is cleared: each agent’s toggle and the organization’s policy stay stored, and screenshare resumes as soon as the lock is removed.
The agent’s model must be able to read images
Screenshare sends captured frames to the agent’s own language model, so the model has to be able to read images. Trying to turn screenshare on for an agent whose model can’t is refused at save time, with:Screenshare requires a model that can read images. Choose a different model, or turn screenshare off.The rule also runs in the other direction: switching an agent that already has screenshare on to a model that cannot read images is refused, rather than silently blinding it. Turn screenshare off first if that is what you want. The same check runs again, independently, at the start of every call. So even if an agent’s model were somehow changed after screenshare was turned on, that call simply never offers a share rather than silently behaving as if it worked — a caller is never asked to share their screen with an agent that cannot use it.
Every model in the catalogue currently supports this, each confirmed against the live provider endpoint rather than taken from a model’s documentation. The check exists for models added later, and for an agent left on a model this build does not recognise — either of which is refused rather than assumed to work.
Healthcare organizations
An organization flagged Healthcare cannot use Screenshare, and this is enforced before anything can be turned on rather than only at call time. Allow Screenshare for this Organization cannot be switched on for a Healthcare-flagged organization: the Dashboard disables the control, and a save is refused withScreenshare is not available for healthcare organizations.The same refusal applies to turning an individual agent’s toggle on, in the Dashboard, in Connect, and through the API. And the call-time check remains as a backstop: even if a toggle were somehow stored as on, no call belonging to a Healthcare-flagged organization ever starts a share.
What the caller sees
When the agent asks to see the caller’s screen, the widget shows a consent prompt naming the agent and listing which kinds of surfaces it may ask for — never more than the organization’s policy allows. The prompt offers Share and Not now, and expires on its own after 30 seconds, after which the agent carries on by voice. The caller then picks what to share, if anything, from their own browser’s built-in picker; nothing is captured until they explicitly agree. Consent is asked for again every time the agent wants a new share — agreeing once does not stand for the rest of the call. The caller can also start a share themselves, without being asked, using the screen-share button in the widget’s action bar. That skips the widget’s consent prompt — pressing the button is itself the agreement, and the browser’s own picker still stands between it and any capture — and produces the same share record, marked as started by the caller. While a share is running the widget shows a You are sharing your screen banner with a live thumbnail and a Stop button, and the collapsed launcher carries a badge. The agent can also end the share itself. Tab audio is never captured — only the picture. Once a share starts, the agent confirms it and briefly describes what it can see, so the caller can tell straight away whether it is looking at the right thing. The agent never drives the browser it’s shown. It only receives still frames — it cannot click, type, scroll, or submit anything inside the caller’s browser. The caller stays in control throughout and can stop a share at any point using their browser’s own sharing indicator, which every browser displays for as long as a capture is active.The surface list is a hint, not a restriction. Some browsers (Chrome) narrow their own screen-share picker to the surfaces the organization’s policy allows. Others ignore that hint entirely and show their full picker regardless — there is no browser API that lets a page restrict which surface its own picker offers. Whichever surface the caller actually picks, even one outside the policy, is what gets captured and recorded, so allowed surfaces should be read as guidance to the picker, never as an enforced restriction.
Browser support
A share can also be blocked by the page hosting the widget. If the widget is embedded inside another site’s cross-origin frame, or the host page sends a restrictive
Permissions-Policy, the browser refuses display capture for that page. In Chromium-based browsers (Chrome, Edge) the widget can detect this in advance and does not offer the control at all; in Firefox and Safari there is no way to ask ahead of time, so the control is offered and the browser’s capture prompt fails when it is used.Retention and viewing frames
The organization’s Screenshare policy sets how long captured frames are kept after a call, from a fixed set of choices: Off (no frames retained), 7, 30, 90, 180, or 365 days. Off is the default, and a Healthcare-flagged organization is always held to Off regardless of what the policy is set to, since a retained frame could contain PHI. When retention is on, frames captured during a call can be viewed in the Dashboard only: open the call in Call Logs, then the Screenshare card on the call’s details, and choose View frames. The links the card hands out are valid for 5 minutes — once they lapse, reopen the call to get fresh ones. Separately, once the retention period itself has passed the card reads “Frames expired.” and the frames are gone for good. Opening frames is subject to the same access controls as a transcript and is written to the same access audit trail. Connect shows the share record on a call — consent, surface, who initiated it, start and end times, and why it ended — but does not show the frames themselves.Frame content never reaches analytics, tracing, or logs. Only counts and event names leave the call path — the frames themselves live solely in the retained storage the policy controls, for as long as the retention setting keeps them.The call transcript records the share as
[Screenshare: …] event lines alongside the conversation — when consent was given, when the share started and ended, and why — never anything about what was on the screen.