Get Journey data

## Getting data from the Journey (ticket history)

The Journey is essentially the audit/log of a Service Record (SR). Today, that information is **not directly exposed as a dedicated “Journey”/history endpoint in the SysAid REST API**, and there is **no simple, supported API call that returns the full Journey stream (all notes, field changes, etc.) as you see it in the UI**.

Below are the realistic options you have as an admin:

---

### 1. Via REST API (what you can and cannot get)

- **You can get the current values of SR fields** (status, assignee, description, etc.) via the standard Service Record endpoints.
- **You generally cannot get the full Journey history** (all field changes over time, audit log, all Journey events) via the public REST API:
- No public endpoint for “Journey events” / “activities” / “audit log per SR”.
- Some environments may expose limited status‑history–type data via customizations, but the generic REST docs do **not** provide a standard “history” object.

So, if your use case is:

- “Show me all status changes, assignee changes, and notes over time”
→ That full detail is **not** available via the standard REST API.

---

### 2. Is Journey data in a specific database table?

Yes: at the database level (for on‑prem / backup SQL), Journey is built from **history/audit tables** that store:

- Field‑change events (old value, new value, when, who)
- Notes / messages / resolution comments
- Status and assignment changes
- Attachments metadata, etc.

However:

- The **exact table names and relationships** depend on your deployment (cloud vs on‑prem and version).
- SysAid does not officially support **direct DB queries in production** in cloud; instead you may receive **MySQL backups** on request, which you can query in your own SQL environment.
- For table‑level details, SysAid provides a **Database Guide / data model documentation** (if you don’t already have it, you’d normally request it from SysAid Support in a Service Record).

So: **yes, Journey is in tables**, but they’re meant to be accessed via:
- Reports / BI extract
- DB backup + your own SQL
not directly by end‑users via the public REST API.

---

### 3. Alternative ways to work with Journey‑like data

Depending on what you’re trying to do, you have a few options:

#### A. Analytics / Reports

For many use cases (KPIs, trend analysis, SLA breaches, etc.), you can:

1. Go to **Analytics → Reports**.
2. Create a **Service Record** report.
3. Use:
- Filters (e.g., by status, category, dates)
- Additional fields (request time, close time, assignee, etc.)
4. Export to **Excel/CSV**.

This will not give you the full event‑by‑event Journey, but may be enough for reporting needs.

#### B. Power BI Extract / BI tools

- SysAid’s **Power BI Extract / JSON export** exposes a richer data set than the basic UI export.
- However, based on existing information, the **full Journey history is generally not included** as a simple “history table” in the standard export.
- If your goal is:
*“Feed ticket history into BI for analysis”*
→ The current general answer is: **not fully supported yet; you mainly get current state, not complete Journey logs.**

#### C. Database backups (cloud) or direct DB (on‑prem)

If you need **all historical detail**, including what you see in Journey:

- **Cloud**:
- You can request **regular DB backups** (MySQL) + attachments backups.
- After downloading the backup, you can:
- Restore it to your own MySQL instance.
- Query the relevant **history/audit tables** to reconstruct the Journey events.
- For help identifying tables/fields (e.g., where notes, statuses, assignees, etc. are stored), you’d reference the **SysAid Database Guide**.

- **On‑prem**:
- You can directly query the SysAid DB.
- Again, use the **Database Guide** to identify the correct tables (SR main table + history/audit tables).

---

### 4. Practical next steps

To move forward, decide which scenario you’re in:

1. **You just need metrics, not full event‑by‑event logs**
→ Use **Analytics → Reports** or **Power BI Extract**.

2. **You need the *complete* Journey/audit trail for integration, compliance, or deep analysis**
- For **cloud**:
- Enable/download the **DB backups**.
- Ask Support (via a Service Record) for:
- The **Database Guide** / data model.
- Confirmation of which tables store Journey/audit data in your version.
- For **on‑prem**:
- Use your DB access + Database Guide to query the history tables directly.

3. **You were hoping to call a REST endpoint like `/journey/{srId}`**
→ That **doesn’t exist currently** in the public API.
If this is important for you (e.g., for an external system that needs ticket history), it’s worth opening a **feature request** with SysAid Support so it can be considered for the roadmap.

---

### If you share your exact need…

If you tell me:

- What *exactly* you want from the Journey (e.g., “all status changes with timestamps and who changed them”, “all notes and messages”, “every field change”), and
- Whether you are **cloud or on‑prem**

I can outline a more concrete approach (e.g., suggested report, what to pull via API, or how to structure queries against the backup DB).