Support timeline end-to-end operator guide

This is the operator-level walkthrough for Support → Timeline, the dashboard page that turns your organization’s own support history with Devotel Orbit into a working casebook. The companion reference Support history (Support → Timeline) describes each element; this guide teaches the workflow: reading a row’s anatomy at a glance, searching inside the thread with quotes, following the status lifecycle, exporting the history as CSV or JSON, knowing who sees what, understanding retention, and acting on a real two-ticket scenario. Open the surface from Support in the sidebar (next to Settings at the bottom of navigation).

1. The operator’s own casebook

Most support surfaces are queues: they show what needs answering. Support → Timeline is the inverse — a casebook of your own requests to Devotel Orbit support, kept in chronological order with the full thread on every entry. Reach for it to answer four operator questions:

What did we already ask? Search a topic before opening a new request; the answer or the half-finished thread is often already there.
Whose turn is it? The response cues tell you whether Orbit owes you a reply (Awaiting reply) or you owe Orbit a follow-up (Replied) without opening the row.
What was promised? Expand a resolved request and quote the exact reply that settled it. The thread is never removed.
Can we hand the history to an auditor or a BI tool? Export the same history as CSV or JSON from the tickets API.

Use it before you reach for the new-request form: the checklist in Support history (Support → Timeline) cuts a duplicate ticket’s wait down to a search.

2. Row anatomy, fully worked

Each list row is one support request. Read this row top to bottom; every element is live on the wire and costs you nothing to scan: Subject: Port-out stuck at carrier verification for +1 415 555 0132, derived from the ticket subject, the disposition when no subject was set, or a request reference fallback. This is your first scan target. Reference: Ref #a3f9c21b, the first eight characters of the request id, in monospace. Quote it to Orbit support when you follow up by phone, chat, or email and the agent finds the same request immediately. Status chip: Open, one of four: Open, Pending, Resolved, Won’t fix. The chip is colored to match the operator queue so a status reads the same on both sides of the conversation. Response cues, only on requests that are still active:

Awaiting reply: Orbit support has not posted a first public response yet. The ball is in our court.
Replied: Orbit support has answered. Open it to read; the follow-up is now yours.

Terminal requests (resolved, won’t fix) show neither cue; the status chip already conveys closure. Priority: shown only when it rises above Normal: High in amber, Urgent in red, Low muted. A normal-priority row stays quiet so true signal stands out. Category: the request type, one of Question, Incident, Problem, Task, flagged with the tag icon. This is the Zendesk-standard vocabulary: an incident is something broken, a problem is the root-cause investigation that may group several incidents, a task is a follow-up with no question attached. Channel hint: voice, chat, or email; where the request originated. Timestamps: Opened, Last update, and (once finished) Resolved, each rendered as a relative label with the absolute time on hover, pinned to your own timezone. Read at a glance, this row says: an urgent incident about a port-out, opened by phone, Orbit has already replied, and it’s still open. You know whether to open it before you click.

3. Free-text search semantics

The search box runs a full-thread, server-side search, not a title filter. It matches against:

the subject,
the request’s originating summary and transcript (the substance of a voice or chat opening),
every public reply in the thread,
the messages of the originating chat conversation, when the request began as a chat.

Internal operator notes are never matched; the search only sees what you can see. Practical quoting:

port-out stuck

matches any request whose subject, opening, replies, or originating chat contains the phrase. A keyword you remember from inside the conversation surfaces the request even when the subject says something else (“Carrier verification follow-up”). Read the caption. Below the box, the page spells the scope out: “Search looks inside the full conversation — the subject, your original request, and every message in the thread — not just the title.” When a word you remember returns nothing, widen the status filter to All before concluding the conversation isn’t there: the status chips combine with search, so a Resolved-only filter with the wrong term can hide the row. Search is debounced (the request fires after you pause typing, not per keystroke) and the previous results stay on screen while the new query resolves.

4. Status lifecycle and the meaning of “Awaiting reply”

A request moves through a four-state lifecycle:

Open: the request exists and is being worked. A newly opened request typically starts here.
Pending: work is blocked on an external party (the carrier on a port-out, a card network on a dispute) or on an answer from you. Pending means “not forgotten, waiting on someone.”
Resolved: the work is done. The resolved timestamp stamps the row. Nothing is removed; the full thread stays readable forever.
Won’t fix: the request was reviewed and closed without a change, with the reason in the thread.

What “Awaiting reply” means. The cue appears only on the still-active states (open, pending) and only until Orbit support posts a first public response. It answers “has anyone picked this up?” at a glance:

Awaiting reply on an open request: the request is in the queue; Orbit hasn’t answered yet. No action needed from you.
Replied on an open request: Orbit answered; the conversation is waiting on you. Open the thread to read the response.
No cue: the request is resolved or closed-won’t-fix. The status chip does the talking.

The cue is derived from whether a first public response exists. It is not an SLA timer and not a read receipt.

5. Export: CSV vs JSON shape

The same tickets API that powers the page offers a bulk export, GET /api/v1/inbox/tickets/export. It returns your organization’s request list as a file download, scoped to your org by the same auth the dashboard uses.

CSV: one flat row per request

curl "https://api.orbit.devotel.io/api/v1/inbox/tickets/export?format=csv" \
  -H "X-API-Key: dv_live_sk_your_key_here"

The CSV ships one header row plus a row per request. Sample:

ticket_id,subject,status,priority,type,source,disposition,agent_user_id,contact_id,requester_email,requester_contact_id,conversation_id,call_id,tags,summary,opened_at,resolved_at,reopened_at,created_at,updated_at
a3f9c21b-…,Port-out stuck at carrier verification,open,urgent,incident,voice_hangup_auto,,user_2hK…,contact_9b1…,ops@example.com,contact_9b1…,,call_7d2…,port-out|carrier,"Port-out for +1 415 555 0132 stuck at carrier verification step.",2026-09-12T14:03:11Z,,,2026-09-12T14:03:11Z,2026-09-14T09:31:42Z
b7e1d4f0-…,Invoice shows duplicate SMS segment charge,resolved,high,question,public_form,,user_2hK…,contact_4c8…,billing@example.com,contact_4c8…,,,billing|invoice,"September invoice lists the same SMS segment twice.",2026-09-08T08:12:05Z,2026-09-10T16:44:20Z,,2026-09-08T08:12:05Z,2026-09-10T16:44:20Z

Fields with no value export as empty cells; a request’s tags land pipe-joined in the tags column.

JSON: with optional inlined threads

curl "https://api.orbit.devotel.io/api/v1/inbox/tickets/export?format=json&include_comments=true&status=resolved&opened_after=2026-01-01T00:00:00Z" \
  -H "X-API-Key: dv_live_sk_your_key_here"

The JSON shape is a single envelope:

{
  "exported_at": "2026-09-30",
  "truncated": false,
  "tickets": [
    {
      "id": "b7e1d4f0-…",
      "subject": "Invoice shows duplicate SMS segment charge",
      "status": "resolved",
      "priority": "high",
      "type": "question",
      "opened_at": "2026-09-08T08:12:05Z",
      "resolved_at": "2026-09-10T16:44:20Z",
      "comments": [
        {
          "author_kind": "customer",
          "body": "Our September invoice lists the same SMS segment twice; can someone check?",
          "created_at": "2026-09-08T08:12:05Z"
        },
        {
          "author_kind": "operator",
          "body": "Confirmed — the duplicate was a reconciliation error and a credit is on its way.",
          "created_at": "2026-09-10T16:44:20Z"
        }
      ]
    }
  ]
}

include_comments=true (JSON only) inlines each request’s full public reply thread, oldest first, the same thread the dashboard expands inline.

Filters, caps, and the truncated flag

The export accepts the same filter axes as the tickets list (status, priority, source, type, disposition, opened_after, opened_before) and they AND-combine. There is no pagination: the export is the whole filtered slice up to the server cap. The caps are 10,000 requests for a flat export, 1,000 when comments are inlined. When the slice overflows the cap, the JSON response sets truncated: true (and the CSV simply returns the capped set). Narrow the date range or status filter and pull the remainder rather than treating the file as the full archive. opened_after must precede opened_before, or the request fails with a 422.

6. Visibility rules per role

The page reads the organization’s own requests through authenticated, org-scoped endpoints; visibility follows your tenant’s own role setup, not a platform gate.

Read access: any authenticated member whose role includes the dashboard Support section sees the same history. The page shows the public thread only: internal notes Orbit’s agents write during triage, and files attached to them, never appear on this surface.
Reply access: to write back on an open request, the member’s seat needs to be allowed to post on the tenant’s inbox tickets. The Continue this conversation button inside an expanded thread deep-links to the ticket’s composer, where the reply is written under the member’s own name. A member whose role is read-only on the inbox reads the same thread here but cannot answer it from either surface.
Restricted roles: if your organization restricts some roles to specific dashboard sections, a member whose role excludes this surface sees an access-restricted notice instead of the list. An owner or admin adjusts the member’s role to include it. Dashboard section restriction is a tenant-owned control.
API access: the export endpoint requires an API key for your organization; it returns that organization’s history only.

7. Retention and archiving behavior

Nothing is removed. A resolved request stays readable in full; there is no archive-by-age, no 30-day cap, and no purge of the public thread. Two practical bounds to know:

The recent window: the page loads the 100 most recent requests and reveals them in Show more pages so long lists stay light in the browser. When your history is longer than the window, a footer notes the full total and that older requests are preserved. Contact Orbit support to retrieve them, or pull the whole slice through the export endpoint above.
Thread depth on long chats: a request that began as a long chat pages back with Load earlier messages inside the expanded thread, so a multi-week conversation is never silently truncated.

Attachments follow the thread: files shared during the conversation stay downloadable as read-only copies for as long as the request is retained.

8. Worked scenario: pick up a port-out ticket and a billing dispute

An ops admin opens Support → Timeline on Monday morning with two threads to act on. First: the port-out ticket (#a3f9c21b).

Find it. Type port-out into search; the full-thread match surfaces the urgent incident even though its subject only says “Carrier verification follow-up.”
Read the cues. The row is Open, Urgent, Incident, channel voice, and shows Replied, Orbit support answered over the weekend. The ball is in your court.
Expand it. The thread opens in place: the call summary and transcript from the original hang-up, then the reply: “Carrier accepted the LOA; the port is scheduled for Wednesday. Reply here if the date slips.”
Act. The date works. You click Continue this conversation, the ticket’s composer opens, and you confirm under your own name. Your reply lands in the same thread labeled You, visible to every future reader.
Verify later. Come back Thursday; if the port completed, the status chip has flipped to Resolved with the resolved timestamp. The thread (transcript, the carrier’s LOA confirmation, your confirmation) stays readable for the next audit.

Second: the billing dispute (#b7e1d4f0).

Find it. A colleague asks “did we ever chase that duplicate SMS charge?” Search duplicate SMS; the resolved Question question row surfaces from two weeks back.
Confirm the outcome. Expand it: the thread shows the original form submission and the resolution reply: “Confirmed; the duplicate was a reconciliation error and a credit is on its way.” Quote the resolution in the team channel; nobody opens a duplicate ticket.
Hand it to finance. Finance wants the paper trail. Export the resolved slice:

curl "https://api.orbit.devotel.io/api/v1/inbox/tickets/export?format=json&include_comments=true&status=resolved&opened_after=2026-09-01T00:00:00Z" \
  -H "X-API-Key: dv_live_sk_your_key_here"

Check the truncation flag. The response returns "truncated": false, so the slice is complete. If it had returned true, you would narrow opened_after / opened_before and pull the remainder.

Two threads, both closed out from the same page. No request re-explained, no history lost, and the audit trail one export away.

WhatsApp

Guides

Messaging Controls

Audience & Support Tools

Support timeline end-to-end operator guide

Support timeline end-to-end operator guide

1. The operator’s own casebook

2. Row anatomy, fully worked

3. Free-text search semantics

4. Status lifecycle and the meaning of “Awaiting reply”

5. Export: CSV vs JSON shape

CSV: one flat row per request

JSON: with optional inlined threads

Filters, caps, and the truncated flag

6. Visibility rules per role

7. Retention and archiving behavior

8. Worked scenario: pick up a port-out ticket and a billing dispute

See also

​Support timeline end-to-end operator guide

​1. The operator’s own casebook

​2. Row anatomy, fully worked

​3. Free-text search semantics

​4. Status lifecycle and the meaning of “Awaiting reply”

​5. Export: CSV vs JSON shape

​CSV: one flat row per request

​JSON: with optional inlined threads

​Filters, caps, and the truncated flag

​6. Visibility rules per role

​7. Retention and archiving behavior

​8. Worked scenario: pick up a port-out ticket and a billing dispute

​See also

Support timeline end-to-end operator guide

1. The operator’s own casebook

2. Row anatomy, fully worked

3. Free-text search semantics

4. Status lifecycle and the meaning of “Awaiting reply”

5. Export: CSV vs JSON shape

CSV: one flat row per request

JSON: with optional inlined threads

Filters, caps, and the truncated flag

6. Visibility rules per role

7. Retention and archiving behavior

8. Worked scenario: pick up a port-out ticket and a billing dispute

See also