Support/Getting Started/Current features and setup requirements

Getting Started

Current features and setup requirements

Find the current page designer, record scope, AI, API, integrations and diagnostics guidance, and check what your app has enabled.

Open raw .md
Guide updated
22 October 2026
Audience
Builders and app users
Availability
App configuration and permissions apply

BuildWithHQ combines a page designer, connected business records and governed automation for SaaS products. Your published app, entitlements, permissions and configured services determine which capabilities you can use. A feature described here or a visible control does not establish that a provider, model server or worker is running.

Design and publish pages

Compose registered React components in the Puck page designer. Configure themes, custom CSS, assets, menus and User Types, save drafts, preview the result and publish the intended version. User Types select homepages, layouts and menus. Record authority still comes from the signed-in user’s Personal ownership, DataRoles, Locations and action permissions. A page being absent from a menu does not by itself deny access to an entitled published page.

Choose record visibility explicitly

For every new top-level business record, choose Personal or one eligible DataRole. When shared records require a location, choose an authorized location or All if you have all-location access. Leaving a selection blank is not All. Child records inherit the parent’s scope. Read Record visibility: Personal, DataRoles and Locations before creating or moving shared data.

Use the modules enabled in your app

Connected modules include contacts, organizations, tasks, checklists, work orders, conversations, files and knowledge. Open the native module for the allowed create, view, edit and removal actions. Some removals archive, cancel or deactivate a record to preserve its history. Search, dashboards and activity projections lead back to that native record rather than duplicating its lifecycle. The module inventory describes individual surfaces and boundaries.

Keep Inbox and AI actions governed

Universal Inbox collects attention while conversations, submissions and business records remain their source records. Refresh an item that has changed before approving a suggested action. GoClaw planning and research are read-only; material changes require the configured approval policy and action permission, and execution must use the approved current context. A suggestion, an approval and a queued execution are distinct states.

AI search and Knowledge Core apply the current user’s record, field, DataRole, location and AI-read permissions before assembling model context. Multimodal retrieval can preserve both text and visual evidence. Ingestion, serving and execution depend on configured and enabled services; contact your operator when the app reports a dependency is unavailable.

Connect a headless app, SDK or MCP client

Start with the generated OpenAPI reference and current versioned Developer Kit. The public API contract is distinct from native browser-only routes. Keep app keys and delegated tokens in trusted server storage. OAuth connections and MCP do not replace tenant identity or record permissions. Sensitive MCP capabilities require explicit app-level approval; connecting a client does not authorize every write. Use the exact documented route and the latest concurrency token, and refresh state after a conflict rather than replaying a consequential request blindly.

Verify external services before enabling work

Mail, payment processing, webhooks, Snowflake export and automation depend on configured providers and running workers. Verify the destination and credentials for the selected organization, test the connection and explicitly enable supported processing or schedules. A queued reply is not a delivered message, a transfer submission is not bank settlement, and a saved integration is not an active worker. See the Snowflake setup and export guide for its test, enable and schedule steps.

Protect sensitive values

Supported Contact secure fields use masked display and an explicit permission-checked reveal. Keep secrets out of ordinary fields and support messages. Do not assume that every module has an operational encryption and reveal flow; the secure-field guide distinguishes available contracts and setup requirements.

Find the evidence for a problem

Authorized builders can open + Debug for safe outcomes, timings and correlation references, then follow a problem to app Logs. Use its sanitized export for support. Closing a problem preserves its history; another occurrence can reopen it. Do not paste customer payloads, credentials or private keys into a ticket.

Wait for app readiness

App creation and infrastructure readiness are separate stages. An app has routed Core, Logs and AI database planes; inspect provisioning status and resolve reported setup requirements before inviting customers. A new app record is not proof that databases, DNS, certificates, compute and workers are ready. Exact-version template installs configure presentation; database updates follow a separate reviewed path. Customer-hosted Appliance operation and optional extension compute have separate deployment requirements.

For incidents use service status. A stale or unavailable feed cannot confirm health. Blog product ideas, conference topics and interface previews explain possibilities; they do not certify a live app or production launch.

Capability review: 2026-10-22. See current features and setup requirements, the generated API Map and first-class module inventory.