BC
Brad CodyAdministrator
Current product→Pipelines and record experience
Reverse spec drafted

Record Communications

Record-scoped messages and communication history.

Observed route/admin/leads/:id?tab=communicationFuture Spec 11 →
Current maturityDesigned multi-channel record inbox with empty conversations
Evidence confidenceVerified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

The Communication tab is a substantial record-scoped inbox rather than a simple log. It exposes Call, Email, SMS, In-App, Schedule and New actions; a health row for contact recency, preference, response time, unread, next follow-up and relationship; channel counts; search; and a conversation panel. Forest Hill Residence currently has zero conversations in every channel, although the health summary displays sample-like values such as last contact today and next follow-up tomorrow.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Channel actionsCall, Email, SMS, In-App and Schedule are first-class buttons plus a New menu.Verified live; composers not opened
Communication healthShows last contact, preferred method, average response time, unread count, next follow-up and relationship.Verified live
Channel railEmail, SMS, Call, In-App and Internal each show a count, with View all communications.Verified live at zero
Conversation searchSearch conversations input sits above the content panel.Verified live
Conversation stateChannel-specific empty message suggests composer or New menu.Verified for Email

User journeys

Current flows

01

Start communication

  1. Open Communication
  2. Choose channel
  3. Select participants
  4. Compose or place call
  5. Send through provider
  6. Attach thread to record
  7. Emit Activity and follow-up state
Observed result

Entry points verified; delivery not exercised.

02

Review thread

  1. Choose channel
  2. Search conversations
  3. Open thread
  4. Review messages/call artifacts
  5. Add internal note or follow-up
Observed result

Layout supports journey; no populated thread was available.

State model

Current and expected states

No conversation

Channel icon, No [channel] conversation yet and start guidance.

Unread

Health metric exists; live count is zero.

Healthy relationship

Live summary displays Healthy.

Delivery/call failure

Not observed.

Disconnected channel

Not visibly distinguished from an empty connected channel.

Product rules

Non-negotiable boundaries

  • Every external communication has a channel, participants, direction, timestamp, provider status and record linkage.
  • Internal content is never sent externally.
  • Email threading must use provider identifiers plus Project/record association rules.
  • Calling requires consent, recording policy and transcript visibility controls.
  • Health metrics must derive from real events and disclose unavailable data rather than show fabricated defaults.
  • Users see only communications permitted by relationship and field access.
Dependencies
Resend/email serviceTwilio SMS and voiceIn-app messagingCalendar schedulingCommunication thread modelContact identitiesNotificationsActivity events

Known current limitations · 6 mapped

What is missing, broken or unverified

Future Spec 11 owns closure →
  1. No populated live conversation was available.
  2. Channel composers, sending, receiving and delivery states were not tested.
  3. Health values appear inconsistent with zero channel events and may be seed/demo data.
  4. Purchased phone numbers, call recordings and transcripts are not evidenced here.
  5. Connection/setup states are not exposed.
  6. Thread-to-Project/provider auto-classification remains unverified.

Future alignment

Required evolution

  • 01Implement the unified inbox and record-aware classification in Spec 11.
  • 02Make connection state, delivery state and consent explicit.
  • 03Add purchased-number management, call recordings/transcripts and searchable summaries.
  • 04Use one communication object across Admin, Designer, Provider and Client relationships with strict visibility.

Current baseline

Acceptance record

  • All intended channels have visible entry points.
  • Channel navigation, search and empty states are present.
  • Health metrics are identified as derived operational data.
  • Unverified send/receive behavior is not claimed as working.
  • Potential demo-data inconsistency is documented.

Reverse-spec completeness

Documentation coverage

The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.

Purpose and user outcome

Documented

Roles and access

Documented

Routes and entry points

Documented

Page and component anatomy

Documented

Fields and displayed data

Documented

Primary actions

Documented

Forms and validation

Documented

States and transitions

Documented

Empty, loading and error states

Documented

Responsive behavior

Partial

Accessibility behavior

Partial

Activity and audit events

Partial

Data sources and persistence

Documented

Notifications and automation

Partial

Known defects and limitations

Documented

Reusable component dependencies

Documented

Future-spec conflicts

Partial

Visual and repository evidence

Deferred

Acceptance of current baseline

Documented
← Feature inventoryOpen Future Spec 11 →