Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What a trigger actually is. Most people picture an AI agent as something you talk to a chatbot that sits there until you type. Triggers are the part that lets it move first. They turn a polite question and answer bot into something that reacts. When a file lands in SharePoint, a task gets assigned or a new person joins your team. In this episode, we're breaking down copilot studio triggers in plain language. No jargon, no admin details. Just what they are, how they work, and where they can cost you money. Welcome to the M365 FM podcast where we explore the people, ideas and technologies shaping the future of work. So here is the plain version. A trigger is the condition that decides when your agent should do something at all. The clever conversation and the final answer are not the trigger. It's the small rule that says this is your moment. An image helps here, and it's the one I keep coming back to. Think of a topic inside Copilot Studio as a room, and inside that room sits everything the agent actually does. It asks the questions, sends the messages, runs the flow, and updates the record in Dataverse. The trigger is the doorway into that room, and it decides whether the person standing outside gets to walk in. This matters more than it sounds when your triggers are vague. One of three things happens. No topic starts at all and your agent looks lost. The wrong topic starts and it answers a question nobody asked, or the user gets a flat generic fallback reply that tells them nothing useful. Microsoft's own documentation describes triggers as the way an agent intercepts and handles different events or incoming activities. That's a long way of saying the trigger notices that something happened and then decides to act on it. A trigger is small, but it does a lot of quiet work behind the scenes. It's the difference between an agent that feels alive and one that just sits there waiting for a human to push it, and some triggers fire when nobody is typing at all, which is the part beginners never see coming. The two families of triggers. One you start and one that starts itself. Every trigger in Copilot studio belongs to one of two families. And once you see the split, the whole tool gets easier to hold in your head. The first family is the one you already understand. These are toxic triggers and they're user led, which means they start a topic or an action based on what a person says. Someone types a question and the trigger works out which topic should handle it. The second family is the one that surprises people. Event triggers are system led and they start agent behavior. When something happens outside the chat, nobody types anything at all. A file shows up in OneDrive. A task gets marked done in planner, a new row appears in a table, or a schedule ticks past a certain time. The event itself wakes the agent up with no person involved. So the clean way to hold it is this one family is someone asked and the other family is something happened. If a person is the reason your agent runs. You want a topic trigger. If a system event is the reason you want an event trigger. That distinction sounds simple and it is, but it changes how you design everything. With a topic trigger, you're mostly thinking about words, the phrasing people use, and how to recognize it. With an event trigger, you're thinking about systems instead, what fires the event and what the agent should do the moment it lands. There's a third tool worth naming here, too. When a connector is hard for the agent to call directly, or when you need strict step by step logic around an approval, an update, or a notification. Microsoft's guidance is to reach for a power automate flow. Think of it as the dependable back office behind the agent, while the trigger is the front door. The two families are not equal, though. A topic trigger always has a human in the loop because someone had to ask for something first. An event trigger can run on its own at three in the morning with nobody watching. That is where the power sits, and it's also where the risk lives. Hold on to that risk. There's a cost side to running on its own, and we'll get to it soon. How a topic trigger figures out what you mean. Let's take the user led family first, because this is the one beginners build first. Inside a topic, you write trigger phrases, which are example sentences that stand in for how people actually ask for something. Say you're building a leave request topic. Your phrases might be apply leave request, vacation book, time off, I need leave or can I take leave tomorrow? You're not writing a script the user has to follow. You're giving your agent a handful of realistic ways to recognize the same request. People get the wrong idea about this step. Trigger matching isn't keyword search, where the user has to type the exact phrase you saved. Copilot studio reads the intent behind the message so someone can type something you never wrote. And the right topic can still start as long as your examples captured the shape of the request. A good phrase list is short, natural, and varied. You want the words real people use, so mix, leave, vacation time off, and holiday. If those are common where you work, you don't need hundreds of phrases and near duplicates don't help. You need to cover the realistic ways people ask and then test them, including partial phrases, typos, and longer questions. If you're stuck for ideas, raid your support tickets or your chat logs. Real questions from real people are the best phrase list you'll ever find, and they'll tell you which words your organization actually uses. When two topics look equally good, Copilot studio has a built in way to handle it. It can show a multiple topics matched list, so the user just picks which one they meant. That's much friendlier than a wrong guess. And it also tells you that two of your topics might be overlapping. There's an order to things as well. Some trigger types fire before others. And if two triggers of the same type both qualify, the older one runs first. You can set a priority yourself to override that. You can also add conditions, so a trigger only fires when the situation is right. For example, only when the conversation is happening inside Microsoft Teams, when a plain condition isn't enough, there's a formula editor for anything more complicated. One thing changed recently, and it's worth knowing before you follow an old tutorial. Newer agents use a mode called Generative Orchestration, and they're. The default trigger is the agent chooses. Instead of matching phrases, the agent looks at a topic's name and its description and decides whether it fits what the user asked. Older style agents use. User says a phrase which is the phrase matching version we just walked through. Both are still alive in the product, so if a tutorial looks different from your screen, that's usually the reason how an event trigger lets your agent act on its own. Now let's look at the family that runs without anyone watching. Before you can use an event trigger, your agent needs generative orchestration turned on. Orchestration is just the agent's ability to decide which tool or topic to use. And in plain terms, it's the part doing the choosing event triggers. Build on that because the agent has to figure out what to do with the event once it arrives. The flow has three steps, and they're easier than they sound. First, an event happens somewhere else, like a new item appearing in SharePoint. Second, the trigger sends what Microsoft calls a payload, which is a small bundle of information about the event, plus any instructions you want to attach. Third, the agent reads that bundle and picks an action or a topic to run. The library of events is bigger than you'd guess. A new item in SharePoint. A new file in OneDrive, a task completed in planner, or a set amount of time passing, which is the recurrence trigger. You pick the event and then you narrow it down. So for a table in Dataverse, you choose which tables changes should wake the agent. One thing trips up beginners here. The agent doesn't invent an action on the spot. You have to build the action or the topic first, and then your instructions. Tell the agent which one to reach for. If you expect the trigger to do the work by itself, you'll be disappointed. You also have two places to write instructions, and keeping them straight saves you a headache. There are the agent's general instructions which cover how it behaves overall, and there are the instructions inside each trigger payload which cover this one event. When those two disagree, you get errors or strange behavior. So the guidance is to keep them consistent. If an agent has several triggers, put the event specific detail in the payload instead of overloading the general instructions. There's a testing step here that beginners skip, and it's worth slowing down for before you publish. The agent won't react to the trigger automatically, so you run the event once to create a payload, then use the test trigger icon to send that payload into the test chat and watch what happens. The activity map shows you step by step how the agent responded, which is how you catch a missing input before real users do. Event triggers authenticate using the maker's own credentials. The account of the person who built them. That's what lets the agent run unattended. And it's also why Microsoft shows a warning before you publish, your agent might reach data and systems that you can access on behalf of people who can't, so the power and the risk arrive together. An agent that can act on its own at any hour is useful, and that same agent is something you have to point carefully. Three everyday examples that make triggers. Click. Three examples will make this concrete because the idea lands better when you can picture it. Example one is the leave request and this one is a topic trigger an employee types. I need to book time off next week. The trigger recognizes the intent and starts the leave request topic. From there, the agent walks them through it, asking for the leave type and the dates and maybe a reason. Then it submits the request through a flow and confirms that it went through. The person never has to learn the menu or know the name of the process, because they just ask in their own words. Example two is the new hire and this one is an event trigger. Picture a new team member being added. An event trigger fires on that moment, and the agent sends a welcome message with the onboarding resources that person needs on day one. Nobody in it has to remember because the event is the reminder. The same pattern works for a new order coming in, where the agent confirms availability, checks shipping timelines, and sends the customer an update. Example three is the quiet one and it's my favorite. An event trigger watches the table in Dataverse, and every time a new row shows up, it checks whether the account name is a duplicate. When it finds one, it creates a to do task to investigate with the details attached. Nobody is staring at a spreadsheet and the agent just keeps watch on its own. Notice what all three have in common. The person gets a fast, natural experience and the maker spent their effort on the trigger and the instructions rather than on the chat itself. That's the trade you're making, and most of the time it's a good one. But there's a bill attached to that third example, the one that keeps watch. And it's the reason a perfectly innocent trigger can get expensive. Let's talk about that next. What triggers cost? Because they are not free. The cost catches almost everyone off guard. So let's start there. Copilot studio builds in units called copilot credits. And the counting rule that catches people. Is this a message? Is any request or message that triggers an action or a response from the agent and payload sent from event triggers count as messages. Read that part again because it means the event itself is billable. Every time your trigger wakes the agent up, that's a message. Now think about the recurrence trigger. It fires on a timer every time the clock reaches the interval you set. If you set it to every ten minutes, your agent gets a payload, a message every ten minutes. That's one hundred and forty four messages a day for as long as you leave it switched on. Whether anything useful happens or not. It's easy to build that on a Friday and forget about it by Monday. The rates themselves are set in credits, and they vary by what the agent does. A classic answer, one that you wrote by hand, costs about one credit. A generative answer, one the AI writes on the fly is about two an agent action, which is a step like a trigger or a topic transition is about five. Grounding an answer in your company's own data costs more around ten and running agent flows. The predefined sequences of steps is built at about thirteen credits per one hundred actions. Those numbers are illustrative and they change. So check the current licensing page before you plan a budget. There's a piece of good news hiding in here, though. If the person using your agent has a Microsoft three. Sixty five copilot license employee facing usage is included at no charge. The exception is agent flows that are triggered some other way, which bill at the normal rate. And there's a hard edge worth knowing if your environment blows past its prepaid capacity at one hundred and twenty five percent, agents get switched off. Users see a message saying the agent is unavailable or that there's a billing issue. Nobody likes that surprise. So a trigger that runs forever deserves a second look before you walk away. The limits and the mistakes beginners make money is one limit, reliability is the other, and this is the one they hit first. Start with the words because most trigger problems live there. Too few example phrases and your agent misses requests. It should catch duplicate phrases across two topics and it can't tell them apart. Long unnatural sentences like initiate employee absence management transaction confuse the matching because nobody actually talks that way. And when two topics are simply too similar, the agent has to guess the fix is boring and effective, which is to read how real people ask from support tickets or chat logs and write your phrases the way they do. There's a quick sanity check you can run on yourself. If two of your topics could both plausibly answer the same message, they'll fight over it. So either merge them or sharpen their descriptions until only one clearly fits. Then there are instruction problems. Vague agent instructions leave the agent guessing and payload instructions that contradict the agent. Instructions produce errors or odd behavior. So the advice is to say what you mean in one place and keep the two sets of instructions agreeing with each other. Now the harder truth, and I want to be fair about it. Some makers report that event triggers fire inconsistently. One person on Microsoft's own question and answer site described an email trigger that worked, then stopped, then worked again after republishing with Power Automate reporting success the whole time. The likely reasons are messy and they include preview status in some environments, connection and identity mismatches, a flow, and an agent sitting in different environments throttling under load and the way email triggers batch their events. Treat that as a community report rather than an official guarantee, and design like the event might not fire. That last point matters if the work really has to happen. Don't let a single trigger be your only safety net. Microsoft's own guidance suggests using a power automate flow when a connector won't cooperate, and building the whole thing so it can retry safely. There are some plain guardrails worth carrying with you. Keep the number of actions and topics an agent calls in a row under fifteen because long chains get unreliable. Be careful with very frequent or never ending recurrence triggers, since they burn resources and can get you throttled. Keep an eye on how many triggers are active in an environment, and remember that availability isn't only up to you, because an administrator can block certain triggers through data policies and adding event triggers requires a specific sharing setting to be turned on. So when a trigger simply isn't there for you, it's often a setting rather than a missing feature. Where all of this lives in Microsoft three hundred sixty five and Azure. Step back and it helps to see where triggers sit in the bigger picture. There are really three layers and you can hold them as people. Platform and power. Microsoft three hundred sixty five copilot is the layer for people, a license that puts AI into the tools they already use. Copilot studio is the platform layer, the low code place where you build the agent, wire up its triggers and connect it to the channels where people meet it, like Microsoft Teams or a web page. Azure is the power layer where heavier custom AI work runs and where the pay as you go meter lives. That meter is a nice detail for beginners because it lets you start small. You can build inside Copilot Studio and never touch Azure. If you do grow, you can link an Azure subscription for pay as you go, which also means overage bills to that subscription instead of switching your agents off. If you bring your own model, including the ones from Azure Foundry that's built separately outside the copilot studio credit rates. So the shape is simple. Microsoft three. Sixty five copilot is your license. Copilot studio is the place you build and the heavy lifting plus the billing flexibility. Live in Azure. You don't need all three to get started. And that's the encouraging part. A quick recap and one question for you. Let's pull it together. A trigger is the small condition that decides when your agent acts the doorway into a topic. There are two families. Topic triggers that fire when a person asks, and event triggers that fire. When a system event happens, you feed topic triggers with realistic example phrases and you point event triggers at events with instructions that tell the agent what to do. Get those right and your agent feels alive. Get them vague and it either does nothing or does the wrong thing. One question for you if you could switch on one trigger tomorrow, what would you have your agent watch for? A new file, a new hire, or a schedule that never sleeps? Tell me in the comments, because that answer usually tells you which kind of trigger you actually need. If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.