Microsoft Teams to Snowflake: How to Move Your Data

Moving Microsoft Teams into Snowflake is worth setting expectations about, because the obvious one is wrong. This connector does not give you channel messages. Airbyte's documentation says so directly: some APIs are not supported in Graph v1.0, channel messages and channel message replies among them.

What you get instead is the structure and usage of your Teams estate: who is in which team, how channels are organised, what is attached to them, and how the product is actually being used. That is a genuinely useful dataset for adoption and licensing work, and a poor substitute if you wanted a conversation archive.

Microsoft Teams to Snowflake at a glance:

Why move data from Microsoft Teams to Snowflake?

Two situations fit this connector, and both are about the shape of your Teams estate rather than its contents.

The first is licensing and adoption. A device usage report tells you how people are actually using Teams, and joining it to your HR data by department or location answers where the rollout has landed and whether the licences you are paying for are being used. That question comes round every renewal.

The second is governance: which teams exist, who belongs to them, which are abandoned. Sprawl in Teams is a common problem and a warehouse is where you measure it. If what you wanted was searchable conversation history, this pipeline does not provide it and you should stop here.

What do you need before you start?

One of these needs somebody with administrator rights, so start it first:

An app registered in the Azure portal. The connector authenticates against Microsoft Graph using OAuth, so you register an application and use its credentials. The Microsoft Teams source documentation links to Microsoft's instructions for creating one.

Application permissions, consented by an administrator. Graph distinguishes delegated permissions, which act as a signed-in user, from application permissions, which run without one. This source requires application permissions, and those can only be consented by an administrator. That is a person you need on the project rather than a checkbox.

A written record of what you granted. Worth more here than usual, because the connector has historically surfaced permission failures without the underlying Graph error. A log saying it could not get channels, with no explanation that privileges were insufficient, is a frustrating thing to debug from scratch.

Snowflake objects and a role. A warehouse, database, schema and a role able to create tables in that schema. Because this data describes employees, use a schema with its own access controls rather than mixing it with general analytics.

If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the Snowflake side before you begin.

How do you build a Teams to Snowflake pipeline in Airbyte?

Step 1: Confirm the streams answer your question

Write down the question somebody asked you, then check it against the stream list. If it is about adoption, membership or sprawl, this connector answers it. If it contains the words what did someone say, it does not, and no configuration changes that. This is a five-minute check that prevents the most common disappointment with this pipeline.

Step 2: Register the app and grant permissions

Create the application in the Azure portal, add the application permissions the documentation lists, and have an administrator consent to them. Grant them all in one pass rather than incrementally, because the poor error reporting makes it hard to tell which one is missing when a stream fails.

Step 3: Configure the source and destination

Click Sources, then New Source, and select Microsoft Teams, following adding a source. Then click Destinations, New Destination, and select Snowflake, following adding a destination, supplying the account identifier, warehouse, database, schema and role.

Step 4: Create the connection and schedule slowly

Click Connections, then New connection, and select streams with a sync mode. Almost everything here changes slowly: teams are created occasionally, membership shifts weekly, tabs rarely. Daily is generous and there is no benefit to more, particularly given the connector is bound by normal Microsoft Graph request limits.

Check every selected stream produced rows after the first sync. Because of the error reporting issue, a stream returning nothing because of a missing permission looks much like a stream returning nothing because there is nothing to return.

Why can't you get channel messages?

Because the connector is built on Microsoft Graph v1.0, and channel messages and their replies are among the APIs not supported there in the form this connector needs. Graph has a beta endpoint with newer capabilities, and taking a production dependency on preview APIs is not recommended, since they can change without notice.

The conversation streams can look like a substitute and are not. They cover the older group conversation model rather than the channel posts people write in Teams today, so a workspace that lives in channels will find them close to empty.

If message content is genuinely what you need, that is a different project: Microsoft offers export and eDiscovery routes designed for it, with the compliance controls such data warrants. Reaching for those deliberately is better than trying to make an analytics connector do a job it was not built for.

How do you turn this into a licensing answer?

By joining the usage report to your HR or identity data, which is the whole reason to put this in a warehouse rather than reading it in the admin centre. Usage on its own tells you a number; usage by department, location or tenure tells you where to act.

Build that join once as a view and define your activity threshold in it, because active is a judgement rather than a field and two teams applying different definitions will disagree about the same dataset. Put the definition somewhere everyone reads from.

Then treat individual-level rows carefully. Licensing and adoption questions work perfectly well on counts by department, so an aggregated view with the detailed tables locked down answers them without putting individual activity in front of everyone with a dashboard.

Frequently asked questions

Can I sync Teams channel messages with this connector?

No. Channel messages and channel message replies are among the APIs not supported in Graph v1.0 as used here. For message content, use Microsoft's own export or eDiscovery routes.

What permissions does the connector need?

Application permissions rather than delegated ones, which can only be consented by an administrator. Plan for that person's involvement rather than expecting to self-serve.

Are the conversation streams the same as channel messages?

No. They cover the older group conversation model rather than the channel posts people write today, so they are often close to empty in a channel-centric workspace.

A stream failed but the log does not say why. What now?

Check permissions first. The connector has historically surfaced Graph permission errors without the underlying cause, so compare what was granted and consented against the documented list.

Can I do this without writing code?

Yes. The Airbyte setup is UI-driven and the Microsoft side is portal configuration. You will want Snowflake views joining usage to your HR data and defining your activity threshold.

Get your Microsoft Teams data into Snowflake

Confirm the streams answer the question you were asked, because message content is not among them. Involve an administrator early for the application permissions, record what you granted, check row counts on every stream after the first sync, and define your activity threshold once in a view.

Airbyte's connector catalog includes 600+ pre-built connectors, so collaboration data can sit beside HR and identity sources. For the same source in a lakehouse, see Microsoft Teams to Databricks, and for the equivalent picture on the Google side, Google Workspace Admin to BigQuery.

Start syncing now →