Airline crew already work in Teams and need answers drawn from their own roster mail. Which build strategy fits?
Select an answer to reveal the explanation.
Short Explanation
The roster note is already in the mail of the person standing in Teams. You extend Microsoft 365 Copilot so each crew member gets answers from that person's own roster mail. A pooled inbox for any visitor publishes the whole crew's schedule.
Full Explanation
The crew already works in Teams, and the answers are in each person's roster mail. Extending Microsoft 365 Copilot uses that existing app and that person's mailbox, which is the boundary the roster requires. The signed-in crew member is the boundary, and Teams is where that sign-in already exists, so a new channel is a second place to do a job the existing app can already do. A public web agent that pools every crew member's roster mail for any visitor puts duty times on an open channel. A Copilot Studio agent on a shared kiosk account that opens the whole crew's mail is the wrong build: the users are already in Microsoft 365, and a shared account erases whose roster is whose. A Foundry agent on an anonymous channel with roster mail uploaded as one shared file leaves Teams and collapses every mailbox into a file any caller could query. Exam caveat: the extension answers from mail the signed-in crew member can already open. It does not grant that person the rest of the crew's mailboxes. Operational check: sign in as one crew member in Teams, ask for a duty that appears only in that mailbox, and confirm a teammate's session does not return it.