Skip to main content

​
Read and export the unified contact timeline

Every time a customer texts, calls, joins a video room, executes a campaign step, or talks to an AI agent, the contact record collects a touchpoint. Before the Timeline tab, reconstructing one customer’s history meant paging Conversations, Call logs, and campaign logs separately and merging them by hand. The contact-detail Timeline tab merges all of those sources into a single reverse-chronological feed you can filter with chips, page through, and export. Open it from the dashboard sidebar under Contacts → Audience → Contacts, pick a contact, and switch to the Timeline tab of the contact-detail page.

​
Where the timeline sits in the customer-360 workspace

The timeline is not a standalone report — it is the per-person feed that two surfaces share:
  • The contact-detail Timeline tab is the dedicated, filterable view covered by this guide. Use it when you want to isolate one contact and apply the chip strip.
  • The Customer-360 workspace (/contacts/{id}/360) embeds the same timeline as its always-first Journey replay tab. The three-column workspace surrounds it with the identity card, open conversations, and the agent assist panel, so an agent can scan history while a live conversation is open in another tab. See Customer-360 workspace for the full layout.
Both surfaces read the same merged feed, so a filter decision you make in one place (for example, confirming that a video session happened before a ticket) holds true on the other.

​
The ten event buckets

The top of the tab renders ten channel buckets as filter chips. Each chip maps to one underlying source, so enabling a bucket narrows the feed to the touchpoints that belong to it: Leaving all chips unselected is the open default and returns every bucket. Unknown chip values are ignored, not rejected, so a stale chip from a previous rollout never fails the query.

​
How chips map to API filters

The dashboard chips translate directly onto query parameters on GET /api/v1/contacts/{id}/timeline. Each filter axis is additive — AND semantics across axes, OR semantics within one axis.
The response page carries items, next_cursor, and has_more. Rows are flat — id, type, ts, channel, a one-line summary, an in-app deep_link, and cross-references (conversation_id, call_id) so a row click jumps to the matching tab. limit defaults to 50 and accepts up to 100; cursor pagination walks the merged sources without skipping rows that share a timestamp. For the deep journey-timeline variant (GET /api/v1/contacts/{id}/journey), the same channel/type/direction axes widen to richer event types — message, call, agent_chat, agent_handoff, consent, note, sdk_event, lifecycle_change, campaign_enrolled, campaign_completed, survey_response — plus date bounds (after/before, with since/until accepted as aliases) and a cursor page size of up to 100 rows.

​
Interaction-search semantics

The Interactions page (/interactions) is the workspace-wide counterpart — it answers “search every conversation and call across messaging and voice in one recency-ordered list.” Where the contact timeline is scoped to one person, Interactions is scoped to the whole workspace.
  • Search axes: free text q matched against the linked contact’s name, phone, or email; channels (the inbox channel vocabulary — voice includes calls); types (conversation, call, or both); statuses; a contact_id restriction; and since/until ISO bounds on last activity. All filters combine with AND semantics; unknown values match zero rows rather than failing the request.
  • Ordering: rows sort by last_activity_at descending — the most recent touch first, mixed across channels. A conversation row’s timestamp is its latest message; a call row’s timestamp is the call start.
  • Pagination: cursor-based, the same shape as every other Orbit list — limit defaults to 25 (max 100), the response carries a cursor and has_more, and the dashboard’s Load more walks the same cursor chain.
  • Result pages: run the search from the dashboard sidebar under Interactions, or call GET /api/v1/interactions directly. The export header button and API export apply the same filters you see on screen.

​
Support history and the timeline

The Support page (/support) is the inverse view — every conversation your organization has had with Orbit support, not your customers’ conversations with you. A support row carries subject, status, response cues (Awaiting reply / Replied), priority, and timestamps; expanding it reveals the full public thread. That page exists so a support interaction never starts from zero. When your own support threads merge with a contact — for example, a ticket raised on behalf of a customer, or a support conversation linked from their profile — the ticket chip on the contact timeline is the bucket that renders them. A merged support thread still counts as one row on the contact timeline, linking back to the inbox conversation rather than duplicating each message.

​
CSV export

The Export CSV button on the timeline downloads the same filtered view as a file. The export runs through GET /api/v1/contacts/{id}/journey.csv and is capped at 5,000 rows — enough for an ad-hoc review, bounded so a browser can’t accidentally pull a multi-million-row history. Use CSV when:
  • The export is one bounded slice of the contact’s history — the same filters you applied on screen, packaged for a spreadsheet.
  • A colleague or auditor needs the record and you already know which chips to narrow.
Use the GDPR data-export flow when:
  • A data subject requests a complete access export. GDPR export traverses the full journey history, not just the 5,000-row view.
  • You need a complete, legally-compliant handover rather than a working slice.
The 5,000-row ceiling is the CSV guardrail; GDPR export is the complete-export path. Pick CSV for the day-to-day review, GDPR for the subject-access response. Export permissions and PII redaction follow the same role gates as the on-screen view — see Interactions for the export-permission model.

​
Walk the dashboard

  1. Open Contacts → Audience → Contacts and pick a contact.
  2. Switch the detail pane to the Timeline tab.
  3. Click a chip to narrow the feed; click it again to widen back. Chips combine with AND semantics across axes (channel AND direction), OR semantics within one axis.
  4. Set the From / To date range if the feed is too long.
  5. Select Export CSV to download the filtered view, or Clear (N) to reset all filters at once.

​
Troubleshooting an empty timeline

Work top-down — each check eliminates one class of empty feed:
  1. Stale chip — a channel bucket left selected from a previous session filters everything out. Hit Clear (N) to remove all filters and re-test.
  2. Date range covers nothing — a narrow From / To range or an accidental one-day window hides older touchpoints. Widen the range or remove it.
  3. Bucket source is genuinely empty — if the contact has no video or agent sessions, that chip returns zero rows even though other buckets have data.
  4. Permission scope too narrow — the timeline respects the caller’s role. Viewer and supervisor roles get PII-masked summaries; confirm your role can read the contact row at all.
  5. Wrong contact picked — the feed is per contact id. Verify the detail pane shows the same contact you searched for.
If none of these checks resolve the empty feed, the contact may simply have no recorded activity yet.

​
See also