Skip to main content

​
Customization And Builder

This page summarizes how gb-fu-charles should approach user-driven customization and a future graphical journey builder.

​
The short answer

We should borrow the pattern from gbcrm and ElevenLabs, but not copy their full platforms into this repo. What fits:
  • workspace-defined contact attributes
  • normalized tags
  • saved dynamic segments
  • configurable inbox and contact views
  • a typed graphical journey builder
  • a future tool catalog and knowledge-base layer
What does not fit yet:
  • full custom-object creation
  • a broad CRM-style metadata engine
  • a general-purpose no-code automation platform
  • AI-agent complexity before the message plane is real

​
Why this matters

Without a real customization model, every request for:
  • new tags
  • new contact properties
  • new segment columns
  • new inbox side-panel fields
becomes a developer task. That is operationally slow and forces product work into engineering even when the requirement is workspace-specific.

​
Phase 1: Controlled customization

Start with:
  • custom contact attribute definitions
  • normalized tags on contacts and conversations
  • segment definitions and snapshots
  • configurable contact and inbox views

​
Phase 2: Typed automation schema

Before adding a canvas, define:
  • a typed journey node model
  • a typed condition model
  • stable references to tags, segments, templates, and custom attributes
  • publish-time validation rules

​
Phase 3: Graphical builder ✅

Shipped (Apr 2025 sprint). Uses a dedicated React Flow graph module with a small node catalog:
  • trigger
  • condition
  • wait
  • send template
  • update attribute
  • add/remove tag
  • outbound webhook
  • AI agent step
  • exit
The editor is at /journeys/[id] with inline validation, cycle detection, and a publish pipeline that creates immutable journey snapshots.

​
Phase 4: Knowledge and tools ✅

Shipped (Apr 2025 sprint). Now that the message runtime is durable:
  • knowledge assets for FAQ/policy/product facts (powered by asset storage, BORD-187)
  • a controlled tool catalog (agent tool-use permissions in ai_agents table)
  • preview and simulation tooling (phone-frame renderer in template builder, journey node validation)

​
Why not copy the full gbcrm model?

The sibling CRM supports a much broader metadata engine:
  • custom objects
  • custom fields across the product
  • graph overviews of the data model
  • workflow builder infrastructure
That breadth is useful in a CRM. It would be too heavy here if adopted wholesale before the WhatsApp control plane is stable.

​
Why ElevenLabs is still useful

The best things to borrow are UX patterns:
  • template-first entry
  • left-rail catalog plus center canvas
  • use-template flow
  • preview/testing before publish
  • separate knowledge and tool catalogs
That is a better operator experience than throwing users into raw JSON or a blank node canvas.
  1. Custom attributes
  2. Normalized tags
  3. Saved segments
  4. Configurable views
  5. Typed journey schema
  6. Graphical builder
  7. Knowledge and tools