Support Intake Agent — AI System Brief | Maneesh Maddala Skip to main content
From Test to Trust TEST TRUST
Connect
← Back to AI Systems

Support Intake Agent

From requests scattered across email, Slack, and Jira to one Teams queue and a routed Asana task.

Power Automate · Microsoft Teams · Webhooks · Asana API · Slack · Jira · Workflow Design

A colleague on the support team told me they were struggling to keep up. Requests reached the team from four places at once: email, Microsoft Teams chat, Slack, and Jira tickets, each with its own queue and its own notifications, and no one could watch all four. Some slipped through, some got worked twice, and there was no record of how a request turned into tracked work.

The intake workflow I built for the support team funnels email, Slack, and Jira into one Microsoft Teams channel, where an engineer turns a real request into a routed Asana task with one action.

Each source has its own webhook, keyed to the support email address, the Slack channel, or the Jira project. When a request lands, the webhook pulls the sender, subject, body, and attachments into a single message and posts it to one Microsoft Teams channel, so the team watches one queue instead of four.

The team triages in that channel. Most messages are noise and go no further. When a request is a real issue, an engineer opens the message actions menu and runs the Support Intake Agent action, which passes that message to a Power Automate flow.

The flow reads the message and its thread for the requestor, the description, and any attachments, then opens an Asana task with those fields copied across. It matches the request type to the team that owns it and assigns the task to that team’s project.

Architecture diagram
Support intake workflow architecture Three sources — a support email mailbox, a Slack channel, and a Jira project — each fire a webhook that normalizes the request and posts it as one message into a single Microsoft Teams channel. A support engineer triages the channel and, on a genuine issue, runs the Support Intake Agent action on the message, which starts a Power Automate flow. The flow copies the requestor, description, and attachments into a new Asana task and assigns it to the team that owns that request type. MICROSOFT 365 · POWER PLATFORM webhook one message run action create task Email support mailbox Slack support channel Jira support project Webhook normalize Webhook normalize Webhook normalize Microsoft Teams one intake channel support engineer triages Power Automate intake flow Asana task created routed to owning team request flow manual action · human triage Microsoft 365 · Power Platform

Funneling four channels into one could just relocate the noise instead of clearing it. The workflow creates nothing in Asana on its own. The team still reads every message, and a task appears only when someone runs the action on a specific one.

A request forwarded from email or Slack often loses its attachments and the name of the person who raised it. Each webhook captures the sender and the files at the source and carries them on the Teams message, and the flow copies all of it into the Asana task.

Routing by hand sends tasks to the wrong team, where they stall and get bounced back. The flow matches each request type to one owning team and assigns the Asana task to that team’s project, so the same kind of request always goes to the same place.

The support team watches one Teams channel instead of four separate inboxes.

Turning a request into a tracked Asana task is one action, and the task arrives with the requestor, the description, and the files already on it.

Every task lands with the team that owns its request type, and anyone can trace it back to the message it started as.