Hi,

Thanks for the detailed write-up. This is a common issue when moving a Copilot Studio solution across environments, and it's fixable. The key point: connection references only decide which connector a flow uses, not who the flow runs as. If a flow still runs under your identity, it will keep using your Outlook regardless of references and environment variables.

Targeted fixes:

Deployment basics. Put all components (4 flows, agent, Canvas app, environment variables, connection references) in the same managed solution. Replace hardcoded SharePoint URLs, list names, and emails with environment variables. During import, map every connection reference to connections that exist in the target environment, and don't skip this step.

Agent-called draft flow. In Copilot Studio, set this flow to run with end-user credentials, not maker credentials. This single setting is the direct cause of "it always uses my Outlook."

RAID-extraction flow and scheduled reminder flow. These are background automations with no interactive user. Create a dedicated licensed service account (e.g. raid-bot@yourcompany.com), make it the owner, and create their connections in the target environment under that account. Reminders will then come from the bot, not you.

Canvas app. Share it with the RAID-owner group and let Power Apps handle per-user connection consent on first use.

Order of execution: create and license the service account, then sign in as that account in the target environment and pre-create connections, then import the managed solution while mapping connection references (service account for background flows, end-user for the agent flow), then set all environment variable values, then test by signing in as a different user, not yourself.

Also confirm every user has proper Power Platform licensing in the target environment, since silent flow failures are sometimes just a licensing gap.

If you can tell me whether the target is a separate tenant or another environment in the same tenant ?

Best regards

A service account is licensed once for the entire solution, not per user. It's a single non-human account that owns the background flows and holds the connections. Your end users don't need anything extra because of it. They still need their own Power Platform licensing to interact with the agent and Canvas app, but the service account itself is one license total. If it also sends reminder emails, give it an Exchange Online mailbox license too, but again, just once.

One practical tip: secure the service account properly since it owns automation. Use a strong password, store credentials somewhere safe, and if your tenant enforces MFA, either exclude that account via a conditional access policy or set it up with app-based auth, otherwise the connections can break.

On the pipeline issue, components not appearing in the target environment usually comes down to one of a few things. Check that the deployment stage actually completed successfully and didn't silently fail, that the components were genuinely added to the solution before the pipeline run, and that you're looking at the managed solution in the target rather than expecting loose components.

Also confirm the pipeline's target environment is the one you're actually checking, and that your account has the security role to view solutions there. If the run shows success but nothing appears, the solution was likely empty or stale at deploy time, so re-add components, publish all customizations, and re-run.