Event trigger overview (preview)

You can configure custom agents to perform actions or call topics in response to something happening using event triggers. Unlike topic triggers, which require input from a user, event triggers allow your agent to act autonomously in response to the defined event occurring.

Important

Using event triggers is a public preview feature. Using event triggers is free for preview participants, but does require messages that count towards your usage quotas. Preview features aren't meant for production use and may have restricted functionality. These features are available before an official release so that customers can get early access and provide feedback.

Note

This feature is only available for agents with generative orchestration enabled.

How event triggers work

Event triggers require a chosen event which generates a trigger payload and sends it to the agent through a connector. The payload contains information about the event, including variables for specific kinds of data. When the agent receives the payload, it executes the directions provided by the agent author in the agent's instructions and instructions sent through the trigger payload.

Agents only act based on their author's design and instructions. For example, you can add a trigger for when a new team member is added, and designate the response to be the action send the new employee a welcome message with onboarding resources.

Event triggers activate based on events external to the agent. They're different from topic triggers, which are used for activating topics or actions based on trigger phrases entered by users.

This article explains how event triggers work, their limitations, and troubleshooting strategies. For more information about adding an event trigger, see Add an event trigger.

Other examples of event triggers include:

• When an item is created in SharePoint
• When a file is created in OneDrive
• When a task is completed in Planner
• A set amount of time passed (a Recurrence trigger)

Important

What triggers are available depends on your organization's data loss prevention policies, configured in Power Automate by an administrator.

The trigger workflow

A trigger is one part of a workflow containing multiple parts:

1. An event trigger registers that a specific event occurred.
2. The trigger sends a payload containing information about the event and instructions.
3. The agent has instructions to choose one or more actions or topics based on the payload.

Find the trigger that fits your event

Copilot Studio has a library of triggers for a range of events that can occur in Microsoft and partner services. The trigger configuration determines the parameters of the event that initiates the trigger. It also determines the contents of the trigger payload.

Most triggers allow you to specify parameters about the event that activates the trigger. For example, in the When a row is added, modified or deleted trigger for Dataverse, you select which table's changes activate the trigger.

Define the trigger payload

The trigger payload is a JSON or plain text message that contains information about an event. The payload is sent to your agent as a message. When adding a trigger, you can keep the default payload contents for that trigger, or add your own instructions. Later, you can modify the payload contents, including adding variables and string operators, in Power Automate.

For example, the default message in the When a row is added, modified or deleted trigger is Use content from Body. When the agent receives the payload, it has the content from the row, and instructions to use that content.

You can add instructions to send to your agent inside the payload that direct the agent on how to act when activated by the trigger. If you have multiple triggers, each trigger payload can have specific and detailed instructions, without you needing to write long and complicated guidance in the agent's general instructions or confusing the agent about which instructions apply to which trigger.

For example, in a When a row is added, modified or deleted trigger payload, you can add Send a summary of the changes in the chat. When the agent receives the payload, it summarizes the changes for the user in the agent chat.

However, avoid writing payload instructions that conflict with the agent's general instructions. Conflicts in instructions can cause an error or unexpected results. Make sure to test all changes involving event triggers.

After creating a trigger, you can add or change variables or string operators in a trigger payload and modify existing payload instructions using Power Automate.

Agent instructions versus payload instructions

Payload instructions are specific to how to react to one event. You can also use agent instructions to direct your agent in how to handle information from a trigger and how to act when it receives a trigger payload, as well as for determining your agent's general behavior. For example, for an agent that checks for duplicate account names in new Dataverse table rows, the instructions could be: When a new row is added, check if it's a duplicate account. If there's a duplicate, create a To Do task to investigate, and include details about the changes and duplicates.

However, agent instructions might not work best for all situations. If your agent has multiple triggers or multiple complex goals, you should use instructions in the trigger payload instead.

Continuing the last example, you could add an instruction in the trigger payload to Look for duplicate account names in the same Dataverse table. When the agent receives the payload, it's instructed to look for duplicate account names. The agent's general instructions then says, If there's a duplicate, create a To Do task to investigate, and include details about the changes and duplicates.

Creating instructions for agents takes practice. Go to writing guidance for more tips, and always test all changes you make to your agent.

Call an action or topic

When an agent receives a trigger payload, the instructions you have given it determine the action or topic it calls in response. Your instructions allow your agent to select an action or topic based on the information it has available.

Your agent doesn't create a new action or topic on the spot. As the agent author, you need to define the actions or topics it can select from. To learn how your agent determines which action or topic to call, go to How does generative mode work?

If your agent isn't reacting as expected, you can use the activity map to see if it's missing any key input information.

Some improvements you can make to instructions include:

• Adding more detailed instructions in the trigger payload or agent instructions. Your agent might need more direction, like what information to use in a specific input field for action.
• Including instructions in the trigger payload.
• Instructing your agent to call a specific action or topic.
• Checking for conflicting instructions between trigger payload and agent instructions.
• Adding to the descriptions of the actions, so the agent has more information to determine when to call it.
• Adding descriptions to the action input fields to help your agent fill in the parameters correctly. If an action's inputs are the same every time, you can set the value yourself.
• Calling fewer than 15 actions or topics consecutively. Complex agents that run many actions or topics as a single sequence can struggle to manage running them reliably.

If your agent still struggles to call the expected action, consider adding a Power Automate flow that fulfils your goal as an action for your agent.

Publishing agents with event triggers

Before you publish your agent with a new event trigger, the agent doesn't automatically react to that trigger. Make sure you test the agent thoroughly before publication, because after you publish an agent with a new trigger, your agent reacts automatically each time its triggers are activated. You can see a step-by-step record of your agent's triggers and reactions in the Activity page.

For information on activating triggers during testing, go to Test a trigger.

Event triggers can only use the agent author's credentials for authentication (that is, the credentials you used to authorize the connections) for your trigger. This can allow users of an agent to use the agent to access data and systems using that same authorization. For more information, go to Troubleshooting and limitations.

Authenticating actions after publishing

If your agent is missing authentication to perform an action or is configured to request user authentication, it sends a message to the user asking for credentials. If an agent's flow is interrupted because it can't receive information or an action failed, it can't continue the session. If you want your agent to run autonomously, each action must be configured with working authentication that doesn't require user input. You can also instruct your agent to not request credentials from users.

Agents might not be able to run every connector successfully. If an agent repeatedly fails to call a connector, consider creating a Power Automate flow action that uses the problematic connector to complete the action.

Troubleshooting and limitations

Quota limitations

If triggers activate too frequently, then your agent might end up using more resources than expected. Your agent might then exceed service load quota limits, and your service could be throttled.

Administrators can monitor resource usage through Power Platform. They can also block event triggers from being used in an environment.

To avoid exceeding quota limits:

• Take care when adding very frequent triggers, or triggers that recur indefinitely. For example, a recurrence trigger activates whenever a set amount of time passes. The smaller the amount of time between activations, the more resources the trigger uses.
• Keep track of how many triggers are active in an environment.

Triggers can use maker credentials only

Currently, event triggers can use only the agent author's credentials for authentication. If you publish or share an agent with authenticated event triggers, users might be able to access information or prompt the agent to perform actions using the author's credentials.

In order to prevent users from accessing or modifying protected data or systems, carefully consider whether and how data and systems requiring authentication are used by agents with event triggers. Authors should be aware when sharing or publishing agents containing event triggers.

Administrators can also block Copilot Studio users from using event triggers with their agents. For more information, go to Block event triggers.

Limitations using knowledge sources with event triggers

Agents can't reference some knowledge sources in response to an event trigger. Some knowledge sources require an agent to provide authentication to access, but agents can't provide that authentication autonomously.

Avoid these knowledge sources, when referenced in response to an event trigger:

• SharePoint
• Dataverse
• Graph Connectors
• AI Builder Prompts

Reference these knowledge sources in response to an event trigger instead:

• Public websites
• Uploaded files
• Enterprise data, using connectors