rss.livelink.threads-in-node

Building an Event-Driven AI HelpDesk on Azure (with Zero API Keys)

KonstantinosPassadis — Sat, 25 Jul 2026 18:35:30 GMT

Building AI agents is one thing, but deploying them securely at enterprise scale is another challenge. If you’re still relying on hardcoded API keys to connect your AI services, it’s time to move on. Join a live, in-depth demo of HelpDesk Copilot—an open-source, event-driven AI service desk built entirely on Azure with zero API keys.

This session will cover the foundry-ticketing architecture, showing how to orchestrate autonomous AI agents using cloud-native patterns, combining Microsoft Foundry Agents’ conversational intelligence with Dapr’s event-routing, all running on Azure Container Apps.

You’ll also learn about the “Zero API Key” security model using Managed Identities and Azure RBAC, and pick up best practices for serverless, scale-to-zero cloud deployments. Perfect for Cloud Architects, AI/DevOps Engineers, and Backend Developers aiming to build secure, scalable, event-driven AI apps on the Microsoft stack.

The Next Generation of Agents with Azure and Microsoft Foundry

KonstantinosPassadis — Sat, 25 Jul 2026 10:07:23 GMT

Every company has a help desk, and every help desk answers the same twenty questions over and over: my VPN keeps dropping, I lost my MFA device, I need access to the Finance share. Sound familiar? That is exactly what makes it the perfect proving ground for an AI agent — not another chat demo that just talks, but a system that answers from real documentation, knows when it is not allowed to answer, and hands off to humans through a real channel.

So that is what we are building today: HelpDesk Copilot, a Contoso IT service desk where a Microsoft Foundry agent triages employee questions, answers them grounded on an IT knowledge base with citations, and — when policy demands a human — creates a ticket that flows asynchronously through Dapr and Azure Service Bus into Table Storage and an Adaptive Card in a Microsoft Teams channel.

The whole thing runs on Azure Container Apps, is provisioned entirely with Terraform, and — my favorite part — contains zero API keys. Every service-to-service call, from pulling container images to invoking the Foundry agent, uses Microsoft Entra ID and managed identities. The Foundry account has local key authentication disabled outright.

Here is what we will cover:

The architecture: three ACA apps, one Foundry Prompt Agent, and an event-driven ticket pipeline
Why I chose one agent instead of a multi-agent orchestra — and why that was the honest choice
Grounded, streaming answers with Foundry File Search and citations
The escalation path: Dapr pub/sub, a Service Bus topic, deterministic ticket IDs, and idempotency
The identity model: five managed identities, zero connection strings
Terraform notes: the Foundry provider landscape is not what you expect
Observability with OpenTelemetry and Foundry's cloud evaluation API

Grab a coffee — let's build!

The Architecture

Three container apps live inside one ACA environment, and each one has a deliberately different network posture:

Frontend — React 18 + Vite served by nginx, with external ingress. This is the only public URL: the chat UI and a live ticket panel.
API — FastAPI with a Dapr sidecar, internal ingress only. It runs the agent conversation loop, streams Server-Sent Events, executes tools, and publishes ticket events.
Ticket worker — FastAPI with a Dapr sidecar and no ingress at all. It exists only to consume Service Bus messages via Dapr, and KEDA wakes it from zero replicas based on subscription backlog.

The frontend's nginx proxies browser calls to the API over the ACA environment's internal DNS — the API is never exposed to the internet. Around the environment sit Microsoft Foundry (a Prompt Agent plus a File Search vector store), a Service Bus topic, Table Storage as the ticket read model, Key Vault holding exactly one secret, Azure Container Registry, and Application Insights on a Log Analytics workspace.

One Agent, Not an Orchestra

My original design called for an orchestrator agent routing to specialist agents. Reality intervened: the Connected Agents pattern I planned to use is deprecated, and the workflow orchestration alternatives are still in preview. I could have demoware'd my way around that — instead, I redesigned around one Foundry Prompt Agent with three capabilities:

File Search over the Contoso IT knowledge base, for grounded answers with citations
A local create_ticket function tool, for escalation
A local get_ticket_status function tool, for lookup

Its instructions enforce the policy: search first, cite your source, and only create a ticket when no procedure covers the problem — or when the procedure explicitly requires human intervention (Finance-share access, a lost device, all MFA methods gone).

Here is the takeaway I want you to keep: a single well-instructed agent with sharp tools beats a fragile multi-agent mesh for this problem size. Multi-agent is a topology, not a virtue. When the platform's orchestration story stabilizes, this design has an obvious seam to split along — until then, one agent is simpler to reason about, cheaper to run, and easier to evaluate.

Similar honesty applies to retrieval: with ten markdown documents, Azure AI Search would be architectural cosplay. Foundry's built-in File Search vector store is the right-sized tool. When the corpus grows into thousands of documents needing hybrid or semantic ranking, that is the upgrade path.

The Knowledge Path: Streaming Grounded Answers

An employee asks: "My VPN keeps dropping every hour." The flow:

The frontend POSTs to /chat with the message and an optional conversation_id
The API creates (or continues) a Foundry conversation and requests a streamed response
The agent runs File Search over the IT docs and gets relevant chunks back
Text deltas and file citation annotations stream back through the API as Server-Sent Events
The employee watches the answer type itself out, with the source document cited beneath it

Citations are not decoration. In an IT support context, "the answer came from the official VPN procedure" is the difference between a trustworthy assistant and a liability. The frontend de-duplicates cited filenames per answer and shows them inline.

The heart of the API is the tool-call loop. When the agent requests a local function, the API executes it and feeds the result back into the same Foundry conversation, so the agent composes the final employee-facing message. The agent stays the author of the conversation; the API stays the executor of side effects. Here is the loop, from agent_service.py:

while True: stream = openai.responses.create( input=pending_input, conversation=conversation_id, stream=True, extra_body={"agent_reference": agent_reference}, ) function_outputs = [] for chunk in stream: if chunk.type == "response.output_text.delta": yield {"event": "delta", "data": {"text": chunk.delta}} elif chunk.type == "response.output_item.done": item = chunk.item if item.type == "function_call": yield {"event": "tool_call", "data": {"name": item.name}} output = self._execute_tool(item.name, item.arguments, conversation_id) function_outputs.append({ "type": "function_call_output", "call_id": item.call_id, "output": json.dumps(output), }) if function_outputs: pending_input = function_outputs continue # submit tool outputs and let the agent finish its answer break

The Escalation Path: Events, Not Awaits

Now the interesting request: "I need Finance-share access for an audit." The knowledge base says restricted Finance access always requires a ticket. The agent emits create_ticket, and this is where the architecture earns its keep:

The API validates the tool input and computes a deterministic ticket ID
It publishes a ticket.created event via its Dapr sidecar to the Service Bus topic ticket-events — and immediately streams the confirmation with the ticket ID back to the employee
Dapr delivers the event to the worker through the ticket-worker subscription
The worker upserts the ticket into Table Storage, reads the optional Teams webhook URL from Key Vault, and posts the payload to a Power Automate HTTP flow
The IT team gets an Adaptive Card in their Teams channel. A human is now in the loop — a real one.

Chat acknowledgement never waits for persistence or Teams delivery. Three deliberate consequences follow.

Idempotency end-to-end. The ticket ID is derived, not generated:

def compute_ticket_id(conversation_id: str, subject: str) -> str: """Deterministic ticket ID from (conversation, subject) so a repeated create_ticket tool call for the same issue in the same conversation collapses to the same ID instead of creating a duplicate. """ key = f"{conversation_id}:{subject.strip().lower()}" return hashlib.sha256(key.encode("utf-8")).hexdigest()[:16]

If the model retries the tool call, or Service Bus redelivers the event (the subscription allows up to 10 deliveries), the worker upserts the same row instead of minting duplicate tickets. Idempotency is designed in at the ID level, not bolted on with dedup logic afterwards.

Eventual consistency, explained honestly. The ticket row may not exist for a few seconds while KEDA wakes the worker. Both the agent's status tool and the ticket endpoints treat "not visible yet" as a normal state and say so, and the UI polls every five seconds. Distributed systems do not hide their nature here — they narrate it.

A topic, not a queue. Today there is one subscription, so operationally it behaves like a work queue. But "a ticket was created" is an event, and tomorrow an ITSM connector, an audit log, or an analytics pipeline can each get their own subscription without the API changing a single line. Publishers describe facts; subscribers decide what facts mean.

This is the payload that travels unchanged from tool call, through Dapr and Service Bus, into the worker, Table Storage, and the Teams flow:

{ "type": "ticket.created", "ticket_id": "9a549ad5d5f723d4", "conversation_id": "conversation-id", "subject": "Request for access to finance shared drive", "description": "I need access to the finance shared drive for an audit.", "category": "shared-drive-access", "urgency": "high", "requester_email": "email address removed for privacy reasons", "status": "New", "created_at": "2026-07-17T16:30:28.396538+00:00", "updated_at": "2026-07-17T16:30:28.396538+00:00" }

And the failure mode is designed too: if the Teams webhook is unset or down, the worker logs a warning and keeps the persisted ticket. Persistence happens first and returns success or retry to Dapr based only on the table write — so a Teams outage cannot cause repeated ticket writes.

Zero Keys: The Identity Model

This is the part I am proudest of. Every hop authenticates with Entra ID via DefaultAzureCredential — in ACA, AZURE_CLIENT_ID selects each app's user-assigned managed identity; locally, the same code rides on az login.

API identity — AcrPull, Foundry agent access, Storage Table Data Reader, Key Vault Secrets User, Service Bus Sender. It invokes the agent, reads tickets, publishes events.
Worker identity — AcrPull, Storage Table Data Contributor, Key Vault Secrets User, Service Bus Receiver. The sole writer of tickets.
Frontend identity — AcrPull. It pulls its image, nothing more.
Shared Dapr identity — Service Bus Data Owner, scoped to authenticating the Dapr component and the KEDA scaler.

Notice the reader/writer split: the API physically cannot modify a ticket, and the worker is the only writer. Least privilege is not a slide bullet here; it is enforced by RBAC per identity. The single unavoidable secret — the Power Automate webhook URL, which is bearer-style by nature — lives in Key Vault, and nowhere else.

Terraform Notes: The Provider Landscape Is Not What You Expect

Terraform is the source of truth for all Azure resources, split into four modules: platform, foundry, observability, and aca. Two lessons here were worth the price of admission.

The obvious-looking resources are the wrong ones.When I started, I assumed I would needazapi for the Foundry pieces. The real surprise was different: azurerm 4.x does ship azurerm_ai_foundry and azurerm_ai_foundry_project — but those provision the classic, hub-based Foundry model, not the GA project-based Foundry Agent Service. The current model is provisioned directly on a Cognitive Services account, fully covered by azurerm, no azapi required:

resource "azurerm_cognitive_account" "this" { name = "${var.prefix}-${var.environment}-foundry-${var.random_suffix}" resource_group_name = var.resource_group_name location = var.location kind = "AIServices" sku_name = "S0" # Required for the account to work as a Foundry resource # (agents, projects) rather than plain Cognitive Services. custom_subdomain_name = "${var.prefix}-${var.environment}-foundry-${var.random_suffix}" project_management_enabled = true # Enforces "no API keys anywhere" at the account level: only # Entra ID auth is accepted, key-based auth is rejected outright. local_auth_enabled = false identity { type = "SystemAssigned" } }

There was one genuine gotcha, though: the built-in Foundry Agent Consumer role grants enough to call the Responses API against an existing thread, but conversations.create() — which the API calls on every new chat — needs the agents/write data action too. I confirmed that live, with a 403 to show for it. The broader Foundry User role would work, but it also grants key-listing and the whole Cognitive Services surface. The fix is a small custom role definition granting exactly the three data actions the chat runtime exercises: interact, agents read, agents write. Least privilege, again.

2. Terraform provisions infrastructure — it does not configure agents.

The vector store, document upload, and agent version are deliberately not Terraform resources. A seed_knowledge.py bootstrap runs after terraform apply, authenticated as a principal Terraform granted the Foundry Project Manager role. Agent instructions and knowledge content change on an application cadence, not an infrastructure cadence — mixing the two lifecycles is how you end up re-uploading your knowledge base because you resized a container app. Dapr's entity management is disabled for the same reason: Terraform explicitly owns the topic and subscription.

Observability and Evaluation

The API initializes Azure Monitor OpenTelemetry, and every Foundry invocation gets a custom agent.invoke span carrying the agent name, conversation ID, selected tools, and input/output token counts when the response exposes them. Platform logs and metrics from all three apps flow to the same Log Analytics workspace. Ask "what did that conversation cost and which tool did it pick?" and App Insights answers.

There is also an evaluation script that pushes ten fixed questions through Foundry's cloud evaluation API, scoring intent resolution, coherence, and task adherence. File-search questions evaluate end-to-end; locally executed function tools need a response-capture approach — a limitation worth knowing before you promise your boss automated agent QA.

If this section feels short, good — agent observability and governance in production deserves its own post, and it is getting one. Consider this the trailer.

What This Deliberately Is Not

Honesty section. HelpDesk Copilot is production-shaped, not production-finished:

No browser authentication yet. Conversation IDs partition the ticket panel but are not an authorization boundary. A real rollout adds Entra ID sign-in and server-side authorization before exposing ticket data.
Tickets stay New. The human handoff is the real Teams notification, not a simulated ITSM lifecycle. Wiring status updates back from an ITSM tool is exactly what the topic's future subscriptions are for.
Global ticket lookup scans partitions. Fine at demo volume; a high-volume system adds an index.

I would rather ship a clear boundary than a hidden one.

Try It

The full source — Terraform modules, all three services, the knowledge base, seed and evaluation scripts — is on GitHub: passadis/foundry-ticketing

Quickstart: terraform apply, run seed_knowledge.py, build and push the three images, and ask the public URL why your VPN keeps dropping. With scale-to-zero on all three apps and a small model deployment, idle cost is close to nothing — the architecture only spends money when someone needs help.

Conclusion

The AI part of this solution is maybe twenty percent of the code. The rest is the unglamorous engineering that makes an agent deployable: identity, ingress boundaries, idempotent events, honest eventual consistency, IaC lifecycle boundaries, and telemetry. That ratio is the real lesson — and it is exactly why Azure Container Apps plus Microsoft Foundry is such a productive pairing: the platform absorbs the undifferentiated heavy lifting so the interesting decisions remain yours.

Next up in this series: taking the agent.invoke spans further — tracing, token economics, drift, and governance for agents in production with Foundry's control plane and Azure Monitor.

Until then — happy building! 🚀

Governance Is the New Bottleneck: What Agent 365 Means for Admins ?

Surya_Narayana — Thu, 23 Jul 2026 01:48:45 GMT

Hi all , following up on my last post about token limits, I wanted to write about something that's been on my mind a lot lately: the sheer number of agents quietly showing up across our tenant. Not just the ones we built deliberately in Copilot Studio, but ones people spun up in Power Platform, ones connected through Teams, and a few I genuinely couldn't trace back to an owner when I went looking. That's the moment this topic stopped being theoretical for me.

For the last couple of years, the Microsoft AI conversation was mostly about capability -what can Copilot do, which model is better, how do I write a good prompt. That conversation hasn't gone away, but a second one has caught up to it fast: who's actually watching all of this. Microsoft's own 2026 Work Trend Index makes the shift explicit this isn't about saving a few minutes in Outlook anymore, it's about organizations redesigning how work gets divided between people and agents. And the moment agents start acting semi-independently across your tenant, "how many do we have, and what are they allowed to touch" becomes a real operational question, not a hypothetical one.

That's exactly the gap Microsoft Agent 365 is built to close. It went generally available on May 1, 2026, alongside Microsoft 365 E7, and I think it's worth understanding properly especially if you're the one who ends up fielding the "wait, there's an agent doing what?" conversation.

What Agent 365 Actually Is (and Isn't)

The first thing worth clearing up: Agent 365 doesn't build agents. That's still Copilot Studio's job, or Foundry, or whatever platform your team is using. Agent 365 is the layer that sits on top of all of that it's a control plane, not a construction tool. Think of it less like "another AI product" and more like the admin and security backbone that was honestly missing from the picture until now.

Microsoft frames it around three pillars: observe, govern, and secure. In practice, that means every agent in your tenant whether it was built in Copilot Studio, imported from AWS or Google Cloud, or even running locally on someone's Windows machine gets registered, gets its own identity through Microsoft Entra, and becomes something you can actually see and act on instead of just hoping it's behaving.

That identity piece is the part I think gets underrated. Each agent gets its own Entra Agent ID, the same way a human user would. That's a meaningful shift it means conditional access policies, auditing, and compliance tooling that already exist for people can now extend to agents instead of treating them as some invisible background process.

Why This Matters Right Now

Here's the honest version of what's been happening across a lot of organizations, including bits of what I've seen firsthand: agent creation has gotten easy. Almost too easy. Between Copilot Studio, Power Platform, and now agentic mode built directly into Word, Excel, and PowerPoint, it doesn't take much for someone in a business unit to spin up something that's technically an AI agent with access to real data without IT or security ever being looped in.

Microsoft has been fairly direct about this risk themselves, which I appreciated seeing in writing rather than just implied: the speed of agent development shows real value, but without guardrails, that pace turns into blind spots, lower ROI, and genuine security exposure. That's not vendor fear-mongering, that's just what happens when adoption outpaces oversight in any technology, and agents are no exception.

What makes this particular moment different from past "shadow IT" waves is that agents don't just store or move data they can act on it. An agent with the wrong scope isn't just a compliance footnote, it's something that could send an email, modify a file, or trigger a workflow on its own. That's a different risk category than an unsanctioned spreadsheet sitting in someone's OneDrive.

What You Actually Get With Agent 365

A few capabilities stood out to me as genuinely useful rather than just checkbox governance:

The overview dashboard gives you a real-time view of your entire agent fleet total registered agents, active users, connected platforms, runtime hours, and risk signals, all in one place. Before this, getting even a rough headcount of "how many agents exist in our tenant" was a manual, frustrating exercise.

Registry sync extends that visibility beyond Microsoft's own tools. It can pull in agents built on AWS Bedrock and Google Cloud, so you're not stuck with three different governance stories depending on where an agent happens to live. For organizations that are realistically never going to be 100% single-vendor, that matters.

Lifecycle actions install, publish, block, unblock, delete, reassign ownership are now available directly from the registry. That's a big deal operationally. Before, tracking down who owned a rogue or abandoned agent could turn into an actual investigation. Now it's a few clicks.

Local agent controls through Defender and Intune are rolling in too, extending management down to agents running on individual Windows endpoints, not just cloud-hosted ones. Given how much agent activity is starting to happen at the device level, this closes a gap that would've otherwise been a blind spot.

Conditional access for agents, through Entra, means you can apply the same kind of dynamic, granular access policies to agents that you'd apply to a human user which is really the whole philosophical shift Agent 365 represents: agents aren't a separate, ungoverned category anymore, they're first-class identities in your tenant.

What This Means for Admins, Practically

If you're managing a tenant with any real Copilot or agent activity, here's where I'd actually start:

Don't wait for "full autonomy" to engage. It's tempting to think governance can wait until agents are doing something more dramatic than they are today. Microsoft's own guidance pushes against that the advice is to establish visibility and guardrails early, while adoption is still accelerating, not after.

Get a real inventory first. Before writing new policies, it's worth just knowing what already exists. I'd genuinely bet most tenants have more agents running than the admin team could name off the top of their head. The overview dashboard is the fastest way to close that gap.

Loop in more than just IT. Agent 365 licensing and controls touch the M365 admin center, Entra, Defender, Purview, and Intune which means this isn't a single-team rollout. Security, compliance, and helpdesk all need to understand what's changing, especially the distinction between Frontier (preview, no production SLA) and GA (production-ready, supported).

Understand the licensing model before you scope a rollout. Agent 365 is licensed per human user — the person who manages, sponsors, or is served by an agent rather than per agent. It's available standalone at $15 per user per month, or bundled into Microsoft 365 E7. Worth mapping that against your actual agent-using population rather than assuming it's a flat cost per bot.

Treat this as incremental, not a one-time setup. Microsoft has said plainly that Agent 365's capabilities will keep evolving as adoption patterns and governance models mature. This isn't a project you finish and close out it's closer to how you'd think about identity and access management generally: ongoing, not a one-time rollout.

The Bigger Shift Underneath All This

What I find genuinely interesting about Agent 365 is what it signals about where Microsoft thinks this is all heading. They're not just selling a better Copilot anymore they're positioning Microsoft 365 as the place where AI-driven work gets governed, regardless of which vendor's model or platform an agent actually runs on. Whether that's the right long-term answer for every organization is a fair thing to debate. But the underlying problem it's solving that agents were multiplying faster than anyone's ability to see or control them is real, and I don't think it's specific to Microsoft shops.

If your organization is building agents in Copilot Studio, experimenting with Foundry, or even just watching Copilot's agentic mode quietly take on more autonomous work in Word and Excel, this is worth getting ahead of. The teams that treat agent governance as a foundational layer now are going to have a much easier time scaling adoption later than the ones who bolt it on after something goes wrong.

Curious whether others are already rolling out Agent 365, or still in the "let's figure out how many agents we actually have" phase I suspect a lot of us are somewhere in between. Would love to hear how your organization is approaching this.

Cheers, and happy reading.

Surya Vennapusa-MCT

Data Days 2026 – Preparing for the PL-300 Exam

GulnazMushtaq — Wed, 22 Jul 2026 17:23:29 GMT

We are excited to be hosting the Data Days 2026 event and would love to welcome everyone from the data and cloud community!

If you're planning to earn the Microsoft certification or want to strengthen your Microsoft Data & Analytics skills, this session is for you.

📅 Data Days 2026 – Preparing for the PL-300 Exam

Join us to explore:
✅ The Microsoft PL-300 exam objectives and skills measured
✅ Effective preparation strategies and exam tips
✅ How PL-300 aligns with Microsoft Fabric, Power BI, and the broader Microsoft data ecosystem
✅ How this certification can accelerate your career in Data Analytics and Business Intelligence

Whether you're just starting your certification journey or looking to sharpen your skills, this is a great opportunity to learn from experts, engage with the community, and expand your professional network.

📍 Register here: https://teams.microsoft.com/l/meetup-join/19%3ameeting_YmQwZjM0Y2YtOTViMS00YWFiLWI0YjYtMTZmNThkNWJkOWIx%40thread.v2/0?context=%7b%22Tid%22%3a%22b4c9f32e-da17-4ded-9c95-ce9da38f25d9%22%2c%22Oid%22%3a%221c23bec6-d3c9-4b8c-8959-6dc752c2f1c1%22%7d

We look forward to connecting with you and seeing you at the event. See you there!

#DataDays2026 #PL300 #MicrosoftFabric #PowerBI #DataAnalytics #BusinessIntelligence #MicrosoftLearn #CloudCommunity #AICommunity #TechCommunity #Learning #CareerGrowth

Microsoft Teams y SharePoint: Colaboración Segura y Gestión Inteligente de la Información.

BAuroraRzValles — Sun, 19 Jul 2026 02:37:51 GMT

Women in M365 Articulo 4 Julio 2026.

La transformación digital ha cambiado la forma en que las organizaciones trabajan, colaboran y comparten información. Los equipos ya no dependen de una ubicación física para comunicarse; hoy, la productividad requiere herramientas que permitan colaborar en tiempo real sin comprometer la seguridad de los datos.

Dentro del ecosistema de Microsoft 365, Microsoft Teams y SharePoint forman una plataforma integrada que facilita la comunicación, la administración documental y la colaboración segura. Juntas, estas herramientas ayudan a organizaciones de todos los tamaños a optimizar sus procesos, proteger su información y mantener el cumplimiento de las políticas de seguridad.

¿Qué es Microsoft Teams?

Microsoft Teams es la plataforma de colaboración de Microsoft 365 que integra chat, videollamadas, reuniones, telefonía, aplicaciones y almacenamiento de archivos en un solo lugar.

Entre sus principales beneficios destacan:

Comunicación instantánea mediante chats individuales y grupales.
Reuniones virtuales con funciones avanzadas de colaboración.
Coautoría de documentos en tiempo real.
Integración con aplicaciones de Microsoft 365 y servicios de terceros.
Espacios de trabajo organizados por equipos y proyectos.

Teams permite que los colaboradores permanezcan conectados sin importar dónde se encuentren, facilitando la continuidad operativa en modelos presenciales, híbridos y remotos.

¿Qué es SharePoint?

SharePoint es la plataforma de gestión documental e intranet de Microsoft 365. Su objetivo es centralizar la información empresarial para que esté disponible de forma segura y organizada.

Con SharePoint es posible:

Crear bibliotecas documentales.
Administrar versiones de archivos.
Compartir documentos con permisos específicos.
Automatizar procesos mediante Power Automate.
Publicar sitios internos para comunicación organizacional.
Controlar el acceso a la información según los roles de cada usuario.

Cada equipo creado en Microsoft Teams cuenta con un sitio de SharePoint que almacena los documentos compartidos, lo que permite una administración más eficiente y segura de la información.

La integración entre Teams y SharePoint

Una de las mayores fortalezas de Microsoft 365 es la integración entre ambas herramientas.

Cuando un usuario comparte un archivo en un canal de Teams, el documento se almacena automáticamente en SharePoint. Esto ofrece beneficios como:

Un único repositorio de información.
Control de versiones.
Edición simultánea por varios usuarios.
Recuperación de documentos.
Gestión centralizada de permisos.

Esta integración elimina la duplicación de archivos y reduce el riesgo de trabajar con versiones desactualizadas.

Seguridad y protección de la información

La colaboración debe ir acompañada de mecanismos sólidos de seguridad. Microsoft 365 incorpora múltiples capacidades para proteger la información durante todo su ciclo de vida.

Entre ellas se encuentran:

Gestión de permisos

Es posible definir quién puede visualizar, editar o compartir documentos, aplicando el principio de menor privilegio para reducir riesgos.

Etiquetas de confidencialidad

Con Microsoft Purview se pueden clasificar documentos según su nivel de sensibilidad, aplicando protección automática como cifrado, marcas de agua o restricciones para compartir.

Prevención de pérdida de datos (DLP)

Las políticas de Data Loss Prevention ayudan a evitar que información confidencial, como datos financieros, información de clientes o documentos legales, sea compartida de manera inapropiada.

Auditoría y monitoreo

Las organizaciones pueden registrar actividades relacionadas con archivos y usuarios, facilitando investigaciones, auditorías y el cumplimiento de requisitos regulatorios.

Buenas prácticas para una colaboración segura

Para aprovechar al máximo Microsoft Teams y SharePoint se recomienda:

Definir una estructura clara para equipos y sitios.
Asignar propietarios responsables de cada espacio de trabajo.
Revisar periódicamente los permisos de acceso.
Utilizar etiquetas de confidencialidad según el tipo de información.
Evitar compartir documentos mediante enlaces públicos cuando no sea necesario.
Implementar políticas de retención y respaldo.
Capacitar continuamente a los usuarios en buenas prácticas de seguridad.

El papel del liderazgo femenino en la colaboración digital

Las mujeres profesionales en tecnología desempeñan un papel esencial en la adopción de soluciones que fortalecen la productividad, la seguridad y la innovación.

A través de comunidades como Women in M365, miles de profesionales comparten experiencias, conocimientos y mejores prácticas relacionadas con:

Microsoft 365.
Colaboración digital.
Ciberseguridad.
Gobernanza de datos.
Inteligencia Artificial.
Transformación Digital.

La diversidad de perspectivas contribuye a crear organizaciones más resilientes, innovadoras y preparadas para afrontar los desafíos del entorno digital.

Recomendaciones para pequeñas empresas

✔ Organizar la información por áreas o proyectos.

✔ Definir políticas claras para compartir documentos.

✔ Utilizar autenticación multifactor para proteger las cuentas.

✔ Clasificar la información según su nivel de sensibilidad.

✔ Supervisar periódicamente los permisos y accesos.

✔ Capacitar a los colaboradores en el uso seguro de Microsoft 365.

✔ Aprovechar las capacidades de seguridad y cumplimiento disponibles en Teams, SharePoint y Microsoft Purview.

Conclusión

Microsoft Teams y SharePoint representan mucho más que herramientas de comunicación y almacenamiento. Son una plataforma integral que permite colaborar de forma segura, administrar la información de manera inteligente y fortalecer la productividad en cualquier entorno de trabajo.

Cuando estas soluciones se complementan con una estrategia de gobernanza de datos, políticas de seguridad y capacitación continua, las organizaciones pueden proteger sus activos de información mientras impulsan la innovación y el crecimiento.

La transformación digital es más efectiva cuando combina tecnología, procesos y personas comprometidas con una cultura de colaboración segura.

Próximamente en Women in M365

Microsoft Copilot para Microsoft 365: Inteligencia Artificial para Potenciar la Productividad y la Innovación.

Descubriremos cómo la inteligencia artificial generativa está transformando la forma de trabajar, automatizando tareas, facilitando la creación de contenido y apoyando la toma de decisiones de manera segura y responsable.

Women in M365

Impulsando el liderazgo femenino mediante tecnología, innovación y transformación digital.

B Aurora Rz Valles

Women in M365 Advocate.

MB-820 Certification Essentials: Your Complete Guide to Becoming a Business Central Developer

Dr_Gomathi — Sat, 18 Jul 2026 06:37:58 GMT

Are you looking to advance your career as a Microsoft Dynamics 365 Business Central Developer? Join this awareness session to get a complete understanding of the MB-820: Microsoft Dynamics 365 Business Central Developer Associate certification.

This session will guide you through the certification overview, exam structure, skill areas measured, important development concepts to focus on, enrollment process, recommended learning resources, and effective preparation strategies. Whether you are an aspiring AL developer or an existing Business Central professional planning to validate your skills, this session will help you understand the certification journey and prepare with confidence.

Key Takeaways:
✅ Understand the MB-820 certification and its importance
✅ Learn about exam objectives and key topic areas
✅ Explore the skills required for a Business Central Developer
✅ Discover tips and resources to kickstart your certification journey

Register here: https://events.teams.microsoft.com/event/f17ee130-9061-4a67-8631-9c3ba4bdac96@b4c9f32e-da17-4ded-9c95-ce9da38f25d9

Token Limit Exceeded? What's Actually Going On and What to Do About It ?

Surya_Narayana — Sun, 12 Jul 2026 18:57:22 GMT

Hi All, Based on some recent experience across the organisation with token limit issues, I wanted to put my thoughts down and actually dig into what's happening under the hood, rather than just chalking it up to "we need a bigger plan."

If you work anywhere near the Microsoft ecosystem these days, you're probably touching more AI tools than you realize. Copilot in Word and Excel, GitHub Copilot while you code, Copilot Studio if you're building agents, maybe Security Copilot or Copilot for Sales depending on your role, and increasingly Azure AI Foundry if your team is building anything custom. I work across a good chunk of this stack day to day, and at some point, almost everyone runs into the same wall: "Token limit exceeded." "You've reached your usage limit." "Upgrade to continue."

The first instinct is usually to assume you did something wrong wrote too much, uploaded too big a file, or just need a fatter subscription. Sometimes that's the actual story. But honestly, often, that error message is standing in for three completely different problems that all happen to look identical from the outside. One is about how much text a model can physically process at once. One is about your license or credits running dry. And one has nothing to do with size at all it's just about how fast you're sending requests.

Once you know which of these three, you're dealing with, the fix becomes obvious. Until then, "upgrade your plan" feels like the only lever you've got even when it isn't.

This post walks through what a token is, why Microsoft's various Copilots each handle this differently, and what habits genuinely cut down on these interruptions instead of just throwing money at the problem.

Part 1: So What Is a Token, Really?

A token isn't a word, and it isn't a character it's somewhere in between. It's the small chunk of text a model's tokenizer breaks your input into before it can do anything with it.

Take a word like "unbelievable." A tokenizer might split it into three pieces something like "un," "believ," and "able." Short, everyday words usually come out as a single token. But code, technical jargon, acronyms, and non-English text tend to fragment into a lot more tokens than you'd guess just by looking at the word count.

This is why every AI tool has a ceiling on how much it can handle in one go, and that ceiling isn't measured in words or characters it's measured in tokens. Your prompt, any documents or emails it pulls in as context, the back-and-forth history of your conversation, and the response itself all draw from the same pool. Once that pool runs dry, something has to give: the tool truncates, rejects the request outright, or quietly summarizes older context to make room.

The part that trips people up: token count doesn't map cleanly to word count. A short, dense paragraph full of code or acronyms can eat up more tokens than a much longer plain-English message.

Part 2: Three Different Limits, One Confusing Error Message

This isn't always obvious upfront, even to a lot of admins managing these tools: "token limit exceeded" is really a stand-in phrase for three separate limits, and they don't behave the same way. This isn't unique to Microsoft either every major AI platform bundles these same three things behind similarly vague error messages. Microsoft's stack just makes a good case study because so many of us touch multiple pieces of it in the same week.

The context window is the ceiling on how much text a specific model can process in a single request everything from your prompt to retrieved documents to chat history. This is tied to the model itself, not your subscription. Swap from one model to another inside the same tool, and this ceiling can move without you doing anything differently.

Your license, credits, or feature allowance is a completely separate thing. This is what Microsoft 365 Copilot plans track through AI credits and feature limits, and it's what Copilot Studio measures through Copilot credits at the environment level. A single action summarizing an inbox, generating an agent response, running an analysis deducts from this pool regardless of how small your actual prompt felt. Run out, and you get blocked, even if you're nowhere near any context window limit.

The rate limit is about speed, not size. Copilot Studio, for instance, enforces quotas measured in requests per minute or per hour to keep the system stable under load. Send messages too quickly, which happens easily with automations, flows, or bots, and you can get throttled even with a tiny prompt and plenty of credits left.

The reason this matters: a plan upgrade only ever fixes the second one. If you're actually running into the model's context window or getting rate-limited, paying for a bigger license won't change anything, and that mismatch is exactly where most of the frustration comes from.

Part 3: How This Plays Out Across the Microsoft AI Stack

The Microsoft ecosystem isn't one AI tool wearing different outfits it's genuinely several different systems, each handling tokens and limits in its own way. Here's a tour of the ones people run into most.

Microsoft 365 Copilot (the one living inside Word, Excel, Outlook, Teams) doesn't work off a single published token number the way a developer tool would. Instead, it dynamically pulls together your prompt, recent chat history, and relevant snippets retrieved from Microsoft Graph your files, emails, and messages and quietly summarizes or drops older material to stay within bounds. Where this usually breaks isn't the context window at all; it's the AI credit and feature-limit system running out, often without much warning until you're mid-task.

GitHub Copilot Chat is more like a traditional developer tool. It has a fixed, published token window tied to whichever model you've selected, and that limit applies consistently whether you're in the browser, VS Code, or the CLI. The failure mode here is usually a long conversation or a big multi-file context quietly creeping past that ceiling.

Copilot Studio, where a lot of custom agent-building happens, runs on Copilot credits per interaction, plus its own requests-per-minute and requests-per-hour quotas at the environment level. If you're grounding an agent in SharePoint content, there's also a separate file-size ceiling to watch content over a certain size can get silently excluded from generative answers depending on your tenant's licensing.

Azure AI Foundry (recently renamed to Microsoft Foundry, in case you've seen both names floating around) is where this gets more directly in your control. If your team is building custom applications on top of Azure OpenAI or other models in the Foundry catalog, which now includes everything from GPT to Phi to Claude to Llama, you're working with explicit, published context windows per model, and you're billed per token rather than per credit. It's a different mental model entirely: less "you hit a wall," more "you're paying by the word, so design accordingly."

Security Copilot, if your org uses it for threat analysis and incident response, runs on its own capacity model pooled compute units at the tenant level rather than a simple per-user cap. It's easy to assume this behaves like M365 Copilot license limits; it doesn't.

Copilot for Sales, embedded in Outlook and Teams for CRM-connected work, and Copilot in Power BI, which now goes beyond generating summaries to actually helping build and refine semantic models, both draw from their own feature-specific allowances layered on top of whatever base Microsoft 365 or Power Platform license you're on.

And then there's the multi-model wrinkle that trips up teams the most: because tools like Copilot Studio and GitHub Copilot let you choose between GPT-based models, Claude, and others, the exact same prompt can have a different effective context window and a different token cost purely based on which model handled it that day. This is a big, underrated reason behind the "it worked fine yesterday, why not now" complaint.

Part 4: What Actually Helps ?

Some of this is genuinely outside your control, but a fair amount isn't.

If you're just using these tools day to day, the single biggest habit shift is not letting conversations run forever. Long threads in Copilot Chat or Copilot Studio keep accumulating history, and that history eats into the same budget as whatever you're asking right now. Starting fresh periodically costs you nothing and buys back a lot of headroom.

Large documents are worth splitting up before you feed them in, especially for SharePoint-grounded agents, where oversized files can get quietly excluded rather than cleanly rejected you won't necessarily know it happened unless you're looking for it. And it's worth resisting the urge to default to the heaviest, most capable model for every single task. Lighter models are usually faster, cheaper, and often sit under a more generous limit than the flagship ones, and most everyday tasks genuinely don't need the biggest model available.

Before you go asking IT for a license upgrade, it's worth a quick sanity check on which limit you actually hit. If it's a rate limit, waiting a minute and retrying usually solves it outright. If it's a context window problem, trimming your prompt or starting a new session fixes it. An upgrade only helps if you've genuinely run out of credits or feature allowance, and that's worth confirming before you file the request.

If you're on the building side Copilot Studio agents, Foundry applications, anything with RAG-style grounding a couple of things pay off quickly. Keep an eye on credit or token consumption proactively rather than discovering it's gone when the agent goes down mid-conversation. Be deliberate about what goes into system prompts and orchestration instructions, since those draw from the same budget as the end user's actual message, often invisibly to whoever's chatting with the agent. And spend real time getting chunk size right for knowledge sources too large and you're burning budget on irrelevant context, too small and the agent loses the thread.

Part 5: Quick Checklist Before You Escalate

Is this actually a context window problem -prompt, history, and attachments too big for the model in use?
Have you genuinely run out of credits or feature allowance on your plan?
Could this be a rate limit -too many requests too fast, especially from a flow or automation?
Did the underlying model change since last time, quietly shifting the effective window?
For Studio or Foundry work, is this a tenant or environment-level limit rather than something tied to you personally?

Closing Thoughts

Tokenization is one of those things that stays completely invisible right up until it isn't. Across a stack as sprawling as Microsoft's M365 Copilot, GitHub Copilot, Copilot Studio, Foundry, Security Copilot, and everything layered on top "token limit exceeded" almost never means one single thing. It means you've hit one of three very different walls, and each one needs a different response.

If your team builds or maintains any of these tools, this is genuinely worth putting in front of people early. Most of the "why did this break" tickets in this space aren't about tokens at all. They're about nobody knowing which limit actually got hit, or where in this increasingly large ecosystem it happened.

I'm curious how this shows up for others has your team standardized on one model across these tools, or are you juggling several depending on the task? I'd love to hear what patterns you've run into.

Cheers, and happy reading.

- By Surya Vennapusa, MCT

How to prepare for the DP-6OO certification ? Looking for study tips and Resources.

BRNayak — Thu, 09 Jul 2026 12:25:57 GMT

Title: How to Prepare for the DP-600 Certification? Looking for Study Tips and Resources

Hello everyone,

I am currently preparing for the DP-600: Microsoft Certified – Fabric Analytics Engineer Associate certification.

I would appreciate your advice on:

- The best learning resources and documentation.

- Hands-on labs or practice projects to build real-world skills.

- Recommended practice tests or mock exams.

- Common challenges faced during the exam.

- Tips from those who have already passed the DP-600 certification.

Any study plan, preparation strategy, or personal experience would be greatly appreciated.

Thank you in advance for your support!

Where is the video recording?

Repocr — Sat, 04 Jul 2026 19:54:02 GMT

I don't see the recording

suppots

godvani — Sat, 04 Jul 2026 08:36:28 GMT

now i am begginer

how to start

Strengthen cyber resilience across the Microsoft Cloud (Entra/M365/Azure).

lukemurraynz — Mon, 06 Jul 2026 19:45:15 GMT

Entra ID and Microsoft 365 form the backbone of many business operations, seamlessly integrating to drive efficiency and innovation. However, this interconnected power also expands the attack surface, increasing the potential risk of data loss and security breaches. Protecting your critical data across these platforms is no longer optional—it’s essential to ensuring business continuity and swift recovery from cyber incidents. In this session, we’ll uncover the key vulnerabilities and provide actionable strategies to strengthen your data security posture against evolving threats.

Speaker:

Vanessa Toves

Unable to Access Lab environment During My DP-300 Examination

Chumasande_Mooi — Sat, 27 Jun 2026 09:00:47 GMT

Hi everyone,

I want to find out who is responsible for this issue—Microsoft or Pearson VUE (the testing center).

During my DP-300 exam, I couldn't access the lab environment. I kept receiving an authentication error when trying to sign in using the Console Authenticator. I carefully followed the instructions and scanned the QR code displayed on the screen, but it didn't work.

I then tried the second authentication option by entering the code manually, but I still received the same error.

I've submitted a complaint, but both Microsoft and Pearson VUE are shifting the blame to each other. I studied really hard for this exam, and to make matters worse, this is the second time I've experienced the exact same issue.

The first time it happened, Microsoft acknowledged the issue and provided me with an exam voucher. I'm now trying to understand who is actually liable for this recurring problem and what my next steps should be.

Has anyone else experienced something similar or have any advice?

June 2026 Meeting Recap - Intune, AI‑Powered Power Apps, and Career Pathways in Tech

NikkiaTCarter1 — Fri, 26 Jun 2026 20:55:46 GMT

🚀Hey Ananse Tech enthusiasts - Here are the Promised Resources from Last Night's Ananse Tech Community Meeting Jun 25,2026 -Intune, AI‑Powered Power Apps, and Career Pathways in Tech! 🌐✨

📆 Last Night Event Recap: Missed our last event? No worries! We've got you covered. Dive into the recording, check out the deck, and take a moment to share your thoughts! 🎙📊

📹 Recording: https://youtu.be/86M1l8zIsR0?si=sE5Fv7V83EAWl7cB

Looking for our past events? Check out our YouTube channel -> https://www.youtube.com/@AnanseTechCommunity!

📑 Deck: AnanseSlides - MayJune2026.pptx

⏰ Post Event Form: And for those who attended and hadn't had a chance to fill out the post event survey, please do. https://lnkd.in/gw2P2yce

✨✨Join us next month, Jul 23,2026 at 6 pm, for our next great event AI-Powered Work: Smarter Meetings, Smarter Content, Smarter Business! See the details here:LinkedIn Login, Sign in | LinkedIn

For all of our upcoming events, please see our events page: S’identifier sur LinkedIn | LinkedIn

🗣🎙BTW, if you are interested in speaking during one of our community events, please fill out this form: Please fill out this form If you are interested in volunteering or sponsoring, reach out to us at email address removed for privacy reasons.

Your insights fuel our community's growth, so don't hesitate to contribute! Let's keep the tech vibes strong! 🚀🌐

AI-Powered Work: Smarter Meetings, Smarter Content, Smarter Business

NikkiaTCarter1 — Thu, 25 Jun 2026 13:46:01 GMT

Join us for our July 2026 meeting: AI-Powered Work: Smarter Meetings, Smarter Content, Smarter Business!

Doors open 5:30 pm GMT (1:30 pm Eastern US / 10:30 am Pacific US)

We start promptly at 6-8 pm GMT (2-4 PM Eastern US / 11am-1 pm Pacific US)

Our Tech Speakers and Topics

Speaker: Onyinye Madubuko, Senior M365 Consultant at Ergo

Session Title:
Teaching Copilot to Speak Your Language: The Future of Smarter Meetings
Session Description:
The use of Copilot to boost workplace productivity continues to grow. Most Microsoft apps and services now have an AI assistant embedded to support users with more on the way. Among Microsoft’s collaboration tools, Microsoft Teams, the hub for teamwork, is steadily evolving with AI-powered features and agents designed to make chats and meetings more seamless.

These AI capabilities enhance the meeting experience both during and after the session. Participants can focus and engage more attentively while Copilot takes notes automatically. While many appreciate the convenience of AI-generated meeting summaries, a common challenge continues to persists. It has been observed that the AI notes often contain misspellings or awkward phrasing, especially when unique organizational acronyms are involved.

In this session, I’ll cover:

- The process structure of capturing team-specific organizational acronyms

- Requirements and steps for implementing a custom dictionary in Copilot for Teams meeting

- Real-world use cases demonstrating the custom dictionary in action

By the end of this session, organization administrators will be better equipped to help team members and stakeholders to fully benefit from AI-generated notes during and after Microsoft Teams meetings

Speaker: Marco Rocca, Cloud Solutions Architect at Tecnimont Services

Session Title:
Discover SharePoint AI Skills
Session Description:
With the introduction of AI Skills in SharePoint, organizations are redefining how organizations transform content into actionable knowledge.
This session explores how SharePoint evolves from a traditional document repository into an AI-powered knowledge platform, enabling teams to "teach" AI how their business works.
We will examine how AI Skills allow users to capture repeatable, multi-step workflows in natural language and convert them into reusable assets that standardize operations across sites.
These skills, stored as lightweight Markdown-based definitions, enable consistent execution of business processes such as document review, content generation, metadata extraction, and reporting—without writing code

Our Career Speaker and Topic

Speaker: Harry Carter, Co-Founder of the Ananse Tech Community, Co-CEO for Sesa Technology Ltd., Co-CEO for NTC Tech Consultancy, LLC

Session Title:
Create Professional Documents with Copilot: Smarter Work for Ghanaian Businesses
Session Description:
Creating polished, professional documents doesn’t have to take hours. In this session, we’ll explore how to use Microsoft Copilot to quickly draft, refine, and improve business documents for real-world use in Ghana.

You’ll learn how to use AI to create emails, proposals, reports, and presentations with clarity and confidence—while saving time and maintaining quality.

This session is perfect for professionals, entrepreneurs, and anyone looking to work smarter and present their ideas more effectively.

Azure Cloud Commanders is moving!

lukemurraynz — Wed, 24 Jun 2026 19:31:33 GMT

The Azure Cloud Commanders group is moving!

This is moving from the Microsoft Community Hub, into Azure! So we can continue the conversation and sessions over there! I will let you know what this means when I have a clearer picture, but sessions are proceeding as is!

new to this group booked exam on Aug. 15

Minty — Wed, 24 Jun 2026 02:24:52 GMT

any suggestions on how to be ready within 7 weeks😃 i have pl 300

Women in M365 Artículo 3 Junio 2026. Microsoft Purview.

Lider_RegionalMGCI — Tue, 23 Jun 2026 23:11:38 GMT

Protegiendo la Información y Fortaleciendo el Cumplimiento Digital. Liderazgo Femenino y Protección Digital en la Era de la IA.

Por B. Aurora Rz Valles.

Microsoft Community.

Lead Regional MGCI.

Advisor.

La transformación digital ha permitido que pequeñas empresas, organizaciones comunitarias y emprendimientos liderados por mujeres accedan a nuevas oportunidades de crecimiento. Sin embargo, el aumento del volumen de datos y el uso de herramientas basadas en inteligencia artificial también han generado nuevos desafíos relacionados con la protección de la información.

Documentos financieros, datos de clientes, expedientes administrativos, contratos y comunicaciones internas representan activos valiosos que requieren mecanismos de seguridad adecuados.

En este contexto, Microsoft Purview se ha convertido en una de las soluciones más importantes dentro del ecosistema Microsoft 365 para ayudar a las organizaciones a proteger, clasificar y gobernar su información.

¿Qué es Microsoft Purview?

Microsoft Purview es una plataforma integral de gobierno de datos, cumplimiento normativo y protección de información que permite a las organizaciones conocer dónde se encuentran sus datos, quién tiene acceso a ellos y cómo se utilizan.

Su objetivo principal es ayudar a proteger información sensible, reducir riesgos y cumplir con requisitos regulatorios y normativos.

¿Por Qué Es Importante para los Pequeños Negocios?

Muchas pequeñas empresas almacenan información crítica en correos electrónicos, documentos compartidos, hojas de cálculo y plataformas en la nube.

Sin una estrategia adecuada de protección de datos, pueden enfrentar riesgos como:

Exposición accidental de información confidencial.

Compartición indebida de documentos.

Pérdida de datos sensibles.

Incumplimiento de regulaciones de privacidad.

Riesgos asociados al trabajo remoto e híbrido.

Uso inadecuado de información empresarial.

Microsoft Purview ayuda a reducir estos riesgos mediante herramientas automatizadas de protección y supervisión.

Principales Capacidades de Microsoft Purview

1. Clasificación Automática de Datos

Permite identificar información sensible como:

Números de identificación.

Información financiera.

Datos personales.

Registros médicos.

Información confidencial de clientes.

Una vez detectados, los datos pueden etiquetarse automáticamente para aplicar medidas de protección.

2. Etiquetas de Sensibilidad

Las etiquetas de sensibilidad ayudan a clasificar documentos y correos electrónicos según su nivel de confidencialidad.

Ejemplos:

Público

Uso Interno

Confidencial

Altamente Confidencial

Esto facilita que los usuarios comprendan cómo deben manejar la información.

3. Prevención de Pérdida de Datos (DLP)

La funcionalidad de Data Loss Prevention (DLP) ayuda a evitar que información sensible sea compartida de forma accidental.

Por ejemplo:

Detecta números de cuentas bancarias.

Identifica datos personales.

Bloquea envíos no autorizados.

Genera alertas para administradores.

4. Gobierno y Retención de Información

Permite definir cuánto tiempo deben conservarse determinados documentos y cuándo pueden eliminarse de manera segura.

Beneficios:

Organización documental.

Cumplimiento normativo.

Reducción de almacenamiento innecesario.

Mejor gestión de registros empresariales.

5. Cumplimiento y Auditoría

Microsoft Purview facilita:

Registro de actividades.

Auditorías internas.

Investigaciones de incidentes.

Monitoreo de accesos.

Seguimiento del uso de información sensible.

Cómo Comenzar con Microsoft Purview

Paso 1. Acceder al Portal

Inicia sesión en Microsoft 365.

Accede al Centro de Cumplimiento.

Selecciona Microsoft Purview.

Paso 2. Revisar el Panel de Cumplimiento

Explora las secciones:

Protección de Información.

Prevención de Pérdida de Datos.

Administración de Registros.

Auditoría.

Riesgos Internos.

Paso 3. Crear Etiquetas de Sensibilidad

Define categorías para la información de tu organización:

Público.

Interno.

Confidencial.

Restringido.

Paso 4. Configurar Políticas DLP

Establece reglas para proteger:

Datos financieros.

Información de clientes.

Documentos estratégicos.

Información legal.

Paso 5. Capacitar a los Usuarios

La tecnología es más efectiva cuando las personas comprenden cómo utilizarla correctamente.

El Papel de las Mujeres en la Gobernanza Digital

Las mujeres profesionales en tecnología desempeñan un papel fundamental en la construcción de organizaciones más seguras y resilientes.

A través de comunidades como Women in M365, miles de mujeres comparten conocimientos sobre:

Ciberseguridad.

Cumplimiento normativo.

Gestión de datos.

Inteligencia Artificial Responsable.

Transformación Digital.

La diversidad en los equipos tecnológicos fortalece la innovación y mejora la toma de decisiones relacionadas con la protección de la información.

Recomendaciones para Pequeñas Empresas

✔ Clasificar la información empresarial.

✔ Aplicar controles de acceso.

✔ Implementar políticas de retención.

✔ Supervisar el intercambio de datos.

✔ Capacitar continuamente a los colaboradores.

✔ Utilizar herramientas de cumplimiento disponibles en Microsoft 365.

✔ Establecer una cultura organizacional basada en la protección de datos.

Conclusión

La protección de la información ya no es una tarea exclusiva de los departamentos de tecnología. En la actualidad, forma parte de la estrategia de crecimiento, confianza y sostenibilidad de cualquier organización.

Microsoft Purview permite a emprendedoras, pequeñas empresas y organizaciones fortalecer la gobernanza de sus datos, proteger información sensible y cumplir con los desafíos de un entorno digital cada vez más complejo.

Cuando combinamos tecnología, educación y liderazgo femenino, construimos ecosistemas digitales más seguros, inclusivos y preparados para el futuro.

Próximamente en Women in M365

Microsoft Teams y SharePoint: Colaboración Segura y Gestión Inteligente de la Información

Descubriremos cómo estas herramientas permiten a las organizaciones mejorar la comunicación, proteger documentos y fortalecer la productividad en entornos híbridos y remotos.

Women in M365

Impulsando el liderazgo femenino mediante tecnología, innovación y transformación digital.

B. Aurora Rz Valles

Women in M365 Advocate.

PL-300 study guidance in Data Days 2026

Feudson — Tue, 23 Jun 2026 06:08:40 GMT

Hello everyone ,

i am currently enrolled in the Data Days 2026 program and actively following the PL-300 study sessions.

i would like to improve my pawer BI skills and follow the most effective learning path for the certification.

could someone guide me on which sessions or study group i should focus at this stage?

Thank you in Advance for your help.

Copilot Employee Self-Service Agent

MichalZiemba — Thu, 18 Jun 2026 10:39:49 GMT

I see that Microsoft has put a lot of efforts to marketing the Copilot Employee Self-Service Agent but it seems it is not available for every tenant.

I have already checked on several small and mid ones (5-2k users) and cannot install it.
As I understand from what I already red and saw, this is a template that should be available to you when you start building agents. Unfortunately when I enter Copilot Studio and enter in the search ESS (abbrevation from Employee Self-Service) I got only those two marked red filtered.
When I installed IT Helpdesk, I do not see topics related to HRSD in ServiceNow which I need.
I found the Employee-Self-Service-Agent-Developer-Kit that contains same examples of the ServiceNow HRSD topics, but when I copy the code of those to my agent I got some references to topics that I do not have.

Anyone has struggled with the same? Or maybe you have access to the ESS agent and can share the topics with me?

Michal

Learn Expert program ending in June

KonstantinosPassadis — Wed, 17 Jun 2026 19:43:41 GMT

Hi everyone,

I wanted to share an important update with you directly.

As some of you may have already heard, the Learn Expert program is being retired, and all Learning Rooms — including ours — will close at the end of June. This wasn’t a decision any of us expected, and I know it affects many of you who have been learning, sharing, and growing together here.

Our room, Modern Development with Azure Integration and AI, has become a small but meaningful

space for practical learning, real conversations, and hands‑on guidance. I would love to keep this community alive if possible.

There is a path to continue: Learning Rooms can be transferred into an existing Microsoft Tech Community group — but only if a community owner approves the move.

If any of you are connected with a Tech Community owner or moderator who might be open to hosting our room, please let me know. Even a simple introduction could help us keep this space going.

If a transfer isn’t possible, the room will officially close at the end of June. Until then, I’ll keep sharing updates and next steps so you know where to find me and how to stay connected.

Thank you for being part of this journey — your curiosity, questions, and contributions have made this room worth every moment.

Konstantinos