rss.livelink.threads-in-node

When to Choose Agent Builder Instead of Power Apps: A Practical Guide for Modern Businesses

JohnNaguib — Wed, 29 Jul 2026 13:35:53 GMT

The Microsoft Power Platform has transformed how organizations build business solutions without extensive coding. Two of the most talked-about technologies in this ecosystem are Power Apps and Agent Builder. While both help organizations automate work and improve productivity, they serve very different purposes.

https://dellenny.com/when-to-choose-agent-builder-instead-of-power-apps-a-practical-guide-for-modern-businesses/

10 Best Practices for Designing Effective Microsoft 365 Agents

JohnNaguib — Wed, 29 Jul 2026 13:35:01 GMT

Artificial Intelligence is rapidly changing how businesses operate, and Microsoft 365 Agents are becoming one of the most valuable tools for improving productivity, automating repetitive work, and helping employees make better decisions. Whether you’re building an agent for customer support, HR, sales, finance, or internal knowledge management, success depends on more than just connecting AI to your data.

https://dellenny.com/10-best-practices-for-designing-effective-microsoft-365-agents/

Microsoft Copilot Tips and Tricks: 20 Smart Ways to Work Faster and Get Better Results

JohnNaguib — Wed, 29 Jul 2026 13:33:52 GMT

Artificial intelligence is no longer just a futuristic concept—it’s becoming a daily productivity partner. Among the leading AI assistants, Microsoft Copilot has quickly become one of the most valuable tools for professionals, students, developers, marketers, and business teams. Built into Microsoft 365, Windows, Edge, and GitHub, Copilot helps users write, analyze, summarize, create presentations, automate repetitive tasks, and make informed decisions in less time.

https://dellenny.com/microsoft-copilot-tips-and-tricks-20-smart-ways-to-work-faster-and-get-better-results/

Cool Things to Do with Microsoft Copilot: 15 Practical Ways to Work Smarter Every Day

JohnNaguib — Wed, 29 Jul 2026 13:27:52 GMT

Artificial intelligence is no longer just a futuristic concept it’s becoming an essential part of how we work. One of the most exciting AI assistants available today is Microsoft Copilot, a productivity companion built into Microsoft 365, Windows, GitHub, Edge, and other Microsoft products.

https://dellenny.com/cool-things-to-do-with-microsoft-copilot-15-practical-ways-to-work-smarter-every-day/

More control over web grounding with Domain Exclusion for Microsoft 365 Copilot

Suhel_Parekh — Tue, 28 Jul 2026 15:50:14 GMT

We are excited to announce Domain Exclusion for Microsoft 365 Copilot, a new web search control that gives organizations more choice over which external web sources can be used to ground Copilot responses. As customers bring Microsoft 365 Copilot and Copilot Chat (Copilot) into more business-critical workflows, admins need practical controls that help web-grounded experiences stay aligned with organizational policies, compliance expectations, and trusted source strategies.

Give admins more control over web grounding

Web grounding helps Copilot deliver more timely and relevant answers by allowing Copilot to reference current information from the public web when it can improve the response. With Domain Exclusion, administrators can now specify external sites that Copilot should not use for web grounding, giving organizations a more precise way to align Copilot responses with internal policies, compliance needs, and trusted source strategies.

What is Domain Exclusion?

Domain Exclusion for Microsoft 365 Copilot enables administrators to define domains that are excluded from Copilot web grounding. Once configured, excluded domains are not used in Copilot responses that rely on web grounding. This capability applies to Microsoft 365 Copilot and Copilot Chat web grounding scenarios and is designed to give organizations additional control over which external web sources can influence AI-generated responses.

Organizations can configure up to 1,000 domains for exclusion. The feature is not enabled by default and requires administrator action to configure through the provided PowerShell script. This gives admins flexibility to adopt the control based on their organization’s specific governance requirements.

Figure 1: Info tip for users showing that Admin policy may restrict certain sources with Domain Exclusion for Microsoft 365 Copilot and Copilot Chat.

Why it matters

Customers want the productivity benefits of web-grounded AI while maintaining confidence that Copilot experiences reflect their organization’s policies and risk posture. Domain Exclusion adds targeted control between allowing web grounding broadly and turning web search off entirely. Admins can continue to enable web-grounded answers where they add value, while excluding domains that are not appropriate for their environment.

This is especially important for organizations with strict compliance obligations, brand safety requirements, regional content considerations, or internal policies around approved sources. By helping admins reduce the influence of unwanted or non-compliant web sources, Domain Exclusion supports a more governed approach to AI adoption.

How admins can get started

Admins can configure Domain Exclusion using the Configure Tenant Domain Exclusions PowerShell script. The script supports common configuration tasks, including creating a new exclusion list from a CSV file, updating an existing configuration, exporting the current configuration, deleting a configuration, and generating a template CSV file. Learn more at aka.ms/copilot/DomainExclusion.

Review the domains your organization wants to exclude from Copilot web grounding.
Prepare a CSV file with the required domain information.
Run the PowerShell script as a Search Administrator or Global Administrator.
Validate the configuration and update it as organizational policies evolve.

Closing

Domain Exclusion gives organizations another practical control to adopt Microsoft 365 Copilot with confidence—helping admins shape how web-grounded experiences align with their policies, compliance requirements, and trusted source strategies. As AI becomes more deeply embedded in everyday work, capabilities like Domain Exclusion help organizations move faster without giving up the transparency, security, and governance they need. Domain Exclusion builds on Microsoft 365 Copilot web search controls, giving admins a more targeted way to manage which external domains can be used to ground Copilot responses.

Related

Domain Exclusion Learn documentation - https://aka.ms/copilot/DomainExclusion
Domain Exclusion PowerShell script - https://aka.ms/Copilot/DomainExclusionScript
Data, privacy, and security for web search in Microsoft 365 Copilot and Microsoft 365 Copilot Chat | Microsoft Learn
How web search works in Microsoft 365 Copilot Chat and agents | Microsoft Support

File processing capabilities in new Copilot Studio

NickKearns — Mon, 27 Jul 2026 20:06:13 GMT

In the classic version of Copilot Studio there is an option in settings to enable file uploads by users. This setting does not appear to be present in the new Copilot Studio settings and I have noticed that I am unable to upload a file to the agent when public via the MS365 Copilot channel. Has anyone else experienced this issue with the new Copilot Studio?

Is "Popular in Your Org" in the Agent Store Actually Based on Usage?

DavidEnestvedt — Mon, 27 Jul 2026 15:19:35 GMT

I've noticed something interesting in the Microsoft 365 Copilot Agent Store and I'm curious if others are seeing the same behavior.

In the "Popular in Your Org" section, many of the agents being surfaced are either:

Blocked by our administrators
Not available for me to install
Restricted due to licensing or governance settings

This creates a somewhat confusing experience because the label implies these are agents that are actively being used or adopted within my organization. However, if users cannot install or access them, it raises questions about what "Popular in Your Org" actually means.

A few questions for the community:

Are others seeing unavailable or blocked agents appear in the "Popular in Your Org" section?
Does anyone know what signals Microsoft uses to populate this list?
Is it based on actual agent usage, admin deployments, views, recommendations, or something else?
Is there a configuration option for admins to make this section reflect only agents that users can actually access?
Has anyone found a way to better align this experience with organizational governance and available inventory?

My expectation would be that "Popular in Your Org" would surface agents that are:

Available to me (or my audience) to install/use
Actively being used within the organization
Relevant to my permissions and licensing

Otherwise, it feels a bit misleading to highlight agents that users discover but ultimately cannot access.

Would love to hear whether others have had the same experience and whether Microsoft has shared any guidance on how this section is populated.

Thanks!

Can Copilot help write better performance review comments?

ClaireB — Mon, 27 Jul 2026 13:10:15 GMT

We just finished our mid-year review cycle and the feedback quality from managers was honestly terrible. Lots of gems like "100%" or “Fully agree“. Someone on my team suggested using Copilot to help managers draft better feedback but I'm not sure how that would work practically. Like where would the AI even pull context from?

腾龙公司游戏网址

小奇 — Sat, 25 Jul 2026 12:18:54 GMT

公司位【wbl12889】

（一）打开浏览器，输入公司游戏官网《WBL995.COM》，点击页面上的“开户”或“注册”按钮。

（二）填写基本信息输入用户名（6~12）

输入用户名（6 ~12位数字字母组合）、设置密码（6 ~12位，建议包含字母+数字+符号），并确认密码。

（三）绑定联系方式

为了保障账号安全，建议绑定手机号或邮箱，方便后续找回密码和接收通知。

（四）输入验证码

在验证码框中输入正确的验证码，完成验证。

（五）提交开户申请

点击“确认”或“提交”，系统会提示开户成功，登录即可。

圣淘沙公司游戏网址

罗小斌 — Sat, 25 Jul 2026 07:28:41 GMT

公司位【wbl12889】

（一）打开浏览器，输入公司游戏官网《WBL995.COM》，点击页面上的“开户”或“注册”按钮。

（二）填写基本信息输入用户名（6~12

输入用户名（6 ~12位数字字母组合）、设置密码（6 ~12位，建议包含字母+数字+符号），并确认密码。

（三）绑定联系方式

为了保障账号安全，建议绑定手机号或邮箱，方便后续找回密码和接收通知。

（四）输入验证码

在验证码框中输入正确的验证码，完成验证。

（五）提交开户申请

点击“确认”或“提交”，系统会提示开户成功，登录即可。

Available today: Anthropic Claude Opus 5 in Microsoft 365 Copilot

Bas Brekelmans — Fri, 24 Jul 2026 21:11:08 GMT

Today we’re expanding model choice in Microsoft 365 Copilot with the addition of Anthropic’s latest model—Claude Opus 5.

Claude Opus 5 is the newest model in Anthropic’s Opus family. Designed to be used every day for complex, multi-step work. It improves on Opus 4.8 across agentic coding, professional knowledge work, and long-horizon reasoning¹.

With Opus 5, Copilot takes on more of the steps between idea and finished work across the apps you use every day—while keeping you in control of the final outcome:

Word: Move from rough idea to a complete draft, holding structure and flow together across longer documents.

Excel: Work through complex analysis with higher-quality modeling and more polished workbooks.

PowerPoint: Build and refine presentation drafts from first outline to polished deck, with more visual polish, creative layouts, and better use of slide space

Copilot Chat: Tackle open-ended, novel problems—comparing options, structuring plans, working through ambiguity—with stronger reasoning.

Copilot Cowork: Stay focused on long-running tasks, orchestrating work across tools and files with the context Work IQ brings from your organization to carry a project through start to finish.

Copilot Studio: Build agents on Claude Opus 5 for advanced reasoning, workflow automation, and multi-step tool use in the preview orchestrator.

We’re committed to bringing you the latest AI innovation and model choice for AI at work, supported by Microsoft’s enterprise-grade security, privacy, and compliance.

Get started today

Claude Opus 5 is rolling out to the model selector in Copilot in Word, Excel, PowerPoint, Chat, Copilot Cowork, and Copilot Studio.

Availability may vary by region and tenant configuration; refer to the Microsoft 365 Roadmap and Microsoft 365 Copilot release notes for the latest rollout status.

For more details on the model, see Anthropic’s Opus 5 announcement1

Editor cannot see agent instruction in Copilot Studio 5137678

Kopigao — Fri, 24 Jul 2026 15:29:49 GMT

Classic

Bot Sharing Broken in Copilot Studio – when owner share a agent to editors but it editor can’t edit or see instructions ) – Issue ID 5137678

Many environment are affected and Microsoft is not permanent fixing it even after we as customer are encountering with bot/agent sharing in Microsoft Copilot Studio.

Issue Description:

what was given

Sharing bots fails in environments where a Team record exists with the following properties:

MembershipType = Members
TeamType = Office Group (Microsoft 365 Group)

This appears to be a known issue tracked as Issue ID 5137678 (created June 3, 2025).

Symptoms:

Unable to share bots with Teams or specific users/groups.

(1) what should we set for security group when new environment is setup

(2) existing environment how can this be best resolve in bulk?

Will GPT‑5.6 Be Available in Microsoft Copilot 365 for Family Subscribers?

amaca19 — Fri, 24 Jul 2026 08:33:26 GMT

I have a question regarding future model availability in Microsoft Copilot 365.

Will GPT‑5.6 (or any upcoming advanced model) be available for Microsoft 365 Family subscribers, specifically for the Family administrator? Right now, most of the enhanced AI features seem to be targeted at Business or Enterprise plans, so I’d like to know whether Family users will also receive access to the newer Copilot models once they roll out.

Thanks in advance to anyone who can clarify this.

1 million documents to 300+agents: Building an enterprise-scale Microsoft 365 Copilot connector

supramo — Thu, 23 Jul 2026 18:57:12 GMT

1 million documents. 100,000+ monthly users. 300+ Copilot Studio agents. Here's what we learned building the Microsoft 365 Copilot connector behind them.

Most enterprise knowledge lives in portals and repositories that people trust but rarely visit in the flow of work. That's the gap this connector was built to close.

At Microsoft, we built an enterprise-scale Microsoft 365 Copilot connector to make internal documentation available as grounded context across supported Copilot experiences. The connector runs in production today, serving teams across engineering, support, and field roles.

Who this post is for: platform teams, developers, and connector owners who are past prototype and thinking about production. We cover the design choices, security and governance considerations, schema decisions, operational patterns, and retrieval-quality practices that helped us make enterprise knowledge easier to discover and reuse through Microsoft 365 Copilot.

Understand why a Microsoft 365 Copilot connector matters

New to Microsoft 365 Copilot connectors? Start with the Microsoft 365 Copilot connectors overview and the Copilot connectors API documentation.

The real power of a Microsoft 365 Copilot connector isn't the ingestion — it's what becomes possible once your content is in the platform.

The moment your connector is live and configured for supported Microsoft 365 Copilot experiences, your content can become available as grounded context in those experiences. That means:

Copilot Chat — users ask questions in natural language and get answers grounded in your content, alongside emails, files, and Teams messages. No portal visit required.
Copilot in Microsoft 365 apps — in Copilot for Word, PowerPoint, and Excel (where supported), your knowledge can appear as context when users draft, summarize, or build presentations.
Copilot Studio agents — users with appropriate permissions and licensing can build custom agents scoped to your connector's content. In our case, 300+ agents were created by teams within Microsoft — incident response assistants, onboarding copilots, domain-specific Q&A bots — all without additional work from us.
Copilot CLI and developer tools — Copilot CLI is the command-line experience for developers working in a terminal. Engineers get answers in their terminal or IDE, grounded in the same authoritative content.
The Copilot Retrieval API — teams with appropriate access can programmatically query the indexed knowledge to build custom experiences we never anticipated.

The key insight is that a connector is not just an ingestion pipeline. When you invest in clean schema, reliable ingestion, and the right access controls, supported Copilot experiences can reuse that content without requiring a separate integration for every surface.

A quick note on terminology. This post describes a Microsoft 365 Copilot sync connector (previously known as a Graph connector). Sync connectors ingest and index your content into the Microsoft 365 substrate, which is different from federated connectors that query content in place.

Plan for production gaps

The public documentation gets you from zero to a working connector. Getting from a working connector to a production one uncovered four gaps we hadn't planned for: tenant configuration, security and compliance readiness, discoverability, and shared throttling limits.

Validate tenant configuration early

The documented path starts with creating a connector in your tenant and ingesting data. In our environment, we had to validate architecture before full production, and hit a few things that weren't in the docs. Watch out for:

Cross-tenant data flow. There is no supported model for cross-tenant data flow between Entra ID tenants today. We resolved this by consolidating connector operations into a single tenant.
"Draft" state limbo. Connectors can get stuck in "Draft" state despite correct permissions. Escalating through the platform team was the fastest unblock.
Ownership gaps. Multiple platform teams have overlapping responsibilities and no single owner. Identify your escalation path before you need it.
Dev tenant lifecycles. Dev tenants may have undocumented auto-deletion policies. Don't rely on a dev tenant as a long-lived staging environment.

Start security and compliance early

Registering an app and configuring permissions is the easy part. For a cross-tenant connector at enterprise scale, we also needed:

A threat model.
A privacy review.
A Responsible AI review.
Design reviews from platform teams.
Security exception approvals.

No template existed. No checklist. No predefined path. This was a significant effort that started well before we wrote code.

Make connector content discoverable

Even with successful ingestion, Copilot may not prioritize your content. Emails and user files rank higher by default. Connector content ranking varies across clients. There's no visibility into why a result was or wasn't surfaced.UserPrincipal support — the ability to attach a user identity to an indexed item so it's ranked with the same signals as that user's emails and files — is an important platform improvement for us. We plan to adopt it in the near future, with the goal of making connector content show up more reliably alongside a user's other work in Copilot results.

Design for throttling and shared limits

At approximately 1 million documents, throttling became an important design consideration. We handled it with retry logic, exponential back-off, monitoring for 429 responses, and operational alerts so we could detect ingestion slowdowns quickly.

The Microsoft 365 Copilot connectors platform has a global rate limit shared across all connectors in a tenant. If another connector spikes ingestion, yours gets throttled — and the 429 doesn't tell you why or who's consuming the budget. Today, there's no visibility into the shared quota, no priority system, and no way to reserve capacity, so it's worth designing your pipeline to tolerate unexpected back-pressure.

Build the connector for scale

Our architecture focused on one principle: keep the source content separate from the ingestion compute. That choice made the pipeline easier to retry, easier to monitor, and easier to evolve as the documentation platform changed.

Separate data from compute

A core design principle was keeping the data layer completely separate from the ingestion compute. The documentation platform stores content in Azure Blob Storage — that's the source of truth. The ingestion pipeline never owns or duplicates that data. Instead, it reacts to changes and transforms on the fly.

Blob Change Feed — Azure Blob Storage's change feed emits events whenever documents are created, updated, or deleted. This is the trigger for all ingestion work — no polling, no scheduled full crawls.
Azure Function (event-driven) — an Azure Function listens to the change feed and processes each event. It reads the blob, transforms the content, enriches metadata, and pushes the item to the Microsoft Graph connectors API. The function is stateless — all state lives in the storage layer and the Microsoft Graph platform.
Storage as the boundary — the function has read access to blob storage but never writes back. Data flows one direction: storage → function → Graph API. This keeps the pipeline simple to reason about and safe to retry — reprocessing a blob event is always idempotent.
Graph API ingestion — items are pushed with retry logic, back-off on 429s, and observability via Application Insights.

This separation means:

The documentation platform can evolve its storage independently — new formats, new metadata, reorganizations — without touching the ingestion pipeline.
The pipeline scales horizontally via Azure Functions consumption plan — spikes in content updates don't require capacity planning.
Failures are isolated — a bad blob doesn't block other ingestion, and the change feed provides natural retry semantics.

Iterate on schema design

We treated schema design as the highest-leverage decision. Through four iterations, we significantly improved retrieval quality — entirely through schema and metadata refinement:

Mapped document types (TSGs, runbooks, architecture docs, onboarding guides) to distinct property sets.
Wrote detailed connection descriptions optimized for Copilot's ranking.
Added custom properties for freshness and ownership signals.
Tested with real user queries, not synthetic data.

Use secure authentication and deployment patterns

A few patterns kept the deployment story simple across environments:

Managed Identity for service-to-service communication in production.
Infrastructure-as-code for consistent deployment across commercial and sovereign clouds.
Environment-specific configuration abstracted from the start.

Measure retrieval quality

One benefit of onboarding to the Microsoft 365 Copilot platform was access to the Search Evaluation framework used by the Copilot team. This helped us measure retrieval quality, including precision and recall against real user queries, without building evaluation infrastructure from scratch. We used this framework to test pipeline changes and catch regressions before they reached users.

Monitor connector health

A healthy connector is a prerequisite for everything else, so we built:

Alerting on ingestion failures and throttling spikes.
Recovery automation for re-ingestion scenarios.

See the impact

Once the connector was live, three things stood out: the portal became a platform, an ecosystem of agents formed on top of it, and we kept the controls we needed while gaining new ways to measure quality.

From portal to platform

The documentation platform moved from being a destination people visited to a knowledge source that powers AI experiences across Microsoft. Users no longer need to navigate to the portal — knowledge surfaces directly in Copilot Chat, Copilot in Word, Copilot in VS Code, and Azure Copilot. Consumption is ambient and contextual, embedded in existing workflows.

An ecosystem of agents

The core value proposition of the Microsoft 365 Copilot platform is this: push your content once, and it's enabled across multiple AI surfaces. That's exactly what happened.

300+ Copilot Studio agents now build on the connector. Content surfaces in Copilot Chat, Copilot CLI, Work IQ (Microsoft's workplace intelligence experience), and other AI-powered developer tools — all from a single ingestion pipeline. Teams within Microsoft created:

Incident response assistants that help surface relevant troubleshooting guides.
Onboarding copilots that pull architecture docs contextually.
Domain-specific Q&A agents scoped to their team's content.
Support augmentation workflows with human oversight.

Because we invested in getting the connector right once — clean schema, proper access controls, reliable ingestion — supported Copilot experiences reuse that content automatically. None of the 300+ agents required additional integration work from our team.

Measurable quality and preserved governance

Alongside the new capabilities, the shift preserved what mattered most: existing controls and a way to measure what we were doing.

Programmatic access at scale. The Copilot Retrieval API lets teams with appropriate access query the indexed knowledge programmatically, without the documentation team's involvement. Single ingestion, multi-surface consumption.
Governance stayed centralized. Despite AI integration, the connector continues to rely on existing Microsoft 365 security and access controls. Governance policies and access restrictions remain centrally managed. This was critical for sovereign cloud deployment and regulated environments.
Quality became measurable. With evaluation frameworks in place, we can quantify answer quality and continuously improve — something that wasn't possible when the platform was purely a static portal.

Apply these recommendations when building connectors

If you are planning a Microsoft 365 Copilot connector, these are the practices we would prioritize before moving from prototype to production:

Start security and compliance conversations before writing code — budget significantly more time than you expect.
Treat schema design as your highest-leverage decision — test with real Copilot queries early and iterate aggressively.
Build evaluation from day one — you need to measure whether Copilot is actually using your content effectively.
Build health monitoring for the connector itself — not just the pipeline.
Design for the ecosystem — if you build it well, people will build on it in ways you didn't anticipate.

Make the investment worthwhile

The public docs for Microsoft 365 Copilot connectors cover the "what." This post covers the "how" — and more importantly, the "why it's worth it."

Security approvals took months. Schema iteration took four rounds. Operational readiness took ownership none of us had budgeted for. But the payoff is real: your organization's knowledge becomes accessible through AI, grounded in authoritative content and available across supported Microsoft 365 Copilot experiences.

The platform is powerful. Getting there takes work. In our first year of production, 300+ agents were built on the connector — none of which required additional integration work from our team.

Get started

Join the conversation

Have you built a Microsoft 365 Copilot connector at scale? We'd love to hear what you learned — share your experience in the comments below, and let us know which patterns worked (or didn't) in your environment.

Did you know? The Microsoft 365 Roadmap is where you can track upcoming updates across Microsoft 365 apps and services. Microsoft 365 Copilot release notes are where you can review generally available Copilot features by platform. Check both resources regularly for the latest status, and note that roadmap dates are tentative and subject to change.

Copilot Studio agent works in M365 Copilot but silent in Teams personal chat (0 Studio sessions)

MiroslavPistek — Thu, 23 Jul 2026 13:21:34 GMT

We are troubleshooting a Copilot Studio agent that works in Microsoft 365 Copilot and Studio test, but does not receive inbound activities from Microsoft Teams personal chat.

Environment

- Agent: Caflou Asistent v1.0.8

- Channels: Microsoft 365 Copilot + Microsoft Teams (published / synchronized)

- Agent Registry: Available

- Entra/bot appId: 7e4a53cc-f51c-4772-ad93-e3f1e8060f35

- Maker-provided tool connection works in Studio (example getTasks HTTP 200)

What works

1) Microsoft 365 Copilot agent chat / shareLink → agent replies; Studio sessions with channel "Microsoft 365 Copilot"

2) Copilot Studio test pane → agent responds

What fails

1) Teams personal chat (desktop AND web): user message visible in "Caflou Asistent" chat, no agent reply

2) Studio Monitor: Teams channel sessions = 0 for probes (only M365 Copilot sessions in last 7 days)

3) Teams Admin Center → Manage apps: 0 results for name "Caflou" and full appId (other apps searchable); UAM banner present while Registry shows Available

Classification

- Teams inbound activity not reaching Copilot Studio runtime

- Not OAuth / not MCP host / not publish alone (M365 path proves runtime alive)

- Secondary: Registry Available ≠ TAC Manage apps listing

Questions

1) Why would Teams 1:1 never create a Studio conversation while M365 Copilot does?

2) Is missing TAC Manage apps row expected under Unified App Management when Registry shows Available?

3) Best next diagnostic when Monitor shows 0 Teams sessions after confirmed client send?

Constraints: no Copilot Studio paid support plan; looking for field experience / known product issues. No secrets posted.

CS agent OK in M365 Copilot; Teams chat silent / no Studio session

MiroslavPistek — Thu, 23 Jul 2026 13:18:40 GMT

We are troubleshooting a Copilot Studio agent that works correctly in Microsoft 365 Copilot and in the Copilot Studio test surface, but does not receive inbound activities from Microsoft Teams personal chat.

Environment and evidence:

- Agent: Copilot Studio agent (custom business assistant)

- Copilot Studio agent ID: 88901b10-… (truncated)

- Teams/Entra app ID: 7e4a53cc-… (truncated)

- Manifest version: 1.0.8

- Channel configuration: Microsoft 365 Copilot + Microsoft Teams

- Publish: Succeeded / Channel state: Synchronized

- Agent Registry: Available

- Authentication: Integrated / Tool credentials: Maker-provided

- MCP/custom connector runtime: working (Studio tool test HTTP 200)

- Microsoft 365 Copilot routing: working

Failure specific to Teams:

- Messages in Teams web and desktop appear delivered in the agent personal chat

- Agent never replies

- Studio monitor has M365 Copilot sessions, but no Teams session for those timestamps

- Teams Admin Center Manage apps returns 0 results by name or exact app ID despite Agent Registry Available

- Intentionally not republishing / reconnecting OAuth / rewiring connectors because M365 Copilot path proves the same agent+connection works

Classification: FAIL — Teams inbound activity is not reaching the Copilot Studio agent.

Questions:

1. Anyone seen agents that work in M365 Copilot but receive no personal-chat activities from Teams?

2. Can Agent Registry show Available while TAC Manage apps has no matching row?

3. Known Unified App Management sync issues for Copilot Studio agents?

4. Separate Teams app catalog deployment/approval required when Teams channel shows Synchronized?

5. Which logs prove whether Teams attempted to route the inbound activity?

6. Known manifest / personal scope / app-centric management / conversation-binding issues with this split?

Looking for confirmed production experience or documented workaround. Redacted screenshots available; no tokens/secrets.

Discover a community gallery of reusable skills for AI agents

CoralieSimonaire — Tue, 21 Jul 2026 12:37:42 GMT

Save this link, it is a gem for your Copilot agents.

This community-driven skills gallery brings together dozens of ready-to-use examples that you can download and import into:

Agents built with Copilot Studio
Copilot Cowork
Microsoft Scout

As a reminder, a skill is a reusable set of instructions that gives an agent a specific capability.

You will find use cases covering document analysis, content creation, document conversion, automation, and data processing.

For those of you working on agent development in Copilot Studio, this is an excellent source of inspiration.

Beyond downloading existing skills, it is also a great way to discover how other creators structure their skills, organize their instructions, and design reusable capabilities across multiple agents.

Skills Gallery: https://microsoft.github.io/cat-agent-skills/

Issue: Cannot Share Agent to New Editor in Copilot Studio New Experience

Kopigao — Sun, 19 Jul 2026 13:00:48 GMT

In the new UX, sharing agents is restricted:

I can share agents for viewing/testing (read-only).
But I couldn’t find the editor rights when the agent is shared in the new experience.

cam advice when this features be released? Is there a workaround to have editors for new user experience

New Agent Experience - Adding Excel Tool

RookieFromTunis — Sun, 19 Jul 2026 07:54:24 GMT

Hello everyone,

I want an agent in the new Copilot Studio experience to read the latest row from an Excel table and then append a new row.

Has anyone successfully configured the Excel Online (Business) tools dynamically in the new Copilot Studio experience? Which values should be passed for Location, Document Library/Drive, and File, etc.?

In preview, the agent fails but when I prompt it, it ends up adding the row. If anyone could also guide me to resources to learn about how to configure tools in the new experience, I would even be more grateful.

Thank you !

Enhance Teaching and Learning with Microsoft Copilot: A New Era for Schools and Universities

JohnNaguib — Fri, 17 Jul 2026 15:09:58 GMT

Artificial Intelligence is transforming education, helping institutions create more engaging, personalized, and efficient learning experiences. Among the latest innovations, Microsoft Copilot stands out as a powerful AI assistant designed to support educators, students, and administrators in their daily work.

https://dellenny.com/enhance-teaching-and-learning-with-microsoft-copilot-a-new-era-for-schools-and-universities