Automate SharePoint to Teams with Azure Logic Apps

In modern workplace environments, maintaining real-time visibility over shared assets is critical for document approvals, engineering handoffs, and team collaboration. Manually notifying team members when documentation is updated introduces lag and room for human error.

This guide demonstrates how to architect a low-code, serverless automation pipeline that broadcasts a near-real-time alert to a Microsoft Teams channel whenever a new file is uploaded to a target SharePoint Online document library. We’ll build it twice: first in the Azure portal designer so you understand every moving part, then fully automated from your terminal — no portal — using the Azure CLI, Bicep, and GitHub Copilot.

What You’ll Build (and What It Costs)

• Trigger: A polling SharePoint Online connector that checks a document library for new files on an interval you choose (e.g., every 1–3 minutes). This is the standard connector mechanism; for a true push alternative, see Why polling — and the event-driven alternative below.
• Action: An outbound HTTP POST to a Microsoft Teams Workflows webhook, delivering an Adaptive Card to your target channel.
• Time to build: ~20 minutes in the portal; ~5 minutes once you’ve scripted it.
• Cost: On the Consumption plan you pay per action execution and per trigger poll. Idle polling against an empty library is billed at a low per-check rate, and message delivery only runs when a file actually lands. For a single low-volume library this is typically pennies per month — but model your own poll frequency and upload volume before assuming.

Azure Logic Apps and Microsoft Teams Architectural Flow

Why polling — and the event-driven alternative

A fair question: isn’t there a push trigger that fires the instant a file lands, instead of checking every few minutes? The short answer is that the SharePoint managed connector has no push trigger — and, importantly, Power Automate works exactly the same way. Its “When a file is created” trigger uses the same connector and also polls; Microsoft states it plainly: “SharePoint doesn’t send a notification to Power Automate when an item is created or modified. Power Automate polls the SharePoint directory to look for changes.” So switching to Power Automate would not buy you push — you’d inherit the same polling model.

True event-driven delivery is possible, but it lives outside the connector. You replace the polling trigger with a Logic App Request trigger (“When an HTTP request is received”), which gives you a public HTTPS endpoint, and then subscribe that endpoint to one of:

• Microsoft Graph change notifications on the document library’s driveItem resource, or
• Classic SharePoint webhooks registered on the list/library.

Either way, SharePoint/Graph then pushes a notification to your Logic App the moment something changes. The catch is the operational overhead that the managed connector hides from you:

For this tutorial, polling is the right default: it’s simpler, it’s idiomatic, and it’s the very same mechanism Power Automate uses. Reach for Graph change notifications only when sub-minute latency or poll volume genuinely matters — and budget for the subscription-renewal and delta-query plumbing that comes with it.

Infrastructure Requirements

To implement this solution, ensure you possess the following access rights and environments:

• Azure Subscription: An active subscription with permission to create resources in a resource group.
• SharePoint Online Site: A site (e.g., IT support team) containing a document library, and an account that can read that library (the connector signs in as you).
• Microsoft Teams: Membership of the target team/channel (e.g., the evening team channel) and permission to create Workflows in your tenant. The “Post to a channel when a webhook request is received” template uses the standard request trigger — it is not a premium flow.

Step 1: Deploying the Azure Logic App Resource

1. Sign in to the Azure portal.
2. In the global search bar, type Logic Apps, select it under Services, and click Add.
3. Hosting plan: Select Consumption (Multi-Tenant). This plan has the fastest setup and a pure pay-per-execution model, which is ideal for lightweight, event-driven tasks. Click Select.

4. Resource details:

5. Click Review + create, verify your parameters, then Create.

Step 2: Initializing the SharePoint Online Trigger

When deployment finishes, click Go to resource, then under Development Tools open the Logic App Designer.

1. Click Add a trigger.
2. Search for SharePoint and select the native managed SharePoint connector.
3. Choose When a file is created (properties only). (Avoid “created or modified” unless you also want edits to fire a notification, and use “created in a folder” only if you must scope to a single subfolder.)
4. Authenticate the connection. The first time you use the connector, Logic Apps prompts you to Sign in. This creates an API connection resource that stores the OAuth authorization the workflow uses to read SharePoint. Sign in with an account that can see the target library.
5. Configure the trigger parameters:
   • Site Address: Select your target site (e.g., IT support team).
   • Library Name: Select your target library (e.g., the default Documents library).
   • Folder (optional): Leave blank to watch the whole library, or pick a subfolder to scope it.

Step 3: Provisioning the Microsoft Teams Workflows Webhook

This is the step that replaces the retired Incoming Webhook connector. You’ll create a Teams Workflow that exposes an HTTP endpoint and posts whatever it receives into your channel.

1. In Microsoft Teams, click the ellipsis (...) next to your target channel (e.g., evening team) and choose Workflows. (Alternatively, open the Workflows app from the left rail and click + New flow.)
2. Select the template Post to a channel when a webhook request is received. If it isn’t in the featured list, search for it.
3. Give the flow a name (e.g., SharePoint upload notifier), confirm you’re signed in, and click Next.
4. Select the Team and Channel that should receive the messages, then click Add workflow / Create flow.
5. Copy the generated POST URL and store it somewhere safe. This URL is a secret — anyone who has it can post to your channel.

Step 4: Configuring the Outbound HTTP Action

Return to the Logic App Designer to connect the trigger to the Teams endpoint.

1. Under the SharePoint trigger, click + → Add an action.
2. Search the Built-in tab for HTTP and select the plain HTTP action.

3. Configure the HTTP action:
   • Method: POST
   • URI: Paste the Workflows webhook URL from Step 3.
   • Headers: Content-Type → application/json
   • Body: Use the Adaptive Card envelope below. Insert the File name with extension dynamic-content token where shown — selecting it from the picker produces the @{triggerBody()?['{FilenameWithExtension}']} expression automatically.

{
  "type": "message",
  "attachments": [
    {
      "contentType": "application/vnd.microsoft.card.adaptive",
      "content": {
        "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
        "type": "AdaptiveCard",
        "version": "1.4",
        "body": [
          {
            "type": "TextBlock",
            "size": "Medium",
            "weight": "Bolder",
            "text": "📄 New file uploaded to SharePoint"
          },
          {
            "type": "TextBlock",
            "wrap": true,
            "text": "File name: @{triggerBody()?['{FilenameWithExtension}']}"
          }
        ]
      }
    }
  ]
}

4. Click Save in the designer toolbar to commit the workflow.

Step 5: Validation and Runtime Verification

Run an end-to-end test:

1. Open your SharePoint document library (and the specific subfolder, if you scoped the trigger to one).
2. Upload a file (e.g., test-document.docx) via Upload → Files or drag-and-drop.
3. Open the target Teams channel (evening team).
4. Because the trigger polls, wait up to one polling interval for the run to fire.

Once the Adaptive Card appears in your channel with the correct file name, your pipeline is live.

Troubleshooting

Starting From a Different Trigger: A Microsoft 365 Cheat-Sheet

The pattern in this guide is trigger → post to Teams. The action half rarely changes — you can reuse the exact HTTP-to-Teams step from Step 4 no matter what starts the workflow. What changes is the trigger, and the single most important thing to know before you pick one is whether it pushes (fires the instant something happens) or polls (checks on a schedule, so there’s built-in latency).

Here’s how the common Microsoft 365 starting points actually behave in Logic Apps (the same connectors, and the same push/poll behavior, that Power Automate uses):

Adapting the workflow to a new starting point

Whichever trigger you choose, only two things change versus this guide:

• The trigger block — swap the SharePoint trigger for your chosen one and sign into its connection.
• The dynamic-content tokens in the Adaptive Card — e.g., for an email trigger show the Subject and From; for a Teams message show the message body and sender. The HTTP-to-Teams action itself is unchanged.

For example, a shared mailbox → Teams alert would keep Step 4 exactly as-is and only change the card text to something like New email from @{triggerBody()?['from']} — @{triggerBody()?['subject']}. Let Copilot do the rewrite:

Copilot Chat prompt — repoint the trigger

“Take my workflow.json and replace the SharePoint trigger with the Office 365 Outlook ‘When a new email arrives in a shared mailbox (V2)’ trigger for the mailbox support@contoso.com, polling every 3 minutes. Keep the HTTP-to-Teams action identical, but change the Adaptive Card text to show the email’s subject and from. Note in a comment that this trigger polls and has no push option.”

Fully Automated Build — No Portal Required

Everything above can be provisioned without a single Azure portal click. There are two parallel ways to do it, and they produce the exact same result:

• The terminal path (this section) — Azure CLI + GitHub Copilot, scripted and repeatable. Best when you want Infrastructure-as-Code and CI/CD.
• The VS Code path (its own section below: Or Build It Visually in VS Code) — the Azure Logic Apps extension with a visual designer. Best when you’d rather click than write JSON.

Both share the same Teams webhook URL, the same SharePoint connection consent, and the same Copilot prompt library — so the VS Code section only covers what’s different, and points back here for the rest. This guide assumes you already have an Azure subscription and GitHub Copilot available both in VS Code and as the Copilot CLI.

The one click you can’t avoid

The Teams Workflows webhook URL is created inside Teams/Power Automate and is interactive to provision. Create it once (Step 3 above), copy the URL, and treat it as an input to the automation. Likewise, the SharePoint API connection needs a one-time OAuth consent. Everything else — resource group, connection resource, workflow definition, and deployment — is fully scriptable and repeatable. I’ll flag those two human-in-the-loop moments honestly as we go.

Your toolbelt

# Azure CLI + the (experimental) Logic Apps extension
az version
az extension add --name logic        # enables: az logic workflow create/show/list/update/delete

# GitHub Copilot CLI (agentic) — needs Node.js 22+
npm install -g @github/copilot
copilot --version                     # launch with: copilot   (then /login)

# OR the older GitHub CLI Copilot extension (suggest/explain)
gh extension install github/gh-copilot
gh copilot --help

In VS Code, install:

• Azure Logic Apps (Consumption) (ms-azuretools.vscode-logicapps) — browse, create, edit, and deploy Consumption logic apps without the portal.
• Azure Tools / Azure CLI Tools — for az IntelliSense and .azcli scratch files.
• GitHub Copilot + Copilot Chat — to generate and refine the artifacts below.

Set up your project folder first

Before running any commands, make a folder to hold your files. This folder is your project — keeping everything in one place (and under version control) is what makes the automation reproducible.

mkdir sharepoint-teams-notify && cd sharepoint-teams-notify
git init      # optional, but recommended

You’ll create just a handful of plain-text files here:

sharepoint-teams-notify/
├── workflow.json     # the Logic App definition (trigger + action)
├── main.bicep        # Infrastructure-as-Code (optional — Path 2 below)
├── main.bicepparam   # parameter values for the Bicep deploy
└── .gitignore        # keep secrets out of source control

Add a .gitignore so the secret webhook URL and local cruft never get committed:

*.env
local.settings.json
.azure/

Mental model for newcomers: the files in this folder are your source of truth; Azure runs a copy of them. You push changes up by deploying, and pull the live version back down by exporting (both shown below). Keep the Teams webhook URL in an environment variable or Key Vault — not in these files.

Step A — Sign in and create the resource group

az login
az account set --subscription "<your-subscription-id>"

az group create \
  --name rg-demo-automation \
  --location westeurope

Step B — Author the workflow definition (let Copilot write it)

A Consumption logic app is just a JSON workflow definition plus a parameters block. Rather than hand-writing it, open VS Code and ask Copilot Chat to scaffold it.

Copilot Chat prompt — generate the workflow definition

“Create an Azure Logic Apps Consumption workflow definition JSON file named workflow.json. The trigger is the SharePoint ‘When a file is created (properties only)’ managed connector, polling every 3 minutes, referencing a connection named sharepointonline via @parameters('$connections'). Add one HTTP action (not HTTP Webhook) that POSTs to a teamsWebhookUrl workflow parameter with Content-Type: application/json and a Teams Adaptive Card message envelope whose TextBlock shows @{triggerBody()?['{FilenameWithExtension}']}. Include the $connections and teamsWebhookUrl parameters. Wrap it as { "definition": { ... }, "parameters": { ... } } so it’s compatible with az logic workflow create --definition.”

The result should look close to this (your exact SharePoint trigger path/dataset encoding is connector-generated — verify it against the designer’s Code view or let the VS Code Logic Apps extension produce it):

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "$connections": { "type": "Object", "defaultValue": {} },
      "teamsWebhookUrl": { "type": "String", "defaultValue": "" }
    },
    "triggers": {
      "When_a_file_is_created_(properties_only)": {
        "type": "ApiConnection",
        "recurrence": { "frequency": "Minute", "interval": 3 },
        "inputs": {
          "host": { "connection": { "name": "@parameters('$connections')['sharepointonline']['connectionId']" } },
          "method": "get",
          "path": "/datasets/@{encodeURIComponent(encodeURIComponent('https://contoso.sharepoint.com/sites/ITSupport'))}/tables/@{encodeURIComponent(encodeURIComponent('Documents'))}/onnewfileitems"
        }
      }
    },
    "actions": {
      "Post_to_Teams": {
        "type": "Http",
        "runAfter": {},
        "inputs": {
          "method": "POST",
          "uri": "@parameters('teamsWebhookUrl')",
          "headers": { "Content-Type": "application/json" },
          "body": {
            "type": "message",
            "attachments": [
              {
                "contentType": "application/vnd.microsoft.card.adaptive",
                "content": {
                  "type": "AdaptiveCard",
                  "version": "1.4",
                  "body": [
                    { "type": "TextBlock", "weight": "Bolder", "text": "📄 New file uploaded to SharePoint" },
                    { "type": "TextBlock", "wrap": true, "text": "File name: @{triggerBody()?['{FilenameWithExtension}']}" }
                  ]
                }
              }
            ]
          }
        }
      }
    },
    "outputs": {}
  },
  "parameters": {
    "$connections": {
      "value": {
        "sharepointonline": {
          "connectionId": "/subscriptions/<sub>/resourceGroups/rg-demo-automation/providers/Microsoft.Web/connections/sharepointonline",
          "connectionName": "sharepointonline",
          "id": "/subscriptions/<sub>/providers/Microsoft.Web/locations/westeurope/managedApis/sharepointonline"
        }
      }
    },
    "teamsWebhookUrl": { "value": "<paste-your-Teams-Workflows-webhook-URL>" }
  }
}

Step C — Create and authorize the SharePoint connection

The workflow references a Microsoft.Web/connections resource named sharepointonline. You can create it from the CLI, but the SharePoint connector needs an interactive OAuth consent before it will return data — this is the second (and last) human-in-the-loop moment.

Copilot CLI prompt — scaffold the connection command

copilot
# then, in the session:
> Generate an `az resource create` command that creates a Microsoft.Web/connections
> resource named "sharepointonline" in resource group rg-demo-automation, region
> westeurope, bound to the managed API "sharepointonline". Then tell me how to
> authorize the connection's OAuth consent from the CLI or a consent link.

After the connection resource exists, open it once to grant consent (the consent link appears in the connection’s Edit API connection blade, or VS Code’s Logic Apps extension will prompt you on first run). This is a one-time action per connection.

Step D — Deploy without the portal (two supported paths)

Path 1 — az logic (fastest):

az logic workflow create \
  --resource-group rg-demo-automation \
  --location westeurope \
  --name la-sharepoint-teams-notify \
  --definition workflow.json

Path 2 — Bicep + az deployment (repeatable, production-grade): ask Copilot to convert the same resources into IaC.

Copilot Chat prompt — generate Bicep

“Write a main.bicep that deploys: (1) a Microsoft.Web/connections resource for the sharepointonline managed API, and (2) a Microsoft.Logic/workflows Consumption resource whose definition is the workflow above, wiring parameters.$connections.sharepointonline to the connection’s resource ID and exposing teamsWebhookUrl as a @secure() parameter. Add a main.bicepparam file. Then give me the az deployment group create command that passes teamsWebhookUrl from an environment variable so the secret never lands in source control.”

az deployment group create \
  --resource-group rg-demo-automation \
  --template-file main.bicep \
  --parameters main.bicepparam \
  --parameters teamsWebhookUrl="$TEAMS_WEBHOOK_URL"

Step E — Verify and manage from the CLI

# Confirm it deployed
az logic workflow show \
  --resource-group rg-demo-automation \
  --name la-sharepoint-teams-notify \
  --query "{name:name, state:state, location:location}" -o table

# List all workflows in the group
az logic workflow list --resource-group rg-demo-automation -o table

# Disable / re-enable without deleting
az logic workflow update -g rg-demo-automation -n la-sharepoint-teams-notify --state Disabled

Keeping local and Azure in sync

This is the part that most often confuses new starters, because it behaves differently depending on your plan — and this guide uses Consumption.

Consumption (this guide): one source of truth, no local runtime. A Consumption logic app cannot run on your laptop — there is no local engine to execute it. So “sync” simply means your workflow.json/Bicep is the source of truth, and you move it one direction at a time:

• Push (local → Azure): deploy with az logic workflow create/update or az deployment group create (Step D). This overwrites the cloud copy with your file.
• Pull (Azure → local): export the live definition back into your file so the two match — useful if someone edited the workflow in the portal:

az logic workflow show \
  --resource-group rg-demo-automation \
  --name la-sharepoint-teams-notify \
  --query "definition" -o json > workflow.json

The VS Code Azure Logic Apps (Consumption) extension blurs this slightly: when you open a logic app from the Azure view and edit it in the designer, you’re editing the cloud resource directly and saving back to Azure — convenient, but it isn’t a local project you can run offline.

Standard (if you want true local development). If “build and debug on my machine, then sync to Azure” is what you’re really after, that’s a Standard logic app capability, not Consumption. Standard stores each workflow as a workflow.json inside a local project folder, runs locally via the Azure Functions Core Tools (func start), and deploys through the Azure Logic Apps (Standard) VS Code extension or zip deploy. Microsoft even ships an Export from Consumption to Standard path in that extension if you start here and outgrow the multi-tenant model. The trade-off is a hosting-plan bill instead of pure pay-per-execution.

A starter prompt library for GitHub Copilot

Copy-paste these to reproduce (or extend) the whole solution:

• Scaffold: “Generate a complete Azure Logic Apps Consumption workflow.json that posts a Teams Adaptive Card via an HTTP action whenever a file is created in a SharePoint library; parameterize the Teams webhook URL and the SharePoint connection.”
• IaC: “Convert workflow.json into main.bicep + main.bicepparam with a @secure() Teams webhook parameter and a Microsoft.Web/connections resource for SharePoint.”
• Deploy: “Give me the exact az commands to log in, create resource group rg-demo-automation in westeurope, and deploy this Bicep, reading the webhook URL from $TEAMS_WEBHOOK_URL.”
• Harden: “Refactor the Bicep to store the Teams webhook URL in Azure Key Vault and reference it via a Key Vault getSecret instead of a plain parameter.”
• Extend: “Add a Condition so the notification only fires for files whose extension is .docx or .pdf, and include the uploader’s display name in the Adaptive Card.”
• Debug (Copilot CLI): gh copilot suggest "az command to show the last 5 runs and failures for a Consumption logic app"

Once az logic workflow show reports state: Enabled and a test upload produces an Adaptive Card in your channel, you have a fully reproducible, portal-free SharePoint-to-Teams notification pipeline — authored, deployed, and managed entirely from the command line.

Or Build It Visually in VS Code (No Portal)

If you’d rather use a designer than hand-edit JSON, the Azure Logic Apps (Consumption) VS Code extension builds the same pipeline — trigger, action, and all — without the portal. This section covers only what’s different from the terminal path; for anything not mentioned here (the Teams webhook URL, the SharePoint OAuth consent, the Copilot prompt library, and the sync model), use the terminal section above.

What you’ll need: the Azure Logic Apps (Consumption) extension (ms-azuretools.vscode-logicapps) and GitHub Copilot — both already in your toolbelt. You won’t need to write workflow.json or Bicep by hand.

1. Sign in to Azure inside VS Code. In the Azure view, sign in — this replaces az login from Step A. No separate terminal session required.
2. Create the logic app from the extension. Right-click your subscription → Create Logic App, then pick the resource group, name, and region in the command palette. This replaces az group create + the deploy in Steps A and D.
3. Build the trigger and action in the designer. Add the SharePoint “When a file is created (properties only)” trigger and the HTTP POST action exactly as in the portal walkthrough (Steps 2 and 4 of the main guide). The key VS Code advantage: the extension handles the SharePoint connection sign-in inline, so the one-time OAuth consent from terminal Step C just happens when you first authenticate — there’s no separate connection resource to create.
4. Reuse the Teams webhook URL. Paste the same Workflows webhook URL from Step 3 of the main guide into the HTTP action’s URI, with the same Adaptive Card body from Step 4. Creating that URL in Teams is still the one unavoidable manual step.
5. Deploy and debug without the portal. Right-click the logic app → Deploy / Upload, then watch Run history in the same Azure view to confirm runs and inspect failures.

How this path differs from the terminal path:

Either way it’s still a Consumption logic app — so there’s no local runtime, and the same push/pull rules from Keeping local and Azure in sync apply. When a test upload lands an Adaptive Card in your channel, you’ve built the entire pipeline without ever opening the Azure portal.