HarkHarkDocs
Theme

Embedded and portal presentation

Present the customer surfaces inside the chat widget or as standalone portal pages, and choose which surfaces to expose.

The same portal surfaces can be presented two ways. Which you use depends on whether you want a lightweight in-page experience or a full destination.

Inside the widget

Set the chat widget's home mode to portal (or enable the individual portal modules on a support home) and the surfaces render inside the widget window. A visitor taps the launcher and can browse feedback, the roadmap, the changelog, and status, check their tickets, or start a chat, all without leaving the page they are on. This is the fastest way to give customers self-serve access, because it rides the embed you already installed.

The embedded home mode goes a step further and places the widget content inline within a page rather than in a floating window, for cases where you want the surfaces to sit directly in your site layout.

As standalone portal pages

The boards, roadmap, changelog, and help center are also reachable as their own pages at your workspace's public address, so you can link to them directly (for example, a "Roadmap" or "What's new" link in your site navigation). This suits customers who arrive looking for one surface specifically rather than through the chat launcher. These standalone pages go live only once an owner publishes your workspace's public site; until then they stay dark.

Choosing what to expose

You control which surfaces appear. On a widget support home, each portal module (tickets, feedback, roadmap, changelog, status) is enabled independently, so you can, for example, expose the roadmap and changelog publicly while keeping tickets to signed-in customers. Boards themselves carry their own visibility (public, private to authenticated customers, or internal to staff), which gives you a second layer of control over who sees what.

Recognized versus anonymous visitors

Public surfaces (feedback, roadmap, changelog, status) render for anyone. Personal surfaces (a customer's own tickets and previous conversations) require a recognized visitor: either a signed-in portal customer or a widget visitor identified through signed identity. When a visitor is recognized, personal state such as their votes, follows, and subscriptions layers onto the public surfaces too.