> For the complete documentation index, see [llms.txt](https://docs.ixhello.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ixhello.com/ixhc2/conversation-transcript-as-a-flow-context-variable.md).

# Conversation Transcript as a Flow Context Variable

### Overview

The Conversation Transcript Variable introduces a new reserved, read-only flow context variable named `transcript`. This variable provides access to the current conversation transcript during runtime, enabling flows to leverage conversation history for analytics, summarization, auditing, compliance, and integrations with external systems.

The transcript is exposed as a JSON-formatted string and can be used anywhere string-based flow variables are supported, including expressions, interpolation, and API Call nodes.

### Key Benefits

With the `transcript` variable, flow authors can:

* Access the complete public conversation history during flow execution.
* Send conversation transcripts to external APIs for processing.
* Generate summaries and post-conversation insights.
* Perform compliance reviews and quality analysis.
* Build prompts for AI and LLM-based services.
* Maintain data protection through configurable PII redaction policies.

***

## How It Works

### The Transcript Variable

| Property      | Value                        |
| ------------- | ---------------------------- |
| Variable Name | `transcript`                 |
| Type          | String                       |
| Access        | Read-only                    |
| Scope         | Runtime-generated            |
| Format        | JSON serialized as text      |
| Availability  | All supported flow consumers |

The variable is automatically generated by the Runtime Engine and appears as part of the available flow variables in Flow Designer.

<figure><img src="https://4187494610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFe4cpY1jy0FJ4kgC7wSx%2Fuploads%2FszaYWJ5XziTtEdOVizqu%2Fimage.png?alt=media&amp;token=8488294c-ced0-4c14-996d-ac499537b804" alt=""><figcaption></figcaption></figure>

#### Example

```
[
  {
    "role": "assistant",
    "content": "Could you please provide your full name and account number?"
  },
  {
    "role": "user",
    "content": "[PERSON]"
  },
  {
    "role": "assistant",
    "content": "Thanks, we have captured the account number."
  }
]
```

The transcript is returned as a JSON string. If a downstream system requires structured access, it must parse the JSON content.

***

## Supported Use Cases

### Expressions

Reference the transcript in expression-enabled fields to:

* Perform conditional checks.
* Evaluate conversation context.
* Build dynamic runtime logic.

***

### String Interpolation

Use the transcript variable the same way as any other string variable.

#### Example

```
Conversation Transcript: 
${transcript}
```

Common scenarios include:

* Building prompts.
* Generating summaries.
* Creating audit records.
* Constructing API payloads.

***

### API Call Nodes

One of the primary use cases is sending the conversation transcript to external services.

#### Example Request Body

JSON{"transcript": "${transcript}"}

Example integrations include:

* Conversation summarization services
* Analytics platforms
* Quality assurance systems
* Compliance review services
* Knowledge extraction workflows
* AI processing services

***

## Transcript Content

### Included

The transcript variable contains:

* Public conversation messages
* Assistant responses
* User messages
* Information within the current retention window
* Content formatted as JSON text

### Excluded

The transcript variable does not include:

* Private subflow interactions
* Messages beyond the retention boundary
* Internal runtime-only content

### Retention Limits

The transcript follows existing transcript retention rules.

* Maximum retained entries: **200**
* No new storage model is introduced
* No separate retention policy is created

<figure><img src="https://4187494610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFe4cpY1jy0FJ4kgC7wSx%2Fuploads%2FXovquI8pmblKDl2QbZl3%2Fimage.png?alt=media&amp;token=e9b33538-4168-40ce-90b6-9a65374a782e" alt="" width="466"><figcaption></figcaption></figure>

***

## Data Protection and Redaction

### Sensitive Data Protection

The transcript variable follows the flow's configured Protect Sensitive Data policy.

When enabled:

* Personally identifiable information (PII) is automatically redacted.
* Redaction uses the existing Presidio-based protection pipeline.
* Protected output is validated before being returned.

#### Example

User Input:

Plain TextMy name is John Doe.

Transcript Output:

Plain TextMy name is \[PERSON].

#### Demo Scenario

During the feature demonstration:

1. The flow collected a user's first name, last name, and account number.
2. The transcript variable captured the conversation.
3. Personal information such as names was redacted according to the configured policy.
4. The transcript was successfully sent to an external API for processing.

<figure><img src="https://4187494610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFe4cpY1jy0FJ4kgC7wSx%2Fuploads%2FZYWJ4CEa9PM37Kkg1EO8%2Fimage.png?alt=media&amp;token=82c5ea00-7fc8-42e4-b019-172deebeb148" alt="" width="308"><figcaption></figcaption></figure>

<figure><img src="https://4187494610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFe4cpY1jy0FJ4kgC7wSx%2Fuploads%2FELala8FAEpfQ0xTr3I6f%2Fimage.png?alt=media&amp;token=7a836002-2b6e-4112-bfb6-9bee1342426e" alt="" width="563"><figcaption></figcaption></figure>

***

### Fail-Closed Protection

If redaction produces invalid or unsafe output:

* The transcript is not returned.
* The system does not fall back to unprotected data.
* This ensures compliance and security requirements are maintained.

***

## Flow Designer Experience

### Variable Availability

Flow authors will see a reserved variable: transcript

within the Flow Designer variable picker.

The variable behaves like any other string variable for consumption purposes.

***

### Characteristics

The variable is:

* Reserved
* Read-only
* Runtime-generated
* Automatically maintained

The variable cannot be:

* Modified
* Overwritten
* Reassigned
* Deleted

***

## Runtime Behavior

### Lazy Resolution

The Runtime Engine resolves the transcript only when it is required by a supported consumer.

Benefits include:

* Reduced processing overhead
* Improved runtime efficiency
* No unnecessary transcript generation

***

### Logging Protection

To reduce exposure of sensitive information:

* Runtime logs do not store transcript values.
* Transcript content is omitted from affected engine logs.
* Users should still validate downstream systems before transmitting transcript data externally.

***

## Common Scenarios

### Conversation Summarization

Send the transcript to an AI service to create:

* Session summaries
* Customer interaction notes
* CRM updates
* Case wrap-up records

***

### Analytics and Insights

Use the transcript for:

* Sentiment analysis
* Intent detection
* Topic extraction
* Trend analysis

***

### Compliance and Auditing

Leverage transcript data for:

* Regulatory reviews
* Audit trails
* Quality assurance
* Conversation verification

***

### AI Prompt Construction

Use the transcript as contextual input for LLMs or reasoning engines.

Example:

```
Analyze the following conversation and provide a summary: 

${transcript}
```

***

### Review Sensitive Data Settings

Before sending transcripts externally:

* Enable Sensitive Data Protection where appropriate.
* Validate redaction coverage.
* Test with representative conversations.

***

### Secure Downstream Systems

Ensure external services:

* Meet security requirements.
* Use appropriate access controls.
* Follow organizational data handling policies.
* Implement suitable retention policies.

***

### Plan Around Retention Limits

Remember that:

* Only the retained conversation window is available.
* The transcript is limited to the platform retention boundary of 200 entries.

***

### Do Not Depend on Private Subflow Content

Private subflow interactions are intentionally excluded and should not be relied upon by downstream processing logic.

***

## Limitations

| Limitation             | Details                                         |
| ---------------------- | ----------------------------------------------- |
| Read-only              | Cannot be modified by flow authors              |
| String format          | Returned as JSON text, not a typed object       |
| Public transcript only | Private subflow content is excluded             |
| Retention boundary     | Limited to retained transcript entries          |
| Log visibility         | Transcript values are omitted from runtime logs |

***

## Summary

The **Conversation Transcript Variable (`transcript`)** provides flow authors with secure, runtime access to the current public conversation transcript. It can be used in expressions, interpolation, and API calls like any other string variable, while respecting PII redaction policies, retention limits, and privacy safeguards. This enables powerful downstream scenarios such as summarization, analytics, compliance reviews, auditing, and AI-powered post-processing without requiring changes to existing flow schemas or storage models.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ixhello.com/ixhc2/conversation-transcript-as-a-flow-context-variable.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.