> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Magic Analytics FAQs

> Answers to common Magic Analytics questions on data freshness, PSA drift, exporting dashboards, drill-downs, Assistive AI exceptions, and ticket attribution.

## General

<AccordionGroup>
  <Accordion title="What is Magic Analytics?">
    Magic Analytics is Thread's built-in reporting experience. It brings your service desk metrics and the impact of Thread's AI products together in dashboards, lets you explore your data by topic, and — for AI Pro members — includes the Dashboard Agent for asking questions in plain English.
  </Accordion>

  <Accordion title="Is the data real-time?">
    No. Magic Analytics refreshes on a **daily cycle**, so it's effectively about a day behind. Each tile shows a **"Query ran…"** timestamp.
  </Accordion>

  <Accordion title="Can other companies see my data?">
    No. You only ever see your own organization's data.
  </Accordion>

  <Accordion title="Why is a dashboard slow sometimes?">
    It's a large dataset. Narrow your **date range** and apply **source / board** filters to speed things up.
  </Accordion>

  <Accordion title="Could the numbers differ from what I see in my PSA? (data drift)">
    They can differ slightly, for two reasons:

    * **The daily lag.** Magic Analytics is about a day behind, so very recent changes in your PSA may not have landed yet. This catches up on the next refresh.
    * **Missed or unconfigured syncs.** Your **PSA is the source of truth**, and Thread keeps in step with it through webhooks and scheduled syncs. If an integration isn't fully configured, or a webhook/sync is missed, some records can temporarily fall out of step — this is called **data drift**.

    <Note>
      A day-old difference is expected. If a number looks **materially** off (well beyond a day's worth of activity), it's worth checking that your integrations are fully configured, then reaching out to your Thread contact so we can reconcile it.
    </Note>
  </Accordion>
</AccordionGroup>

## Using dashboards

<AccordionGroup>
  <Accordion title="Can I download or export a dashboard?">
    Yes — See [*Downloading, alerts & scheduling*](/analytics/downloading-alerts-scheduling).
  </Accordion>

  <Accordion title="Can I be notified when something changes?">
    Yes — set an **Alert** on a tile. You can also **Schedule delivery** on a recurring cadence.
  </Accordion>

  <Accordion title="Why can't I drill into individual tickets/calls on some charts?">
    Some topics are **Aggregate** (rolled up for speed) and don't keep row-level detail. Use a **Detailed** topic like **Threads** (tickets), **Triage Agent** (sessions), or **Voice AI** (calls). See [*Things to know & gotchas*](/analytics/things-to-know-and-gotchas).
  </Accordion>

  <Accordion title="Why don't all closed tickets show who closed them?">
    We can credit the **member** who closed a ticket only when it's closed from within Thread (Inbox or Pods). Tickets closed directly in the PSA can't be attributed to a specific member, due to a PSA API limitation around impersonation. So closer metrics reflect closures made in Thread. See [*Things to know & gotchas*](/analytics/things-to-know-and-gotchas).
  </Accordion>

  <Accordion title="Why does my third-party report (Crewhu, BrightGauge, etc.) credit ticket closures to a Thread integration user instead of the real tech?">
    This is a PSA-side limitation, not a Thread reporting issue. Magic Analytics credits the correct technician for closures made in Thread Inbox or Pods.

    When any tool — Thread included — closes a ticket through the ConnectWise Manage API (or the equivalent write API on another PSA), the PSA stamps the **API integration member** as "closed by" on the ticket, not the technician who took the action. This is a documented PSA API limitation around impersonation. Downstream reporting tools that read from the PSA (Crewhu, BrightGauge, custom SQL, etc.) then see the integration user as the closer.

    **Recommendation:** In third-party reports where you want per-technician credit for closures, pivot on **ticket owner** instead of **closed by**. Ticket owner is set to the responsible technician and isn't affected by the API-writeback limitation.

    If you need per-technician closure credit that reflects actions taken in Thread, Magic Analytics already has this — the **Threads** topic and the **Service Team Performance** dashboard attribute closures to the real member for anything closed from Inbox or Pods.
  </Accordion>
</AccordionGroup>

## Assistive AI

<AccordionGroup>
  <Accordion title="What's an &#x22;exception&#x22; on the Assistive AI Accuracy dashboard?">
    It's a case where Thread's AI suggested a value (priority, category, title) and it was later overridden by a person or system.
  </Accordion>

  <Accordion title="Why are some overrides shown as &#x22;PSA / System&#x22; instead of a person?">
    When a change is made directly in the PSA, a PSA API limitation prevents attributing it to a specific member, so it shows as PSA / System. Changes made in Thread Inbox or Pods are attributed to the member. See [*Things to know & gotchas*](/analytics/things-to-know-and-gotchas).
  </Accordion>
</AccordionGroup>

## Dashboard Agent

<AccordionGroup>
  <Accordion title="Who can use the Dashboard Agent?">
    The Dashboard Agent is available to **AI Pro** members.
  </Accordion>

  <Accordion title="What can I ask it?">
    Follow-up questions about any tile, summaries, and re-cuts of the data within the topics you have access to. See [*Dashboard Agent*](/analytics/dashboard-agent).
  </Accordion>
</AccordionGroup>


## Related topics

- [Microsoft Teams 2.0 FAQs](/messenger/microsoft-teams-2-0-faqs.md)
- [Common questions](/get-started/common-questions.md)
- [Flows: Automate Thread Routing and Actions in Inbox](/inbox/flows.md)