Flows for the apps you already use

The same shape, five different apps

Every flow you build is still a trigger, the "when this happens" event, followed by one or more actions, the "do that" steps, each drawn from a connector that links Power Automate to a particular app. What changes from app to app isn't the shape; it's the vocabulary of triggers and actions each connector offers, and a few habits that make each one behave. This lesson tours the five you'll reach for most at work (Outlook, Excel, Teams, SharePoint and Microsoft Forms), then joins two of them into a useful pipeline.

Keep one Fernway job in mind as we go. Maya, the Office Manager, wants every response to the office-move feedback form to land automatically in a spreadsheet the whole ops team can see, with a short Teams heads-up when a new one comes in. We'll build towards exactly that.

Outlook: the connector you'll use most

The Outlook connector is the workhorse. Its triggers include When a new email arrives (the one you met in Level 1) and When a new email arrives in a shared mailbox; its actions include Send an email, Reply to email, Create event and Get emails. The durable idea is that email is both a common starting gun for a flow and a common thing a flow does at the end. Many flows begin with an email landing and finish by sending one.

The one habit worth forming: narrow the trigger. An unfiltered "when a new email arrives" fires on everything, so use the trigger's options to filter by sender, subject or "has attachment" before you build the rest.

When a new email arrives in Outlook from a fernway.example address with "invoice" in the subject, forward it to accounts@fernway.example and add a note at the top saying which mailbox it came from.

Excel: always format it as a table first

Excel is where new builders lose the most time, and it's nearly always the same cause. Power Automate can only reliably read and write Excel data that is formatted as a proper table, the feature you get from Insert > Table in Excel, which turns a plain range of cells into a named table with defined columns. A sheet that just looks like a table (rows and columns of data) is not one as far as the flow is concerned.

Once a sheet is a real table, the Excel Online (Business) connector gives you clean actions: Add a row into a table, List rows present in a table, Update a row and Get a row. Each asks you to point at the location (the file, the worksheet, the table by name) and then works column by column, which is why the table's named columns matter so much. The single most common Excel failure, "the table couldn't be found" or an action that sees no columns, is almost always a sheet that was never formatted as a table, or a new column added without the table being extended to include it.

When a new item is added, add a row to the "Expenses" table in the Finance-Log.xlsx workbook on the team SharePoint site, filling the Date, Name and Amount columns from the incoming details.

Teams: a low-risk way to notify people

The Teams connector is the friendliest place to add a notification, because a message in a channel or chat is visible, undoable in effect (people just read it) and far lower-stakes than sending external email. Its most-used action is Post message in a chat or channel, which asks who to post as, where to post, and the message text. Because it's low-risk, it's the ideal "final step" to add while you're learning. A flow that files something and drops a one-line heads-up in a channel is more useful and no more dangerous than one that files silently.

After the row is saved, post a message to the "Office Move" channel in the Operations team saying "New feedback logged from " followed by the respondent's name, so Maya sees it without checking the sheet.

SharePoint: shared lists and files

SharePoint is where teams keep shared files and, just as usefully, lists: structured, table-like records that live on a SharePoint site and are built for exactly this kind of automation. The connector's triggers include When an item is created and When an item is created or modified; its actions include Create item, Update item, Get items and the file actions you met in Level 1. If your team already keeps a tracker as a SharePoint list, that's often a better automation target than an Excel file, because a list has no "format it as a table" step to forget. It's structured by design.

The durable choice: use a SharePoint list when several people need to add and edit shared records in the browser, and an Excel table when the data is more of a spreadsheet you also want to sort, chart or hand to someone. Both work with Power Automate; pick by how the humans will use it, not by which the flow prefers.

The Forms-to-spreadsheet pipeline, end to end

Now we join it up. Microsoft Forms is a common front door (surveys, sign-ups, feedback), and its responses are far more useful in a spreadsheet the team can filter than buried in the Forms results screen. Here's Maya's pipeline, described one step at a time.

The trigger is Forms' When a new response is submitted. There's one quirk worth knowing in advance: this trigger hands you only the response's ID, not the answers themselves. So the very next step must be the Forms action Get response details, which takes that ID and returns the actual answers as dynamic content you can then use. New builders often miss this and wonder why their spreadsheet fills with blanks. The answers were never fetched. After that, an Excel Add a row into a table step (or a SharePoint Create item) writes the answers into your table, and an optional Teams Post message step tells the team a response arrived.

When someone submits the "Office Move Feedback" form, get the full response details, then add a row to the "Feedback" table in the Office-Move.xlsx workbook with the submission date, the respondent's name and their comments. Then post a short message to the Operations team's "Office Move" channel saying a new response arrived.

Try it now

Common mistakes

• Forgetting to format the Excel sheet as a table. The Excel actions need a real table (Insert > Table), not a sheet that merely looks tabular. "The table couldn't be found" or empty column lists almost always mean this step was skipped.
• Skipping "Get response details" after a Forms trigger. The Forms trigger returns only a response ID, so a pipeline without the "get details" step files blank rows. Fetch the details before you use the answers.
• Adding a column to the spreadsheet but not to the table. If you widen the data with a new column, extend the table to include it, or the flow won't see it. The table's boundary, not the sheet's, is what the connector reads.
• Trusting the pipeline after one tidy test. A form response with an empty optional field, an unusually long comment, or an odd character can behave differently from your clean test. A flow that files responses unattended still needs the occasional look at its run history. It does exactly what you built, on whatever real people actually submit, with no sense of when a row looks wrong.

Keeping current

The connectors here are stable, but Microsoft renames the odd action and adds trigger versions over time. For the current details, see the Excel Online (Business) connector reference and Microsoft's Create a cloud flow guide on Microsoft Learn. Accurate as of 13 July 2026.