Skip to content

About

Azure Functions samples showcasing Connector triggers and bindings.

Resources

Code of conduct

Stars

0 stars

Watchers

0 watching

Forks

Repository files navigation

Azure Functions Connector Samples (TypeScript)

TypeScript samples for the Azure Functions Connector Samples repo, using @azure/functions-extensions-connectors to receive events from Microsoft 365, SharePoint, Teams, and other connectors.

Azure Functions connectors and the packages used here are in preview.

Samples

Folder Connector Triggers
azureblobApp Azure Blob Storage Blob added or modified, using the generic API
dataflowsApp Dataflows Refresh completed
genericApp Any connector Generic connectorTrigger<TItem> examples with custom item types; opt-in single-event polling
office365App Office 365 Outlook New, flagged, mentioning-you, and shared mailbox emails; new, updated, changed, and upcoming calendar events; opt-in batched email polling
onedriveApp OneDrive for Business New and updated file content and metadata
plannerApp Planner New, completed, and assigned-to-me tasks
salesforceApp Salesforce New and updated records
sharepointApp SharePoint Online File metadata, file properties, list items, deletions, forms, classification changes, and recurring digests
teamsApp Microsoft Teams Channel/chat messages, mentions, reactions, keywords, recordings, transcripts, and team membership changes
vstsApp Azure DevOps Builds, pull requests, pushes, TFVC check-ins, and work item changes

The ten apps contain 54 webhook sample functions and two opt-in polling functions. The trigger samples cover 39 typed registrations in eight namespaces exported by @azure/functions-extensions-connectors@0.2.0-preview, plus generic examples and two raw OneDrive content handlers. The samples omit two deprecated SharePoint file helpers, one duplicate Office 365 calendar alias, and the Kusto callback helper because Kusto has actions rather than connector triggers.

Each folder has its own dependencies, azure.yaml, host configuration, and source code. The five original connector-specific apps configure connections and triggers through deployment hooks; additional Office 365 and SharePoint subscriptions require the optional settings documented in their READMEs. SharePoint requires its site URL before provisioning and enables five create/update subscriptions by default. Additional Teams webhook inputs are collected interactively after connector OAuth consent. genericApp and the four new apps use manual connector setup. The new apps reuse genericApp's deployment module, so keep the full repository checkout when deploying them.

Use test accounts: these examples log event metadata, including dynamic record fields. Review logging before using production data.

Package versions and API changes

All apps use:

{
  "@azure/connectors": "0.4.0-preview",
  "@azure/functions": "^4.17.1",
  "@azure/functions-extensions-connectors": "0.2.0-preview"
}

The connector extension requires Node.js 24+. Package engines, Node.js type definitions, and the deployment templates use Node.js 24.

Functions 4.17.1 exports the DeliveryMode and Cardinality enums. Polling samples use DeliveryMode.Poll; the batched Outlook sample explicitly selects Cardinality.Many. Single-event examples omit cardinality and rely on its Cardinality.One default. Webhook examples also omit delivery mode, which defaults to DeliveryMode.Webhook.

The SDK version is upgraded alongside the extension because 0.2.0-preview requires @azure/connectors@^0.4.0-preview. If your registry does not yet expose these releases, use the local tarball installation instructions.

The name in each azure.yaml is a lowercase project slug, as required by the azd schema. Folder names and retained Function names are unchanged.

Each app's .funcignore keeps local settings, azd state, editor files, Azurite data, and build-time source/infrastructure out of deployment packages. Compiled functions and installed runtime dependencies remain included.

Retained registered function names remain unchanged, but some helper names changed:

  • Office 365 uses onNewEmailMentioningMe and onUpcomingEvents.
  • Teams uses onTeamMemberAdded / onTeamMemberRemoved with TeamMemberTriggerContext.
  • OneDrive uses connectors.onedriveforbusiness.onNewFiles / onUpdatedFiles for metadata operations OnNewFilesV2 / OnUpdatedFilesV2. Separate raw app.connectorTrigger handlers cover the singular file-content operations OnNewFileV2 / OnUpdatedFileV2.
  • Azure Blob has no first-class helper or metadata re-export in this release. Both Blob examples use connectorTrigger<AzureBlobMetadata>, importing the metadata type from @azure/connectors/generated/AzureblobExtensions.
  • office365.onCalendarNewItems is an alias for onNewCalendarEvent. Only onCalendarNewItems has an example and subscription, avoiding duplicate delivery for the same calendar operation.

Polling samples

Polling examples live in separate files; existing webhook handlers and deployment hooks are unchanged:

App Sample Invocation mode
office365App OnNewEmailPoll Typed helper; up to four Poll events per invocation
genericApp OnGenericOffice365NewEmailPoll Generic API; one Poll event per invocation, up to four concurrent calls

Both use Office 365 Outlook's OnNewEmailV3 operation. Choose one example per Poll Trigger Config; listeners using the same configuration compete for events. A Poll event can itself contain several emails, independently of invocation cardinality.

  1. Create an authorized connection and an enabled Trigger Config with service deliveryMode: "Poll", without webhook notificationDetails. Follow the extension's Poll configuration guide for the ARM request and access policies. Authorize both the namespace identity that runs the connector trigger and the Function/developer identity that receives Poll events. Existing deployment hooks create webhook subscriptions only.

  2. Merge these entries into the chosen app's local.settings.json Values object:

    {
      "EnablePollingSamples": "true",
      "ConnectorNamespace__pollingEndpoint": "https://<connector-namespace-host>",
      "OnNewEmailPollTriggerConfigName": "<poll-trigger-config-name>"
    }

    ConnectorNamespace is a configuration prefix, not a connector connection resource name. Derive its endpoint from the Trigger Config's service-generated pollingEndpoints.receiveUri: remove /triggerconfigs/<name>/receive and the query string, preserving any /api/connectorGateways/<id> prefix. For stable namespace DNS, use only https://<connector-namespace-host>, with no /api suffix. Never commit real endpoints or credentials.

  3. Use a host Connector extension that supports Poll delivery, sign in with az login, start Azurite if needed, and run npm start from the chosen app. No public callback URL or tunnel is required. Preview bundles can lag the current extension source; verify the selected bundle's contents using the host extension guidance.

For Azure, add the same settings to the Function App and set ConnectorNamespace__credential=managedidentity; grant its managed identity access to the connection. Restart the host after changing settings.

Polling samples do not register unless EnablePollingSamples is exactly true, so existing deployments do not require new connection settings. Batch handlers receive flattened, ordered context.items / context.emails; context.rawPayload retains the complete original envelope array and metadata. maxConcurrentCalls is used only by the single-event example, not the batched example.

More triggers and operations

See the Operations to Azure Functions Signature Mapping for connector trigger signatures. The Azure Connectors Node.js SDK provides typed action clients and exported <Connector>TriggerOperations / <Connector>TriggerParameters metadata. Use that metadata from the pinned 0.4.0-preview SDK for exact operation IDs, required parameters, and dynamic-value pickers; helper names are not always remote operation IDs.

Manual connector setup

Deployment of genericApp, Dataflows, Planner, Salesforce, and Azure DevOps provisions a Function App, host storage, Application Insights, and Log Analytics. It does not create a Connector Namespace, connections, OAuth consent, or subscriptions.

For Dataflows, Planner, Salesforce, and Azure DevOps:

  1. Deploy the chosen app, using its README and a unique azd environment.

  2. Create a namespace in a supported region and a connection using the connector ID in that app's README:

    az connector-namespace create -g "<resource-group>" -n "<namespace>" -l "brazilsouth" --system-assigned
    az connector-namespace connection create -g "<resource-group>" --namespace "<namespace>" -n "<connection>" --connector-name "<connector-id>"
  3. Configure the connector's authentication. For OAuth connections, follow the consent-link and status-polling examples in the Teams deployment hook. Do not create triggers until the connection is Connected. Configure connection access policies for the operator and any identity calling connector actions; the namespace policy template shows the resource shape.

  4. Select the operation and actual parameter values from the app's table and the SDK metadata. Retrieve the Function App's connector_extension system key with az functionapp keys list, without logging or committing it.

  5. Prepare the following JSON argument files outside the repository, protecting the notification file because it contains the real key. This example targets Planner's new-task sample:

    Connection details:

    { "connectorName": "planner", "connectionName": "<connection>" }

    Parameters:

    [
      { "name": "groupId", "value": "<group-id>" },
      { "name": "id", "value": "<plan-id>" }
    ]

    Notification details:

    {
      "callbackUrl": "https://<functions-host>/runtime/webhooks/connector?functionName=OnPlannerNewTask",
      "httpMethod": "Post",
      "authentication": {
        "type": "QueryString",
        "name": "code",
        "value": "<connector_extension-system-key>"
      }
    }
  6. From the directory containing those protected files, create the subscription:

    az connector-namespace trigger create -g "<resource-group>" --namespace "<namespace>" -n "<trigger-name>" --connection-details "@connection-details.json" --operation-name "OnNewTask_V3" --parameters "@parameters.json" --notification-details "@notification-details.json" --state Enabled

    Substitute the correct connector, function name, operation ID, and parameters for other examples. Keep the key in notificationDetails.authentication, not the callback URL. Remove temporary argument files after configuration.

  7. Verify the connection is Connected and the trigger is Enabled in Connector Namespaces. Generate a test event and inspect Function App logs.

Tests

Run npm ci and npm test from a sample directory to build its TypeScript source and run the offline smoke tests. See tests/README.md for all-ten-app coverage and the offline deployment-configuration tests.

Prerequisites

The connector-specific templates default the Connector Namespace location to brazilsouth. To use another supported region, set CONNECTOR_NAMESPACE_LOCATION on the azd environment before provisioning.

Related repos

About

Azure Functions samples showcasing Connector triggers and bindings.

Resources

Code of conduct

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors

Languages