Configure allowed domains and test on mobile
Allow the intended production hostnames and validate the Agent on narrow customer screens Follow a safe workflow, verify the customer-facing result, and isolate common problems.
Allow the intended production hostnames and validate the Agent on narrow customer screens This guide keeps the work focused on deployment domains and provides a repeatable path that a new Humind user can follow without changing unrelated configuration.
Deployment connects a configured Agent to a customer-facing sales channel. The installation method depends on the storefront, but every launch needs an allowed domain, a single valid embed, a visible entry point, and tests on the real site. Workspace testing remains useful, yet it cannot replace validation in the deployed environment.
Before you begin
Access: Company or deployment settings write access is required to change allowed domains.
- List the canonical production and required subdomains.
- Exclude temporary, private, and unrelated environments.
- Prepare a real mobile device or narrow browser viewport.
Work in the smallest owning area described below and keep the current customer-facing state available while you prepare the change. Before clicking any final action, confirm the active company, Agent, store, language, and market shown in Humind. A missing control can indicate read-only access or a capability that is not configured for this company. In that case, record the intended task and ask an administrator to review the exact permission or dependency. Do not bypass the boundary by sharing an account, copying data into another area, or promising a capability that the workspace does not expose.
Step-by-step workflow
Confirm the scope and current state
Open the domain settings for the active company and compare the primary and allowed domains with the storefront installation.
- Confirm the active company and Agent before editing.
- Record the current state so the result can be compared after the change.
- Stop if the screen or permission does not match the intended task.
Prepare the change
Add only exact supported hostnames needed by the deployment and preserve market-routing requirements where a shared domain is configured.
- Use the smallest change that completes the customer task.
- Keep authoritative information in its owning source.
- Review labels, dates, language, and customer-visible wording before saving.
Save and allow required processing to finish
Save the domain change, reload the live site in a fresh session, and confirm the embed is accepted without broad wildcard assumptions.
- Wait for the interface to confirm that the change is saved.
- If synchronization, indexing, or publication is required, wait for its final state.
- Reload the area and confirm the saved values persist.
Test the complete customer journey
Test launcher placement, opening, typing, product cards, scrolling, consent, support, and dismissal on a narrow screen and after page navigation.
- Use a fresh session and a realistic customer scenario.
- Check desktop and mobile when the result appears on a storefront.
- Capture the exact failing step if the outcome differs from the expectation.
Important limits and operating notes
- A successful save confirms persistence, not every downstream synchronization or public update.
- Workspace permissions can hide an area or allow reading without allowing changes.
- Do not copy volatile catalog, account, or customer facts into narrative content as a workaround.
- Test only supported capabilities that are visible and configured for the current company.
- Keep changes in deployment domains separate from unrelated Agent, Knowledge, catalog, Inbox, or Helpdesk work.
Verify the result
- The intended hostname is allowed and unrelated hosts remain excluded.
- The correct market and Agent load on the real domain.
- No important storefront control is covered on mobile.
- Conversation and support flows survive navigation and screen changes.
Keep a short record of what you tested, which customer scenario you used, and what changed. This makes later troubleshooting more precise and helps another teammate reproduce the result without relying on memory.
Troubleshooting
The Agent works locally but not on production
Compare the exact production hostname, deployed embed, consent and content-security behavior, and allowed-domain record. Local success cannot validate production routing.
The launcher blocks mobile controls
Use the supported entry-point placement and test common viewport widths. Avoid storefront CSS overrides that make the embed inaccessible or fragile.