Skip to main content

​
1. How the integration works

  • Traversal provides a registered Microsoft app (an Azure AD app plus Azure Bot). Your Teams admin uploads it to the org catalog — your organization decides where Traversal participates: it acts only on mentions, configured triggers, or Workers your team has enabled.
  • Processing: the mention kicks off an incident investigation on Traversal’s backend. The analysis runs against your connected observability tools (for example, Datadog — a separate integration), not your Teams content. Teams is the chat surface, not the primary data source. Users can also set up triggers to run investigations automatically.
  • Outbound: Traversal authenticates to Microsoft as its registered app (MSAL client-credentials) and posts the result back.

​
2. What data we capture from Teams

Traversal captures data only from the channels and conversations where the bot can be used. Limited to the chat surface, and only for messages the bot is party to:
  • Message content of messages that mention the bot, match a trigger, or that a Worker follows in a team or chat Traversal is added to — the text the user typed (the incident description), plus any attached files/images if provided.
  • Conversation identifiers — channel, thread, team, tenant, and message IDs — used to reply in the right place and identify the install.
  • Channel/thread context — channel name and, when investigating a thread, prior messages in that thread.
  • Sender identity — see §3.
  • Install metadata — tenant ID, bot service endpoint, app IDs.
We do not ingest the entire workspace or message history at large.

​
3. PII / user information & handling

  • What user info is involved: the sender’s Azure AD user ID, and their display name / email (resolved to attribute the request).
  • Handling:
    • Data is scoped per customer (per install / organization); cross-tenant access is prevented by design.
    • Bot credentials are stored encrypted (AWS Secrets Manager); data is stored in Traversal’s cloud (AWS, United States).
    • Microsoft is a sub-processor specifically to power the Microsoft Teams integration.
    • Least-privilege Microsoft permissions; inbound validated (Microsoft-signed JWT), outbound app-authenticated.
    • Running an investigation sends relevant context (including the incident description) to Traversal’s third-party LLM providers. We have zero-data-retention agreements with our LLM providers — no data is retained by the provider. Traversal may retain LLM inputs/outputs to improve the product (default 2 years, configurable). See Security & compliance → LLMs for tenancy/residency.

​
4. Permissions requested

Bot identity + messaging (not a Graph permission): a registered Azure AD app + Azure Bot with the Microsoft Teams channel enabled, installed by an admin. Traversal requests two kinds of Microsoft Graph permissions: Application permissions are optional for core functionality. On a team, chat, or meeting where the matching RSC permission is granted, Microsoft Graph allows that scoped read without the tenant-wide permission. Features with no RSC equivalent need the application permission.

​
Application permissions

Grant these with admin consent.

​
RSC permissions

Declared in the Traversal app package and granted when someone adds Traversal to a team, chat, or meeting. They apply only there.
TeamSettings.Read.Group, ChatSettings.Read.Chat, and ChatMember.Read.Chat have been in the app package since version 1.3.0. The production package is 1.5.0. If you uploaded an older package, upload the new version in the Teams Admin Center and have users accept the update.

​
What works with RSC only

Works wherever Traversal is added:
  • @Traversal investigations
  • Workers following every message
  • Message triggers and new-channel triggers in installed teams
  • Names and members of installed teams and chats
  • Starting a Worker when someone adds Traversal to a matching meeting (app package 1.3.0 or later)
  • Images pasted in messages, and files attached in chats
Needs application permissions:
  • Auto-joining every new meeting or incident bridge (needs Chat.ReadBasic.All, TeamsAppInstallation.ReadWriteAndConsentSelfForChat.All, and AppCatalog.Read.All)
  • A company-wide map of teams and channels
  • Reading channels or chats Traversal isn’t in
  • Looking up people outside the conversation
  • Files attached in team channels

​
Choosing which application permissions to grant

The standard consent screen grants all requested application permissions at once. Afterwards, you can revoke individual permissions in Microsoft Entra admin center → Enterprise applications → Traversal → Permissions, or with Microsoft Graph PowerShell (Remove-MgServicePrincipalAppRoleAssignment). To grant only specific permissions instead, skip the consent screen and assign them with New-MgServicePrincipalAppRoleAssignment. Traversal calls Microsoft Graph with its app token. Consented application permissions are in that token’s roles claim, and Graph also allows a call on a team, chat, or meeting where the matching RSC permission was granted. Consent changes can take up to an hour to take effect, because the app token is cached.
Run as a Global Administrator or Privileged Role Administrator. Replace Team.ReadBasic.All with the permission you want. The app ID below is the production SaaS app. A dedicated deployment uses the app ID from its own package.

​
If RSC is restricted in your tenant

Tenant admins set resource-specific consent for teams and chats with Set-MgBetaTeamRscConfiguration and Set-MgBetaChatRscConfiguration. If either setting is DisabledForAllApps, Microsoft blocks installation of apps that declare RSC permissions. Traversal declares RSC permissions, so it cannot be installed while that setting is on. If the setting is EnabledForPreApprovedAppsOnly, Traversal can be installed only after an admin creates an RSC preapproval policy for it. Preapproval is in public developer preview and may change. -TeamsAppId is the Teams app ID of the uploaded package. For the production package that ID is 60dd587e-57dd-406a-8424-96059aa83967, the same GUID as the Entra client ID, because the manifest id is that app ID. A dedicated deployment uses the app ID from its own package.
Team permissions must end in .Group and chat permissions in .Chat.

​
5. Security & compliance

SOC 2 attestation: https://drive.google.com/file/d/1yuDwxVu8ZaasrUfgv0yOPXGQQP7Bvl7O/view?usp=sharing Sub-processors: Yes. Guidelines for sub-processors: https://docs.google.com/document/d/15qB3eO0ECuZeqnaOWKbCRKA7NogcaKQTVWPc72GZ53I/edit?tab=t.0 Large language models (LLMs):
  • Retention settings: We have zero data retention agreements with our LLM provider — no data is retained by the provider. We may retain LLM input/outputs for the purposes of improving data, with a default of 2 years but configurable.
  • Data tenancy: In SaaS, every prompt/embedding carries an org_id; data, keys, and caches are namespace-isolated, and RLS+IAM block cross-tenant reads. In on-prem, the entire stack runs inside your VPC, eliminating multi-tenant sharing.
  • Data residency: Managed SaaS stays in AWS us-east-1 / us-west-2. All sub-processors are locked to the same geography. LLM providers are also based in the USA.
Data center location(s): United States. Data hosting: Amazon Web Services (AWS). S3 and RDS store relevant data in AWS cloud data centers in the USA. Data retention policy: Our data retention policy is to keep customer data for as long as an account remains active. When an account is voluntarily closed, its data is marked “expired.” Expired data is retained for 30 days and then permanently deleted. Customers should download their data before closing an account. If an account is involuntarily suspended, it becomes inaccessible for a 30-day grace period. During that time, the account can be reopened if payment obligations are met and any Terms-of-Service violations are resolved. After 30 days, the account is closed, its data enters the “expired” state, and it will be deleted 30 days thereafter unless applicable law requires a longer retention period. The Data Retention Schedule is as follows. Corporate records—such as board and committee minutes, corporate seals, articles of incorporation, bylaws, and annual reports—are stored in Google Drive and retained for five years. HR records are retained for five years. Employee personnel records (including attendance, applications, status changes, performance reviews, terminations, withholding information, garnishments, test results, and training and qualification records) are stored in Google Drive. Individual employment contracts are stored in Dropbox. Employment-agency correspondence and job-opening advertisements are stored in Google Drive. Job descriptions and postings are also stored in Google Drive. Log data is typically retained for 15-30 days. CloudWatch logs are stored in AWS CloudWatch and S3, and application logs are stored in Datadog. Data deletion request procedure: An admin opens a ticket with tenant ID and date range; automated tasks erase rows, vectors, S3 objects, and backups, then email a deletion confirmation to the requester. If a user would like to make a request to delete their data, they can email us at security@traversal.com for any of their data concerns. Data archiving and removal policy: When an account is voluntarily closed, its data is marked “expired.” Expired data is retained for 30 days and then permanently deleted. Customers should download any needed data before closing an account. If an account is involuntarily suspended, it becomes inaccessible for a 30-day grace period. During that time, the account can be reopened if payment obligations are fulfilled and any Terms-of-Service violations are resolved. After 30 days, the account is closed; its data is marked “expired” and will be deleted 30 days thereafter, unless applicable law requires a longer retention period. Traversal’s data archival and removal policy requires that hard-copy materials containing sensitive data be destroyed when they are no longer needed for business or legal reasons. Destruction is carried out through secure means—such as shredding, pulping, or incineration—so the data cannot be reconstructed. Prior to destruction, hard-copy materials are kept in secure storage containers. Electronic media that holds sensitive data is destroyed or rendered unrecoverable once it is no longer needed for business or legal purposes. Data on hardware (for example, hard drives) is disposed of through secure methods such as verified wiping or physical drive destruction. Before any equipment is disposed of or reused, Traversal verifies that all storage media has been purged of sensitive data and licensed software. This information is either securely overwritten or completely removed. When using cloud services, Traversal obtains assurances from its cloud providers that they have established policies and procedures for the secure disposal or reuse of resources. Cloud providers engaged by Traversal must ensure timely, secure disposal or reuse of resources—including equipment, data storage, files, and memory. Data storage policy: Traversal’s Data Storage Policy requires that all stored data be properly categorized and assigned a retention schedule in alignment with the Asset Management Policy, Data Classification Policy, and Data Retention Policy. When determining how long to retain data, consider any statutory, regulatory, or contractual requirements; the type of data involved (for example, accounting records, database records, or audit logs); and the storage medium (such as paper, hard drives, or servers). Data must also be properly stored and handled while at rest. In conjunction with the same policies, storage and disposal decisions should account for who is authorized to access or manage the data; clear identification of records and their retention periods; the impact of technology changes on the ability to access data throughout the retention period; acceptable timeframes and formats for retrieval; and appropriate methods of disposal.