Inkpilots

Domains and Public Workspace

Workspace

Domains and Display Windows(your visitor facing content) settings determine how Inkpilots appears outside the dashboard. This is the delivery layer where an internal workspace becomes a public destination with its own address, visibility rules, and presentation quality.

This page explains how the current domain and Display Windows(your visitor facing content) features work in practice, including visibility, slug identity, verification states, and what the team should confirm before pointing real traffic to the workspace.

What the Display Windows(your visitor facing content) represents

The Display Windows(your visitor facing content) is the external face of your content system. It should be treated as:

  • the public destination for published workspace content,
  • the branded surface visitors actually see,
  • the place where your internal editorial work becomes externally legible.

This matters because the dashboard and the Display Windows(your visitor facing content) serve different purposes. The dashboard is for operating the system. The Display Windows(your visitor facing content) is for exposing the result.

What users manage in this area

The current product gives workspace users control over the core elements that determine public delivery:

  • workspace name,
  • workspace slug,
  • public visibility,
  • custom domains,
  • domain verification details,
  • public presentation settings managed in adjacent tabs.

Together, these settings determine whether a workspace is discoverable, trustworthy, and ready to be shown externally.

Workspace slug and visibility

Before custom domains are involved, a workspace already has a public identity through its slug and visibility settings.

The general workspace settings currently support:

  • updating the workspace name,
  • editing the workspace slug,
  • checking slug availability,
  • controlling visibility,
  • selecting workspace language and other general operating options.

The slug is especially important because it forms part of the workspace’s public identity. It should be stable, readable, and aligned with how the workspace is meant to appear externally.

What custom domains do

Custom domains give the Display Windows(your visitor facing content) a dedicated branded address. This is more than a cosmetic upgrade. It changes how the workspace is perceived and how confidently it can be used as a public destination.

Custom domains are most valuable when:

  • the workspace is client-facing,
  • the Display Windows(your visitor facing content) is part of a brand or campaign,
  • the team wants a stronger separation from default product-hosted identity,
  • trust and recognizability matter to the audience.

Domain management in the current product

The current domain manager supports:

  • adding a domain,
  • listing existing domains,
  • viewing verification status,
  • expanding a domain to inspect setup instructions,
  • deleting a domain,
  • surfacing misconfiguration details when setup is incomplete or incorrect.

This is important because domain management is an operational workflow, not a one-field setting. Users need to know whether the domain is live, pending, or misconfigured and what to do next.

Verification states you will see

Inkpilots currently exposes domain states such as:

  • verified,
  • pending,
  • failed,
  • misconfigured.

These states should be treated as operational signals.

Verified

The domain is correctly connected and ready to be used for the workspace.

Pending

The domain has been added, but the verification change has not completed yet. This usually means DNS propagation or setup work is still in progress.

Failed or misconfigured

The domain is not ready. The current UI can expose record details and configuration hints so the team can correct the issue instead of guessing.

What the setup details are for

For domains that are not yet verified, Inkpilots can show the practical verification details needed for completion, including:

  • record type,
  • record name,
  • record value,
  • setup instructions,
  • additional misconfiguration guidance when available.

This is the part teams should use when coordinating with whoever controls DNS. It turns the domain workflow into a repeatable checklist instead of a trial-and-error setup.

Recommended order of operations

The safest public rollout order is:

  1. Finalize the workspace slug and public identity.
  2. Confirm the workspace should actually be public.
  3. Shape the public presentation layer.
  4. Publish content worth showing.
  5. Add and verify the custom domain.
  6. Only then send real traffic to the workspace.

This order keeps external visibility downstream from content and presentation quality.

Good operating practice

Treat public visibility as a publishing decision

Making a workspace public should reflect actual readiness, not curiosity or convenience.

Use a stable slug

Frequent slug changes weaken continuity and can create confusion around the workspace identity.

Read domain status literally

Do not treat pending or misconfigured domains as “basically done.” Public delivery is only ready when the domain is verified.

Pair domain work with presentation work

A verified domain does not create trust on its own. Trust also depends on coherent messaging, design, and published content quality.

Common mistakes to avoid

  • Publishing a workspace before its public messaging is ready.
  • Treating custom domain setup as a branding step instead of a delivery workflow.
  • Ignoring misconfiguration details and assuming DNS will fix itself.
  • Sending external traffic to a workspace before verification is complete.

How this page connects to the rest of the handbook

Use this page together with:

Related guides