# Conversations

The **Settings > Configuration > Conversations** window allows you to set parameters for your Aisera tenant. These settings apply to any bot you create in this Aisera tenant.

## Session management

### User Session Duration (min.)

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `5`                   |

When a user stops interacting with the bot, Aisera waits for this many minutes before ending the session. The timer resets with each message, so this is an idle timeout rather than an absolute session length. Once it expires, the conversation context resets and the user's next message starts a new session. By default, this period is five minutes.

Increase this value if users in your environment frequently pause mid-conversation and need context preserved across longer gaps. Decrease it to release session resources sooner in high-volume deployments.

While a user is in Live Agent mode, this setting does not apply. See also: [Max Idle Time(min) for Users in Live Agent Mode](#max-idle-time-min-for-users-in-live-agent-mode)

### Max Idle Time(min) for Users in Live Agent Mode

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `30`                  |

Sets how long, in minutes, a user's session can remain idle while they are in an active live agent session. The timer resets with each new message or interaction. If no activity occurs for the configured number of minutes, the session expires.

This setting applies only while the user is in Live Agent mode. For all other conversation states, the standard User Session Duration applies.

Setting this to `0` disables the idle timeout, keeping the session active indefinitely regardless of inactivity. Increase this value to allow more time between agent and user responses. Decrease it to free up session resources by disconnecting inactive sessions sooner.

See also: [Max Idle Time(min) for Agents in Live Agent Mode](#max-idle-time-min-for-agents-in-live-agent-mode)

### Max Idle Time(min) for Agents in Live Agent Mode

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `0`                   |

Monitors each active live agent session and tracks the last time the assigned agent sent a message. If the agent has not responded within the configured number of minutes, Aisera disconnects the session and sends the user a notification that the agent is unavailable.

The idle timer only starts after the agent first joins the session and sends a message. Sessions where no agent has yet joined are not affected.

The default value of `0` disables this feature entirely, keeping sessions active regardless of agent inactivity. Enable this when you need to ensure users are not left waiting indefinitely for an unresponsive agent.

See also: [Max Idle Time(min) for Users in Live Agent Mode](#max-idle-time-min-for-users-in-live-agent-mode)

### Live Agent Connection Timeout

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `5`                   |

When a user is transferred to a live agent queue, Aisera starts a timer using the configured value. If no agent joins within that many minutes, Aisera closes the session and sends the user a notification that no agent is currently available. The default is five minutes.

The message sent to users when the timeout is reached is customizable via the `live_agent_connection_timeout` message in Conversation Messages. See [Conversation Messages](https://app.gitbook.com/s/ksUDWGr9UTfOpa53PosP/how-to-set-up-an-aiseragpt-bot/add-conversation-messages) for instructions on editing this message.

### Download Transcript after Live Agent Chat

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Disabled |

When enabled, Aisera presents a button to the user when a live agent chat session ends, allowing them to download a transcript of the conversation. The button prompt and label are customizable via the `live_agent_message_download_transcript` and `download_transcript_button_label` messages in Conversation Messages. See [Conversation Messages](https://app.gitbook.com/s/ksUDWGr9UTfOpa53PosP/how-to-set-up-an-aiseragpt-bot/add-conversation-messages) for instructions on editing these messages.

Enable this when your support policy requires users to retain a record of their live agent interactions, or when compliance requirements mandate that users have access to their conversation history.

## Response behavior

### Response Message Delay In Milliseconds

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `1000`                |

Sets the minimum time gap, in milliseconds, between consecutive outbound messages during a conversation. Before sending each message, Aisera measures the time elapsed since the previous message. If less than the configured value has passed, delivery is held until the gap is met. If messages are already spaced further apart, no additional delay is added.

Increase this value if users report responses appearing too rapidly or if downstream channels have rate limits. Decrease it to reduce perceived latency where message pacing is less important. Setting this to `0` disables enforced spacing entirely.

### Page Size

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `3`                   |

Controls how many knowledge base results Aisera displays in a single response when a user's request matches multiple articles. When more results exist than the configured value, Aisera shows the first batch and presents a **More Recommendations** option. Each time the user selects it, the next batch of the same size loads. The button disappears when all results have been shown. If the total number of results is at or below the configured value, all results appear at once.

Decrease this value if users are overwhelmed by too many results at once or if your channel has limited display space. Increase it if users frequently need to load more results and your channel can comfortably display longer lists.

### ConversationGraph version

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `1`                   |

When Aisera answers a question using a knowledge base article that contains linked sections, it presents a navigation graph with clickable buttons allowing the user to explore related sections. This setting selects which version of the graph-building algorithm is used. Valid values are `1`, `2`, and `3`. Any other value falls back to version `1`.

{% hint style="warning" %}
It is recommended you change this setting only under the direction of Aisera Support.
{% endhint %}

### ConversationGraph Node as XList

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `0`                   |

Controls whether navigation options presented from conversation graph nodes appear as clickable buttons or as a scored list, and how many options are shown.

When set to `0`, all available navigation options are presented as clickable buttons. When set to a positive number, options are presented as a scored list instead, showing up to the configured number of items.

Set this when you want to limit and rank the navigation options shown to users rather than displaying all available options as buttons.

### Response Order Config

| **Type**    | Text field (JSON)                        |
| ----------- | ---------------------------------------- |
| **Default** | `{"KB":1,"Action":2,"ServiceCatalog":3}` |

Controls the display order of responses when a user's message returns results from more than one source. Assign each source a rank of `1`, `2`, or `3`. When multiple sources return results in the same turn, the source ranked `1` appears first, followed by rank `2`, then rank `3`. If only one source returns results, this setting has no effect.

When Action or Service Catalog is ranked first, Aisera embeds knowledge base results inside the action or Service Catalog response card rather than displaying them as a separate block. If the top-ranked source returns no results, Aisera falls through to the next ranked source.

Adjust this when your deployment should prioritize a specific response type. For example, a service desk deployment where automated actions should always take precedence over article recommendations would rank Action first.

This field accepts a JSON object with all three keys present:

```json
{"KB":1,"Action":2,"ServiceCatalog":3}
```

Omitting a key may cause that source type to be misrouted into an unintended ordering position.

### Present Service Catalog Item Conversationally

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Enabled  |

Controls whether service catalog items are presented as a conversational flow or as a rendered form. On channels that support dynamic form rendering, the default behavior is to display a form. When enabled, Aisera presents service catalog fields conversationally instead, asking each question in sequence regardless of the channel's form capabilities. On channels that do not support form rendering, the conversational flow is always used regardless of this setting.

Enable this when you want a consistent conversational experience across all channels, or when a step-by-step flow provides a better user experience than a rendered form for your service catalog items.

### Show Translated Content Info

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Enabled  |

When enabled, Aisera appends a hint to any response that has been translated, indicating to the user that the content was machine-translated. The hint only appears on translated responses and has no effect on content served in its original language. The default hint text is "Note: This is Translated Content."

Enable this in multilingual deployments where you want users to know when a response has been translated rather than served in its original language.

The hint text is customizable via the `translated_content_hint` message in Conversation Messages. See [Conversation Messages](https://app.gitbook.com/s/ksUDWGr9UTfOpa53PosP/how-to-set-up-an-aiseragpt-bot/add-conversation-messages) for instructions on editing this message.

### Threshold to Show Complete Options List in Transcript

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `50`                  |

Controls the maximum number of dropdown options recorded in conversation transcripts and history. When a flow presents a dropdown question with more options than this threshold, the transcript shows the first half of the options, an ellipsis, then the last half rather than the full list. This applies to ticket descriptions, live agent handoff context, and flow execution history. It does not affect what users see in the live chat widget.

Setting this to `0` always displays the complete options list regardless of length.

Lower this value if long dropdown lists are cluttering ticket descriptions or live agent handoff notes. Raise it or set it to `0` if agents need the full options list visible in transcripts for context.

## Audit and privacy

### Data Retention Policy

| **Type**    | Text field (JSON array)                                                                 |
| ----------- | --------------------------------------------------------------------------------------- |
| **Default** | `[{"dataModel": "Conversations"}, {"dataModel": "JobExecution", "retentionDays": 720}]` |

No description available.

### No Conversation Audit User Emails

|             |                              |
| ----------- | ---------------------------- |
| **Type**    | Text field (comma-separated) |
| **Default** | `test@aisera.com`            |

Specifies a comma-separated list of user email addresses to exclude from conversation auditing. Any user whose email matches an entry in this list will not have their conversations recorded in the audit log, and their activity will not appear in conversation analytics or reporting.

Use this to exclude internal test accounts or QA users who regularly interact with the bot for testing purposes. Without this, test activity will pollute your conversation analytics and audit data.

Email matching is case-insensitive. The default value `test@aisera.com` excludes the built-in Aisera test account. To add multiple addresses, separate them with commas: `user1@example.com,user2@example.com`

### Anonymize Conversation Audit

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Disabled |

When enabled, Aisera applies PII detection and anonymization to conversation data before it is written to the audit record. This ensures sensitive information entered by users or surfaced in bot responses does not appear in plain text in conversation audit logs. Anonymization is applied at audit write time and does not affect live responses delivered to users.

Individual form fields and card response fields can be configured to always mask their values, and those fields are masked regardless of this setting. Enabling this adds a broader layer that catches sensitive data not individually flagged at the field level.

Enable this when your organization requires that personally identifiable information be masked in stored conversation data, such as to meet privacy regulations or internal data governance policies.

This setting requires the Anonymize Conversation Template to be configured. Without a valid template, enabling this setting has no effect.

See also: [Anonymize Conversation Template](#anonymize-conversation-template)

### Anonymize Conversation Template

| **Type**    | Text field (JSON)  |
| ----------- | ------------------ |
| **Default** | `{"text":"$TEXT"}` |

Defines the PII detection and transformation rules applied when Anonymize Conversation Audit is enabled. This template must be configured for anonymization to have any effect.

Aisera uses Microsoft Presidio as the underlying PII detection and anonymization engine. The `AnalyzeTemplate` section maps to Presidio's Analyz[er service](#anonymize-conversation-template-1) and the `AnonymizeTemplate` section maps to its Anonymizer service. Supported entity types are those provided by Presidio's built-in recognizers. See the [Presidio documentation](https://microsoft.github.io/presidio/) for the full list of supported entity types.

The template is a JSON object with two sections. The `AnalyzeTemplate` section specifies which PII entity types to detect, such as `PHONE_NUMBER`, `CREDIT_CARD`, `LOCATION`, and `DATE_TIME`. The `AnonymizeTemplate` section specifies how each detected type is transformed. Three transformation types are supported: `maskValue` replaces characters with a masking character, `redactValue` removes the value entirely, and `replaceValue` substitutes it with a custom string.

To use the v2 anonymization engine, include `"version": "v2"` at the top level of the JSON. Omitting it defaults to v1.

The following is an example of a valid template:

```json
{
  "AnalyzeTemplate": {
    "fields": [
      {"name": "PHONE_NUMBER"},
      {"name": "CREDIT_CARD"},
      {"name": "LOCATION"}
    ]
  },
  "AnonymizeTemplate": {
    "fieldTypeTransformations": [
      {
        "fields": [{"name": "PHONE_NUMBER"}],
        "transformation": {
          "maskValue": {
            "maskingCharacter": "*",
            "charsToMask": 8,
            "fromEnd": false
          }
        }
      },
      {
        "fields": [{"name": "CREDIT_CARD"}],
        "transformation": {
          "redactValue": {}
        }
      },
      {
        "fields": [{"name": "LOCATION"}],
        "transformation": {
          "replaceValue": {
            "newValue": "<LOCATION>"
          }
        }
      }
    ]
  }
}
```

This template is also used by the `AnonymizeTextAction` built-in action, which can apply the same anonymization logic within a flow at runtime.

See [Masking PII](https://docs.aisera.com/aisera-platform/tenant-setup/security-and-privacy-traps/masking-pii)

See also: [Anonymize Conversation Audit](#anonymize-conversation-audit)

### ConvAI Data Retention Period in days

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `0`                   |

Sets the number of days Aisera retains ConvAI conversation data before permanently deleting it. When set to a positive number, Aisera permanently deletes any ConvAI data older than the specified number of days. When set to `0` or left empty, retention enforcement is disabled and data is kept indefinitely.

Configure this when your organization has data governance or compliance requirements that limit how long conversation data may be stored.

{% hint style="warning" %}
Deletion is permanent and cannot be undone.
{% endhint %}

## System of Record

### Track Workflow Request

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Disabled |

When enabled, Aisera automatically creates a ticket in the configured System of Record at the end of any conversation where the user completed a workflow. If the user already created a ticket during the conversation, no additional record is created.

The ticket is created with the user's initial request as the title, the full conversation transcript as the description, a status of Closed, and a priority of High.

Enable this when your organization requires a record in the System of Record for every completed workflow, independent of whether the broader Add Conversation to SOR setting is enabled.

See also: [Add Conversation to SOR](#add-conversation-to-sor)

### create ticket to SOR on KB Serving over Email

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Disabled |

When an incoming email is handled and Aisera serves a response, enabling this setting triggers the KB Ticket Resolution flow to create a record in your System of Record. The flow receives the user's query, the knowledge base article content if Aisera found one, and a flag indicating whether an article was served. The flow can use this to create a ticket, suppress the response email, or append follow-up questions.

When disabled, email responses return the knowledge base article directly without creating any ticket record.

Enable this when your organization requires a System of Record ticket for every inbound email request Aisera handles.

{% hint style="info" %}
This setting requires a **KB Ticket Resolution** flow to be configured for the bot. Without it, enabling this setting has no effect.
{% endhint %}

### Add Conversation to SOR

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Disabled |

When enabled, Aisera executes the Post Conv Ticket Creation flow at the end of each closed, non-casual conversation that does not already have a ticket. The flow creates a ticket in your System of Record with the user's opening message as the title and the full conversation transcript as the description. The ticket is created with a status of Closed and a priority of High.

Enable this when you want every conversation logged as a record in your System of Record for audit, reporting, or support tracking purposes.

{% hint style="info" %}
This setting requires a Post Conv Ticket Creation flow to be configured for the bot. Without it, enabling this setting has no effect.
{% endhint %}

See also: [Track Workflow Request](#track-workflow-request)

## Feedback and surveys

### Collect Session Feedback Comments

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Disabled |

When enabled, the end-of-session feedback survey includes an optional free-text comment field in addition to the star rating. When disabled, only the star rating is shown.

Enable this when qualitative feedback would help your support team understand session outcomes beyond a numerical rating.

The comment field prompt is customizable via the `session_feedback_survey_comments_question` message in Conversation Messages. See [Conversation Messages](https://app.gitbook.com/s/ksUDWGr9UTfOpa53PosP/how-to-set-up-an-aiseragpt-bot/add-conversation-messages) for instructions on editing this message.

## Rate limiting and input controls

### Conversation Request Length Limit

| **Type**    | Text field (integers) |
| ----------- | --------------------- |
| **Default** | `1000`                |

Sets the maximum number of characters Aisera accepts in a single user message. When a user sends a message longer than this limit, Aisera skips intent matching and responds with an error message asking the user to rephrase. The conversation remains open and the user can send another message.

This limit applies to chat-based channels only. **Email**, **Listening**, and **EventStudio** channels are exempt regardless of the value configured here.

Lower this value to protect against unusually long inputs that could degrade performance or produce poor intent matches. Raise it if your users regularly send longer messages, such as detailed support descriptions, that should still be processed.

The error message shown to users is customizable via the `conversation_request_length_exceed` message in Conversation Messages. The default is: "The request text size exceeded the permitted limit. Please try again with the request rephrased." See [Conversation Messages](https://app.gitbook.com/s/ksUDWGr9UTfOpa53PosP/how-to-set-up-an-aiseragpt-bot/add-conversation-messages) for instructions on editing this message.

### No Throttle User Emails

| **Type**    | Text field (comma-separated) |
| ----------- | ---------------------------- |
| **Default** | `test@aisera.com`            |

Specifies a comma-separated list of user email addresses that are exempt from request count throttling. Users on this list are never blocked by throttling regardless of how many requests they have made. All other users remain subject to the throttle limit configured for your tenant.

Add emails here for internal test accounts, automation users, or service accounts that need unrestricted access and should not be blocked by your tenant's request quota.

Entering a value here replaces the default entirely. If you want `test@aisera.com` to remain exempt, include it explicitly in your list. Email matching is case-insensitive.

The message shown to throttled users is customizable via the `exceed_throttle_limit` message in Conversation Messages. The default is: "You have reached the maximum number of requests." See [Conversation Messages](https://app.gitbook.com/s/ksUDWGr9UTfOpa53PosP/how-to-set-up-an-aiseragpt-bot/add-conversation-messages) for instructions on editing this message.

### Enable Request Type Fulfilment Filtering

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Disabled |

Controls whether Aisera filters fulfillment options based on the type of request the intent classifier detects. When an intent has multiple fulfillments attached, such as both a flow and a knowledge base article, enabling this setting narrows the response to only the fulfillment type that matches the detected request type. Action-oriented requests surface flows and service catalog items. Information-oriented requests surface knowledge base articles.

If an intent has only one fulfillment type, or if filtering would remove all options, filtering is skipped and all fulfillments are returned.

Enable this when intents with multiple fulfillment types are returning responses that don't match what the user is trying to do. For example, if a user asking to complete a task is receiving a knowledge base article instead of an actionable flow, this setting can correct that behavior.

## Deprecated configurations

### I18N Cluster

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Disabled |

This configuration is deprecated and scheduled for removal.

***

### Enable Not Helpful Feedback

| **Type**    | Checkbox |
| ----------- | -------- |
| **Default** | Disabled |

This configuration is deprecated and scheduled for removal.