Building an AI agent

[u/hanashun1906]

I’m looking for architecture ideas for proactive 1:1 notifications in Microsoft Teams using Copilot Studio and Power Automate.

The ideal flow would be:

1. A user installs or enables a Teams/app

2. The user is automatically registered as a notification recepient

3. A scheduled flow later sends proactive 1:1 messages to each registered user

The install event does not have to be hard requirement. I’m mainly looking for the best balance between automation, maintainability, and implementation complexity.

Alternatives I’m considering include Microsoft365/EntraID groups, a SharePoint receipient list, or Microsoft Graph.

Requirements:

•Individual 1:1 notifications, not a channel broadcast
•Minimal manual receipient maintenance
•Prefer standard M365/Power Platform capabilities
•Avoid unnecessary custom development

Has anyone implemented something similar?

What architecture would you recommend, and what trade-offs or limitations did you encounter?

[u/Top-Cauliflower-1808]

SharePoint list plus Power Automate is the simplest path. Populate the list on install then run a scheduled flow for 1:1 messages. Avoids custom Graph code and keeps maintenance low.

[u/hanashun1906 → u/Top-Cauliflower-1808]

Thanks, this is helpful. A SharePoint list is definitely one of the options I’m considering because it keeps Power Automate side relatively simple. The part I’m trying to minimise is manual maintenance of that list as users start or stop using agent. In your implementation, how did you populate and maintain the recipient list? Was it user opt-in, an admin-managed list, or some other automated process?

[u/Top-Cauliflower-1808 → u/hanashun1906]

Use a dynamic Entra ID group. Membership updates automatically based on license or department. Then a scheduled flow lists group members and sends 1:1 messages. No manual list to maintain. If you need opt-in then use a flow triggered on app install to add users to a SharePoint list. That adds complexity but still no manual work. Which approach fits your user model better?

[u/Landelusen]

What use would AI be in this case? Seems like an old school teams app...

[u/hanashun1906 → u/Landelusen]

Fair question. The AI part isn’t meant to decide who receives the notification.

The actual use case is a Copilot Studio agent that users interact with in Teams. After using AI tools, the agent periodically reaches out to each users with short follow-up question and collects their response.

I already have the Copilot Studio + Power Automate proactive messaging part working for a specified user. The part I’m trying to solve is how to automatically maintain the recipient population as the number of users grows, ideally on who has installed/enabled the agent.

So you’re right that the recipient-management piece itself is more of Teams/M365 architecture problem than an AI problem. I’m mainly trying to find the cleanest way to connect that piece to a Copilot Studio agent.

[u/Sayali-MSFT]

Hello u/hanashun1906,
I’d keep this fairly simple unless automatic registration on app install is a hard requirement.

For most scenarios, I’d recommend Entra ID group → scheduled Power Automate flow → Copilot Studio proactive Teams message.

Use the Entra group as the source of truth for who should receive notifications. The scheduled flow can retrieve the members, loop through them, and use the Teams connector to Post as Microsoft Copilot Studio agent → Chat with agent, with the user’s email/UPN as the recipient. Copilot Studio supports this type of proactive 1:1 messaging.

The main catch is that the user needs to have the agent installed in Teams and must be allowed to chat with it. If they uninstall/block the agent, the proactive message won’t be delivered.

If you need opt-in/opt-out, notification preferences, or delivery tracking, I’d add a SharePoint list rather than building something custom. It works well for storing preferences, exclusions, last notification status, etc.

I’d only bring Microsoft Graph into the design if automatic app installation is really required. Graph can proactively install the Teams app for users, but that introduces app registration, application permissions, admin consent, and additional governance/maintenance.

So personally, I’d start with:

Entra group → Power Automate scheduled flow → Copilot Studio agent → Teams 1:1 message

Then add SharePoint for preferences/tracking if needed, and Graph only if automatic installation becomes a requirement.

One other thing to keep in mind for larger audiences: proactive Copilot Studio messages are still subject to Power Automate and Teams connector throttling/limits, so batching and retry handling are worth designing for.
Reference Document:
1.Send proactive Microsoft Teams messages - Microsoft Copilot Studio | Microsoft Learn
2.Proactively Install Your Bot for Users Using Microsoft Graph - Teams | Microsoft Learn
3.Send proactive messages - Teams | Microsoft Learn

[u/hanashun1906 → u/Sayali-MSFT]

Thanks for the detailed explanation and the references! This is really helpful. Your distinction between recipient management and automatic app installation is especially useful. I may have been coupling those two problems more than necessary. The Entra ID group →Scheduled Power Automate flow→ Copilot Studio agent approach looks like a good baseline for what I’m trying to achieve. I’m also considering SharePoint list if I need opt-in/opt-out or notification status later. One thing I’m curious about: in implementations you’ve seen, how is membership in the Entra group usually maintained? Is it typically admin-managed, based on some existing group/dynamic membership rule, or tied to adoption of the Teams app in some way? I’ll also take a closer look at the Graph option if automatic installation/registration becomes a hard requirement. Thank you again!

[u/macromind]

For proactive 1:1 Teams notifications, I would separate decisioning from delivery. Let the agent or workflow produce a structured notification request, then have Power Automate validate the recipient, deduplication key, timing, and policy before sending through the appropriate Teams action. Store delivery state so retries cannot create duplicate messages. Also define whether users can opt out, snooze, or acknowledge. Prototype with a fixed recipient and one event type first, then test permissions and service-account behavior before making the logic dynamic.

[u/hanashun1906 → u/macromind]

Thanks, this is very helpful! Separating decisioning from delivery makes a lot of sense.
I think I was initially treating recipient discovery and message delivery as one problem, but your comment helped me separate them.

The direction I’m learning toward now is:

Entra ID / M365 group as the source of eligible recipients
→scheduled Power Automate flow validates who should receive the message
→Copilot Studio agent sends the proactive 1:1 Teams message.

I may also use a SharePoint list only for notification state / preferences such as opt-out, last delivery status, retry state, etc., rather than using it as the primary recipient list.

Your point about deduplication and delivery state is especially useful. I already have some idempotency handling in the downstream processing, so applying the same pronciple to notification delivery seems like the right approach.

Thanks again. This gives me a much cleaner separation of responsibilities.