Installation, identity and privacy
What should you check when installing a chat widget?
Install a chat widget using the product’s current embed snippet, configure the domains where it may run, and test the full conversation on the real site. Check desktop and mobile layouts, page navigation, security policy, and what happens after the visitor closes the tab.
Where should the embed go?
Use the installation instructions and site-specific public key from your support product. Load the script once per page or app shell. If a site builder provides a custom-code field, check whether it runs globally or only on one page, and avoid injecting a second copy during navigation.
Which security settings can block it?
An allowed-origin restriction or Content Security Policy may prevent the widget from loading or connecting. Inspect the browser console and network requests before disabling unrelated protections. A public widget key identifies the site; it should not be treated as authority to read private customer accounts.
How do you test beyond the first page?
Navigate through the pages where customers need help, including any single-page app transitions. Check that the launcher does not cover checkout or mobile navigation. Send a message, attach a supported file, and test a response after the visitor disconnects.
Practical checklist
- Use the current snippet and correct site key.
- Allow only the intended website origins.
- Test desktop, mobile and client-side navigation.
- Complete a chat and an offline email round trip.
Worked example
A widget works on a preview hostname but not the live domain. Before changing the script, compare the allowed origins and console errors. Then test the production page template, since preview-only success does not establish that every published page loads the embed.
How Fire Away fits
Fire Away provides a dependency-free script with a shadow-root interface and allowed-origin controls. The install page contains the embed approach; configure the actual site key for your workspace.