What Is the MYLO Call-Event History?

MYLO call-event history is a unified operational view of supported inbound calls, direct outbound calls, campaign calls, and API or controlled test calls. It connects each business call to an ordered event sequence, direction and origin context, result, related call legs, campaign or API identifiers, and recording reference where recording was explicitly enabled. It is not a replacement for raw Asterisk evidence or a complete customer relationship record.

Retention and Access Are Part of the Design

Event history can reveal customer numbers, employee activity, business schedules, outcomes, and recording relationships. Give access only to roles with a defined operational purpose, scope queries to the correct customer, and record sensitive retrieval where policy requires it. Exports and downstream CRM copies need their own retention and deletion rules; removing a view from MYLO does not remove every exported copy. Keep enough history to investigate and reconcile legitimate business activity, but do not retain unlimited detail merely because storage is available.

Read an Event History Without Overinterpreting It

Start with the call identifier and confirm the direction, business context, time zone, and related campaign or run. Read events in their supported order while retaining both source and ingestion times where available. Identify which events describe a customer leg, agent leg, bridge, IVR, recording, or final operation. A later event may add evidence without invalidating the fact that an earlier stage occurred.

Do not turn the presence of an “answer” event into a completed business conversation unless the required leg and bridge evidence supports it. Similarly, a terminal failure for an agent leg does not prove that the customer was never reached. If an event is missing or ordering is uncertain, retrieve current call state and mark the gap instead of manufacturing a neat sequence.

Use History for Reconciliation and Support

Applications can consume events for timely updates and use reporting retrieval to repair missed or duplicated delivery. Consumers should be idempotent: the same event must not create a second CRM activity, callback, or campaign count. Keep a durable checkpoint only after related records are committed, and use a bounded reconciliation window after downtime.

For support, export only the relevant call and redact unrelated customer data, credentials, and internal secrets. The evidence pack should contain the MYLO call ID, related business identifiers, bounded timeline, observed outcome, unresolved questions, and authoritative sources consulted. A call event history is therefore neither a raw Asterisk log nor a transcript. It is MYLO’s structured operational account of how a supported call progressed, suitable for explanation, audit, and careful follow-up.

One View Across Several Call Origins

An inbound call begins outside the organisation and reaches a published number and route. A direct outbound call may begin in the browser or through the customer-facing API. A campaign flow may contain customer and agent legs. A controlled test call may verify configuration. These calls start differently but all produce operational telephony events.

A unified history lets an authorised user answer “what happened to this call?” without searching unrelated screens. Each row or detail view should preserve its origin so a campaign call is not mistaken for an ad hoc API call.

Call ID Is the Primary Relationship

The call ID links the high-level call record to status and event detail. A business flow with several legs may also expose leg or channel identifiers and a parent relationship. Campaign context can add campaign, run, customer or lead identifiers. An API client stores the returned call ID to track the request.

Identifiers are safer than matching solely by phone number. One number may make several calls, and concurrent calls can share a destination. Applications should treat identifiers as opaque values and should not infer hidden meaning from their format.

Events Form an Ordered Sequence

Depending on the flow, events can represent accepted request, origination, ringing, answer, bridge, DTMF, transfer, hang-up, recording relationship, provider or endpoint failure, and final result. The exact customer-facing catalog is authoritative; developers should not invent event names from examples.

Timestamps and leg relationships explain order. The history should not imply that an “answered” first leg means a human conversation occurred if the second leg never connected. A final result must reflect the supported state machine and evidence.

Inbound and Direct Outbound Context

An inbound detail can show the called number, matched route, destination, and result while respecting permissions. A direct outbound detail can show the authorised caller identity, requested destination, accepted request, and final call outcome. The history should not expose SIP credentials or internal callback endpoints.

A test call should be labelled as test context where the contract supports it so operators do not mistake it for customer demand. Test data still needs privacy, retention, and recording controls.

Campaign Context Is Leg-Aware

Campaign history connects the call to the campaign and run, selected flow, lead or customer record, agent destination where applicable, attempt number, retry eligibility, and final result. Customer no answer must remain separate from agent-side failure.

Pause, resume, restart reconciliation, and natural completion can affect when work occurs but should not erase the event chain. Supervisors need to see what was attempted before an interruption and why a record did or did not remain eligible.

Recording Is a Relationship, Not the Event History

When recording was explicitly approved and successfully created, the call record may contain or relate to a recording identifier. Access to event metadata does not automatically grant permission to retrieve audio. The recording API and user interface should enforce their own role, retention, and availability rules.

A missing recording does not mean the call never occurred. Recording may have been disabled, failed under the campaign’s approved policy, or been deleted after retention. Events and recordings have related but distinct lifecycles.

Use History for Operations and Integration

Operators can investigate missed routes, campaign outcomes, API calls, and customer reports. Developers can relate a returned call ID to events, final status, campaign reporting, and a recording reference when authorised. Pagination, filters, and event streaming should follow the current documented API contract.

Call history is not a CRM and should not become an unlimited profile of a person. Export only the fields needed for the integration, protect them, and define deletion and reconciliation when source records change.

Call-Event History Checklist

• Start with a call ID and preserve origin context.
• Keep call legs and their outcomes distinct.
• Order events by authoritative timestamp and relationship.
• Connect campaigns, runs, API requests, tests, and recordings through identifiers.
• Enforce separate access for event metadata and audio.
• Use raw bounded Asterisk evidence when deeper diagnosis is required.