If you change the subject line of an email in an Outlook conversation, Outlook treats the modified message as the start of a new, separate conversation. This means the original thread is split: messages with the old subject stay in one thread, while messages with the new subject appear in another.

Because Tekst relies on the conversation ID that Outlook assigns to group messages into threads, a subject change in Outlook results in:

• Separate threads in your message feed - the original conversation and the renamed one show up as two distinct threads.
• Separate processing runs - each thread is processed independently by your AI models.
• Multiple automation runs - automations that trigger on incoming messages will run separately for each thread, potentially causing duplicate actions such as repeated replies, label assignments, or ticket creation.
• Split conversation history - context from the original thread is not carried over to the new one.

Why this happens

Outlook uses the email subject line as a key component of its conversation ID (also called the thread ID). When you modify the subject, Outlook generates a new conversation ID for that message and any future replies to it. This is a limitation of how Outlook handles email threading - it is not something Tekst can override or work around.

Microsoft's recommendation

Microsoft recommends that users do not change the subject line of an ongoing email conversation. In fact, newer versions of Outlook (desktop and web) have removed the ability to edit the subject line of a reply for exactly this reason. Microsoft recognizes that changing the subject breaks the conversation thread and leads to confusion.

Tekst aligns with this recommendation. Keeping the original subject line intact ensures that all messages in a conversation are grouped correctly in both Outlook and Tekst.

What to do if this has already happened

If a subject change has already split a conversation, the threads cannot be merged back together in Tekst. You can still view both threads individually in your message feed by searching for the sender or keywords from the conversation.

To prevent this from happening in the future:

• Do not modify the subject line when replying to or forwarding an email within an existing conversation.
• Start a new email if you genuinely need a different subject - this makes the intent clear and avoids confusion.
• Update to a newer version of Outlook if your organization is still using an older version that allows subject editing on replies.

Related articles

• Why is the same email appearing in multiple threads?

Salesforce imposes a character limit on the HTML body of emails. To ensure that your emails are successfully delivered and displayed in Salesforce, our platform automatically handles emails that exceed this limit. This article explains how we process oversized HTML emails and what to expect in the user interface.

How it works

When an email's HTML body is too long for Salesforce, our system initiates an automatic cleaning process. This process involves two main steps:

1. Soft HTML Clean: The system first attempts to simplify the email's HTML by removing unnecessary code while preserving the original formatting as much as possible.
2. Plain Text Conversion: If the soft clean is not enough to meet Salesforce's requirements, the system converts the email to plain text.

This process may result in the removal of inline images. If an email is converted to plain text, inline images will not be displayed in Salesforce.

What you will see in the UI

In the Tekst platform, you will still be able to see the content of the email, even if it has been shortened. Here's what to expect:

• Cleaned Preview: The user interface will show a cleaned, shortened preview of the email.
• Expand Option: If the email content is split into multiple parts, you will see an "Expand all" option to view the rest of the content.
• Original HTML View: You can still access the original HTML view by selecting the "Show Original" option. However, please note that if Salesforce has truncated the HTML, this view will only show the content that was successfully synced.

If you notice that images are missing from an email in Salesforce, it is likely due to the HTML body limit and our automatic cleaning process. To view the original email with images, you can check the original email in your email client.

Some users have asked whether the capitalization of Outlook labels matters for topic routing in Tekst. For example, if a label is "Service Claim" in one mailbox and "Service claim" in another, will they be treated as the same topic?

The short answer is: No, capitalization does not matter. Our system treats labels in a case-insensitive manner. "Service Claim" and "Service claim" will be routed to the same topic.

While the system handles capitalization differences, we recommend establishing a consistent naming convention for your labels. This will make it easier for your team to manage and understand the topics.

Best Practices for Labeling

• Be consistent: Try to use the same capitalization and naming convention across all mailboxes.
• Be specific: Use clear and descriptive names for your labels. For example, instead of "Claim," use "Service Claim" or "Insurance Claim."
• Keep it simple: Avoid using special characters or long names for your labels.

If you're seeing the same email appear in multiple threads on your dashboard, it's likely due to how the email was routed to your inboxes. Our platform creates a unique thread for each inbox an email is delivered to. This means that if an email is sent to multiple addresses, or forwarded from one inbox to another, it will appear as a separate thread for each instance.

This is the intended behavior of our system and not a bug. It ensures that every instance of an email is tracked, regardless of how it arrived in your inboxes.

How to identify the cause

To confirm that duplicate threads are being caused by your email routing, you can check the inbox associated with each thread. Here's how:

1. Open one of the duplicate threads in your dashboard.
2. Check the inbox name associated with the thread. You can usually find this information near the top of the thread view.
3. Open the other duplicate thread and check the inbox name.
4. If the inbox names are different, it confirms that the email was delivered to multiple inboxes, resulting in separate threads.

How to prevent duplicate threads

To prevent the same email from appearing in multiple threads, you'll need to adjust your email forwarding rules. The goal is to ensure that an email is only delivered to one inbox that is monitored by our platform.

Modifying your email forwarding rules can affect how your emails are delivered. Make sure you understand the changes you're making before proceeding. If you're unsure, consult with your email administrator.

Here are some general steps you can take:

• Review your forwarding rules: Check the forwarding rules in your email client (e.g., Outlook, Gmail) to see if any rules are causing emails to be sent to multiple inboxes that are connected to our platform.
• Use a single destination inbox: If possible, have all relevant emails forwarded to a single inbox that is monitored by our platform. This will ensure that each email creates only one thread.
• Use email groups or aliases carefully: If you use email groups or aliases, make sure they are configured to avoid sending duplicate emails to multiple monitored inboxes.

For more information on how to manage your email settings, please refer to the documentation for your email provider.

Related articles

• Outlook prerequisites
• Connecting extra mailboxes from Outlook

This guide will explain the dual method-approach used by Tekst to keep mailboxes up-to-date. This 

Real-time webhooks (primary)

When you connect a mailbox, Tekst registers Microsoft Graph API subscriptions to monitor:

• New emails created in Inbox
• Updates to existing emails (e.g., read status, categories)
• Sent Items folder changes

Webhooks deliver notifications within 5 minutes of changes. Subscriptions auto-renew every 6 hours to maintain continuous monitoring (Microsoft Graph subscriptions expire after 3-30 days depending on resource type).

Polling fallback (backup)

If webhooks fail renewal after 3 retry attempts, Tekst automatically switches to hourly polling:

• Queries messages received since last successful sync using receivedDateTime filter
• Processes up to 400 email threads per batch
• Continues until webhooks re-establish or manual reconnection occurs

Delta sync and state management

After initial backfill, Tekst uses Microsoft Graph delta queries to fetch only changed items, storing a delta token for each mailbox to minimize API calls and improve performance.

Real-time sync reduces manual triage time by up to 200% for shared inboxes by enabling immediate AI categorization and workflow triggers.

Tekst processes customer data using a streaming architecture: the content of emails, tickets, and cases is handled ephemerally and never stored permanently. This article explains what metadata Tekst does store, how the feedback loop works, and how models are retrained.

What Tekst stores vs. what it does not store

Tekst does not persist any PII, message content, or confidential information. All content is processed in real time and discarded after classification.

However, Tekst does store metadata that is essential for monitoring and improving model performance:

• Prediction values: The category, tag, or assignment the model predicted.
• Feedback signals: Whether an agent accepted or corrected the prediction (also called "relabeling").
• Identifiers: Ticket/case IDs and integration IDs (no content).
• Timestamps: When the prediction was made and when feedback was received.
• Model metadata: Model version, confidence score, and accuracy metrics.

This metadata contains no message body text, attachments, customer names, or other personal data.

How the feedback loop works

The learning process relies on a real-time feedback loop between Tekst and the customer's platform (e.g., Salesforce, SAP CEC, Outlook):

Step 1: Real-time classification

When a new ticket or email arrives, the customer's platform sends an event to Tekst. Tekst reads the content via API, runs its AI models, and writes the predictions (category, assignment, priority) back to the platform. The content is processed in memory and not stored. Only the prediction metadata is persisted.

Step 2: Feedback capture

When an agent reviews the ticket and changes a field that Tekst predicted (e.g., selects a different category), the customer's platform sends an update or closure event back to Tekst. Tekst records only the final metadata values and compares them to its original prediction. This tells Tekst whether it was correct or whether the agent made a correction.

Step 3: Model retraining

The accumulated feedback metadata is used to evaluate model accuracy. Retraining is not scheduled on a fixed cadence (e.g., nightly). Instead, it is triggered by two conditions:

1. Accumulated corrections: Enough new feedback has been collected to meaningfully improve the model.
2. Accuracy drop: Automated monitoring detects that model performance has declined.

During the initial onboarding phase, retraining happens more frequently to rapidly build accuracy. Once the model is stable, retraining occurs only when one of the above conditions is met. Retraining typically takes between 1 and 12 hours depending on model complexity.

Why update/closure hooks are needed

The webhook or API notification that the customer's platform sends back to Tekst (e.g., "case updated" or "case closed") is critical for the learning process. Without it, Tekst would have no way to know whether its predictions were accepted or corrected by the agent. These hooks transmit only metadata (final field values, IDs, timestamps), not ticket content.

Related articles

• How often are the AI models retrained?
• How is model accuracy calculated?

Monitoring model and tag accuracy ensures your models and, therefore, your automations are performing as well as possible.

Prerequisites

In order to view model and tag accuracy, you need first to have:

• A classification model (model accuracy is not yet supported for entity extraction models).
• Correct filled in feedback rules.

About the confidence level

In order to make sure the model and tag accuracy is as accurate as possible, a confidence level is used. This confidence level is based on the amount of feedback that was received for a certain tag (with feedback being the correction or verification of a tag prediction).

Confidence = Messages with feedback / All messages

Example: Tag is predicted 1000 times, and 500 times the prediction is followed with feedback. Confidence level = 50%.

Important to note is that there is also an absolute minimum of feedback that is needed:

• For model accuracy: 100 messages with feedback.
• For tag accuracy: 10 messages with feedback.

The time period for including feedback in the confidence calculation is the past 30 days or until the last training date if this is less than 30 days ago.

About the accuracy percentage

Accuracy percentage is calculated as an F1-score, which is a combination of Recall and Precision percentage.

Recall = Correct messages with tag / All messages with tag

“Of all messages that should have this tag, what percentage did we correctly identify?”

• 1000 messages with feedback tag X

• Of which 800 correctly predicted

→ 800 correct messages / 1000 messages = 0.80 (80%)

Precision = Correct predictions with tag / All predictions with tag

“Of all messages we tagged with this label, what percentage were correct?”

• 1000 predictions tag X

• Of which 800 have correct feedback

→ 800 correct predictions / 1000 predictions = 0.80 (80%)

F1 = 2 * (Recall * Precision) / (Recall + Precision)

About tag confusion

Within the side panel of a model or tag it is possible to see exactly how tags are mispredicted using the tag confusion. This shows on the left the original tag that was predicted and on the right the correct tag, together with the frequency of this confusion happening.

Note that confusion follows the same time window as confidence, the past 30 days or until the last training date if this is less than 30 days ago.

To maximize processing speed and minimize the risk of failures or delays, our platform uses an intelligent, dynamic method for selecting which AI models to use for real-time processing tasks.

How it works: Instead of using all available models, the system dynamically selects the most essential ones needed for a specific task. This ensures faster, more reliable performance for all real-time operations.

How model selection works

Our AI system has a comprehensive suite of models that work together in a processing block. However, not all of these models are required for every task.

• Real-time Processing: For tasks that require an immediate response, our system intelligently selects a smaller, optimized set of models. This selection is based on the specific requirements of the task at hand, ensuring rapid and accurate results.
• Simulations & Non-real-time tasks: For processes like simulations, analytics, or model training, the system utilizes all models within the processing block. These tasks are not subject to the same strict time constraints, allowing for more extensive, in-depth analysis.

What about the other models? Even if a model isn't selected for a real-time task, its predictions are still generated. These predictions are processed without a real-time constraint, ensuring that all data is eventually processed comprehensively.

What's next

To learn more about our AI models, you can read these related articles:

• How often are the AI models retrained?
• How to monitor model retraining status

The training of custom models is fully managed by Tekst. Every customer has multiple models that are constantly monitored for performance. Customers will be able to validate the accuracy of the models in the Tekst portal. Tekst has built a pipeline where accuracy and feedback trigger automatic retraining.

Frequency depends on the accuracy drops. During the start of the project, models will be continuously retrained to achieve an already high accuracy before going live as this will be crucial gain end-user's trust.

If a new open source model becomes available, Tekst will test this model internally to validate performance. Once done, we evaluate which customer could benefit from the newest model.

At Tekst it is our main goal that every customer has at all times the best available and trained model for its business case.

Monitor the model retraining status

You can monitor the progress of your model retraining to know when it's complete. This article explains how to find the status of your retraining jobs and provides information on timelines and notifications.

Prerequisites

• You must have initiated a model retraining through support.
• You have made changes that need to be incorporated.
• The overall accuracy is too low and triggers a retrain.

Steps

1. Navigate to the Models section in the Tekst platform.

2. Select the model you want to monitor.

3. In the top overview bar you will see the status of the retraining job. The status will indicate if the job is in progress, completed, or has failed.

   

Typical Timeline

Model retraining typically takes between 1 to 12 hours to complete. However, this timeline can vary depending on the complexity of the model and the amount of data being processed.

We recommend checking the status of your retraining job periodically for the most up-to-date information.

Once the retraining is complete, you can view the updated model in the "Models" section.

Tekst supports all languages, including those with Cyrillic and Uralic alphabets such as Hungarian and Bulgarian. We have multiple successful EMEA-wide (and worldwide) deployments that cover these languages.

Tekst AI models support the following exhaustive but not extensive list of languages. If a language does not appear in this list, please contact support to verify if your language is supported.

Note that the Tekst platform itself is English-only.

Tekst is capable of processing a wide variety of file types. This article provides a comprehensive list of all supported file formats and any limitations associated with them.

Supported File Types

What's next

• Learn more about connection methods

Getting help

If you have any questions or encounter issues with file attachments, please don't hesitate to contact our support team for assistance.