How-To Do This

How to build Resolve

Build a permission-aware support operation that identifies customers, retrieves policy, proposes safe resolutions, and escalates exceptions.

Resolve is a ai customer support pattern. This guide turns the product concept into a buildable first release using BuildWithHQ records, pages, workflows, permissions, integrations, AI, and exact-version packaging.

Define the outcome before the screens

Help support teams understand an incoming request, see verified customer context and policy evidence, and complete a narrow resolution without giving an AI or browser broad authority.

1. Create the smallest useful data model

In the Developer Console, create or select the SaaS app and model these as application record types and relationships. The page editor composes React components and validated data bindings, which call the platform APIs for these records.

Relationship rule: Keep conversations and business records in their native models; use Universal Inbox as the attention layer that points to the work requiring action.

2. Build the working screens

Start with task-oriented pages instead of a page for every table. The first navigation should contain:

• Team support inbox and SLA queue.
• Conversation workspace with customer and order context.
• Policy evidence viewer.
• Resolution approval panel.
• Escalation and quality-review queues.

Use Puck for the normal visual experience. Keep stable block identity when using Monaco advanced JSON mode so future template upgrades can merge safely.

3. Set access before adding automation

• Limit customer/order context to the signed-in support role and location.
• Protect payment, identity, health, or other sensitive fields independently.
• Set action-specific ceilings for credits, cancellation, access reset, and data changes.

User Type menus establish eligible page routes for each audience. They do not grant the records or actions on those pages. The server derives the account, SaaS app, user, DataRole, and location scope from the verified identity on every data request.

4. Add the core workflows

• Message received → identity match or safe manual resolution.
• Issue classification → queue, owner, SLA, and required context.
• Suggestion → policy and confidence check → approval when required.
• Approved narrow action → execute once → reply and timeline evidence.
• Missing authority or ambiguous identity → escalation, never guessed mutation.

Make each mutation a narrow, reviewed action with explicit inputs, allowed states, correlation evidence, and an idempotent retry policy where retries are possible. Pages, integrations, and agents all reach the same application service and stored-procedure contract through supported APIs.

5. Connect channels and outside systems

• Connect approved email, SMS, and form channels.
• Retrieve order, billing, entitlement, or delivery context through reviewed connectors.
• Expose separate narrow actions for each supported resolution instead of a general mutation endpoint.

Use managed connections, OAuth connectors, inbound endpoints, and webhooks. Put specialized SDKs or private processing behind a declared appliance endpoint; never expose provider credentials to a page.

6. Add AI as a governed layer

Use retrieval to ground answers in effective policy and permitted customer records. AI may prepare a reply or resolution action, but policy and authorization decide whether it can run.

• Ingest policy with source/version metadata and visual evidence where needed.
• Return citations/evidence with every suggested answer.
• Represent refunds, resets, cancellations, and escalations as separate action contracts.
• Log retrieval, refusal, approval, and exact result.

AI and retrieval must apply CanAiReadRecords, tenant, DataRole, field, and location security before context is assembled. Planning and research remain read-only. Customer-facing or material changes use an action suggestion and the configured policy or human approval before execution.

7. Ship one complete vertical slice

Recommended first release: Receive one email category, match it to a customer, retrieve one policy, prepare a reply and a bounded action, and require approval before execution.

1. Create the minimum record types and seed representative, non-production data.
2. Build the primary list/queue and one complete detail page.
3. Implement one state-changing workflow and its denial/error states.
4. Add the narrowest useful integration or inbound channel.
5. Add one permission-aware AI read or suggestion only if it improves that workflow.
6. Test as an owner, a normal operator, a restricted user, and an unauthorized user.

8. Validate, package, and operate

• Test unknown and ambiguous customer identity.
• Test expired policy and insufficient evidence.
• Prove refund/permission ceilings cannot be bypassed.
• Replay inbound messages and actions without duplicate side effects.

Publish a reviewed exact version as a template when the pattern is reusable. If you sell it, complete the marketplace preparation checks. Template installs are version snapshots; upstream edits must never silently mutate a tenant copy.

Built-in data path: React components and data bindings call authenticated APIs; typed application services execute reviewed stored procedures and return bounded results with audit and correlation evidence.