How-To Do This

How to build RelateEverything

Build a CRM where people, companies, work, communications, files, and custom records reveal their connected context.

RelateEverything is a relationship-first crm 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

Let a user open any important record and understand the surrounding people, companies, work, conversations, documents, and history without duplicating those records into a separate graph-shaped application.

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: Use typed relationships between canonical records. Do not copy a contact, file, or project merely to make it visible from another page.

2. Build the working screens

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

• Global search and recent context.
• Person and company 360-degree views.
• Relationship explorer with typed filters.
• Project/work page with people, files, tasks, and conversations.
• Relationship quality and duplicate-review queue.

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

• Authorize both the relationship and each target record before displaying connected context.
• Protect sensitive fields even when the containing record is visible.
• Apply location and DataRole filters during graph traversal and AI retrieval.

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

• Record created/imported → match candidates → confirm or create identity.
• Relationship change → append history and refresh relevant views.
• Connected trigger → create follow-up work on the correct source record.
• Merge review → authorized deterministic merge with preserved provenance.
• Important context change → inbox attention for affected owner.

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

• Ingest contacts, calendars, files, messages, and CRM records with stable external IDs.
• Deduplicate through a reviewable matching process.
• Expose related context through authenticated APIs without returning inaccessible nodes.

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 relationship traversal to select relevant permitted context, then let AI summarize or suggest connections. AI-inferred relationships should remain distinguishable from confirmed facts.

• Filter accessible nodes before context assembly.
• Store provenance and confidence for inferred links.
• Require review before consequential inferred relationships drive mutations.
• Evaluate retrieval for both relevance and permission leakage.

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: Create people, companies, projects, tasks, files, and typed relationships, then build a company page that shows only the connected context the current user may see.

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

• Traverse mixed permitted/restricted relationships without leaking names or counts.
• Test duplicate and directional relationship rules.
• Preserve provenance during merge and unlink operations.
• Verify connected-record automations target the canonical record.

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.