Outlook FAQ

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.