Beyond Benchmarks: The Lifecycle of Measuring Agentic Quality in AI Content Management
By Sujay Kumar Jauhar, Spriha Chandrayan, Natasha Gaitonde, Zhen Lei, Reed Pankhurst, Anush Sankaran, Amrit Shandilya, Ryen W. White Organizations put their most important content in OneDrive and SharePoint, trusting us to deliver AI experiences they can depend on. That trust runs across everything Copilot does with their content — surfacing the right information through retrieval, and, increasingly, driving agentic workflows that reason over documents and take action on their behalf. Living up to that trust is what we care about most, and it's why we put the quality of these experiences — and consequently the ways we measure that quality — at the center of how we build. It turns out that this is a non-trivial problem, because quality in AI is rarely binary. An agent can call exactly the right tools and still produce an answer that's subtly, confidently wrong. A search result can be technically relevant and still miss what the user was really after. An AI-generated page can be well-structured and fluent and still omit the one detail that mattered. Quality here is continuous, context-dependent, and multidimensional — and when these experiences are serving hundreds of millions of enterprise users, measuring it demands scientific rigor across the full lifecycle of building AI products. Across OneDrive and SharePoint — the knowledge platform for Copilot and Agents — we’ve spent the past year building a rigorous practice around evaluation: determining what to measure, developing the right methods to measure it, and learning how to act on those measurements to improve our systems and experiences. In software engineering, tests verify correctness and telemetry monitors health. The boundaries are well-defined: a function returns the right value or it doesn’t; a service meets its service level objective or it doesn’t. AI evaluation requires an analogous discipline, but the problem is structurally harder — there is rarely a single correct answer, and quality depends on factors that shift with every user, task, and context. This post describes the evaluation practice we are building across Copilot capabilities in OneDrive and SharePoint. It follows the arc of what we think of as the evaluation lifecycle — from rapid inner-loop validation, through rigorous offline measurement, to customer-grounded evaluation that evolves with real feedback, and ultimately to understanding whether our metrics predict what users actually experience. Each stage addresses a question the previous ones cannot, but they don’t run in a straight line. What we learn downstream can reshape the data and methodology of upstream measurements. That’s what makes this a lifecycle — and together they form a strategy for building AI systems that aim to earn user trust at enterprise scale. We're on a journey — learning and evolving as we build this practice. Some of the things we're actively working on, omitted from this blog post for the sake of brevity, are: holding ourselves to public, industry-standard benchmarks such as GAIA and GDPval, with more in the pipeline; and investing in the foundations that keep evaluation trustworthy, by generating realistic synthetic evaluation data so our test sets keep pace with new models, and monitoring the health of our benchmarks for saturation. The inner loop: "Did I break anything?" The first requirement of any AI development workflow is a fast feedback signal. Teams are experimenting constantly on internal builds — adjusting prompts, swapping model versions, rearchitecting retrieval pipelines — and they need to know within minutes whether a change helped or hurt. That is the role of our unit-level evaluations: a rapid inner loop for feature crews. A developer modifies a system prompt or adjusts the grounding context, runs it against a targeted set of test cases, and gets immediate feedback on whether key behaviors are preserved. These checks are fast, focused, and designed to catch regressions before they compound. The distinction from traditional unit testing is worth noting. In software, a test asserts an exact expected output. In AI, you are validating behavioral properties — coherence, completeness, tool selection, factual consistency — against approximate expectations. The pass/fail boundary is softer, but the engineering purpose is the same: give teams confidence to iterate without fear of silent degradation. One of the crews building Copilot's agentic features over SharePoint Lists knows this loop well. They keep a large set of prompts that engineers run whenever they change something — a tweak to a tool's description, a different setting passed to the model, a reworded prompt. Many of those questions run over the same synthetic data: lists of bakery orders, each row carrying details like the baker, the delivery agent, the profit on the order, and its status. The same lists come in a range of sizes, from a few thousand rows up to a million. The largest are used to push the system's limits but the inner loop lives at the lower end. There, most questions are ones the system has gotten right for a long time, so when a change quietly breaks one of them, it shows up right away. An engineer can try an idea, run the set quickly, and whether they've introduced a regression. Fast iteration checks are essential, but they only tell you whether something regressed. They cannot tell you how good the system actually is. Offline evaluation: "How good is this, really?" This is the domain of our offline evaluation practice. We maintain curated, scenario-focused benchmarks evaluated in a controlled harness that reflect the tasks and content types our enterprise users encounter, alongside public benchmarks that situate our systems in the broader AI landscape. The goal is to bring each AI scenario to a state of decision-readiness: explicit success criteria, representative evaluation datasets, metrics we attempt to validate against real outcomes, and systematic coverage of known failure modes. We try to do this rigorously by running evals against the real product. Each test case is a plan — a short script of things a user might ask for — paired with criteria (or assertions) describing what a good outcome looks like, sorted by how much each one matters: Critical, Expected, or Aspirational. An LLM plays the user: it drives the live product through the browser, sends the opening request, and then reacts the way a person would, confirming an action card here or answering a clarifying question there, so the system is exercised end to end. When the conversation finishes, the harness gathers the evidence of what actually happened — the responses in the chat, the state of the page, and screenshots where the judgment is visual. That evidence goes to a second model acting as judge — the increasingly standard "LLM-as-a-judge" approach — which scores the run against the original assertions. And because a model grading a model is only as trustworthy as its agreement with people, those scores are calibrated against human raters. Using a high-priority, curated slice of these evals, the team ran big proposed changes side by side to see which ones came out ahead. One of those comparisons looked at how the orchestrator is told about the tools it can use. At one extreme, you hand the model the full description of every tool up front; at the other, you give it only short, tweet-length summaries and let it pull a tool's full description and parameters only when it decides it needs them. Configuration Quality % Latency vs. default Cost vs. default Baseline 83.0 1.00x 1.00x Default tool discovery 90.3 1.11x 0.62x Rearchitected tool discovery 85.6 0.97x 0.73x Semantic tool search 92.8 0.95x 0.74x Hybrid 93.5 0.82x 0.62x Table 1: A comparison of the different approaches for tool selection we experimented with. Based on internal evaluation results using our internal test environment, and test configurations of the product. Quality was measured through LLM judgement of AI responses based on a set of criteria, latency was measured by the harness running the evaluations, and cost is based on publicly disclosed price heuristics for token usage for the LLM API being used for orchestration. Results were calculated from 500 scenario tests based on synthetic data. The table above summarizes our results from an internal offline evaluation on a curated slice. In this evaluation, we found that the baseline which loads everything up front was, predictably, the most expensive. The out-of-the-box tool-discovery method cut token usage sharply — but was a bit slower. Pushing further, a rearchitecting of the orchestrator for tool discovery did speed things up, but at the cost of quality. Meanwhile semantic tool search improved on both quality and latency relative to the baseline but wasn’t as cost-efficient as the default tool discovery method. Overall, in this evaluation, a strong balance of quality, token usage, and latency came from a hybrid — the standard tool-learning architecture with a few targeted semantic-search changes, which still resulted in a more than 35% reduction in token usage when compared with full tool descriptions. Offline benchmarks, however carefully constructed, have an inherent limitation. They represent a fixed snapshot — based often on what product teams believe will be important use cases, particularly for features that have not yet shipped to real customers. As the product evolves and real usage patterns emerge, the gap between what our benchmarks measure and what actually matters can widen. The evals flywheel: "Are we measuring what users care about?" This is the motivation behind what we call the Evals Flywheel: a closed-loop system that translates real user dissatisfaction directly into better evaluations and, ultimately, better systems. In software engineering, there is a well-established discipline of turning production bugs into tests. In the AI analog, user feedback provided with appropriate consent helps produce new evaluation data, systematic failure diagnoses, and targeted improvements. Take for instance a user that consents to share feedback with us (via a thumbs down). At first glance, this seems like a single interaction. But to us, it's an opportunity to learn. We investigate what happened, identify the underlying reason for the user dissatisfaction, and ask a critical question: was this an isolated mistake, or does it reveal a broader weakness in how the system understands documents like this one? Here's a representative example. A user uploaded a 120-page quarterly financial report packed with dense tables, nested headers, footnotes, and appendices. They asked a straightforward question: "What was our actual spending in Q3?" The answer seemed like it should be easy — the relevant numbers were all in the document. The assistant responded confidently with a figure from one of the summary tables; but it cited the budgeted amount, not the actual spend. The mistake stemmed from the document's complexity. The table spanned multiple pages, with a top-level "Q3" header extending across several sub-columns such as Budget, Actual, Forecast, and Variance. On its own, that's one mistake in one document. However, it pointed at something more general: whenever a table uses a heading that spans multiple columns, or stacks two rows of headers, or tucks a small table inside a larger one, then the link between a header label and its value turns fragile. Understanding the text is often not enough — the assistant must also accurately preserve and reason over intricate document structure, table relationships, and context that can span dozens of pages. Hence, instead of patching that single file, we built a family of evaluation documents that deliberately stress that exact structure. Each eval document pairs a question with the single correct answer and a short list of "tempting but wrong" answers which are the nearby values a confused reader would most likely grab. That last part is the key: an eval that only checks for the right answer can be passed by luck, but an eval that includes likely distractors tells you whether the system is genuinely reasoning or just guessing. This example reflects a repeatable method. The first step is resisting the urge to treat a user dissatisfaction as an isolated bug. Instead, we ask why it happened and not "what's the right answer for this question." That root-cause identification is what turns the user feedback into a useful signal. The payoff is a flywheel between real-world experience and offline evaluation. The improvement ships back into the product, where future interactions validate it — and surface the next gap. Each loop widens our coverage and, just as importantly, helps us prioritize the improvements that matter most to the people using the product. But it raises a deeper question: when our benchmarks are representative of user concerns, do improvements actually translate into better experiences in production? Real-world insights: "Does this actually matter to users?" It is possible to improve a benchmark score and have it mean nothing in practice. A model that scores five points higher on an offline evaluation may produce no detectable difference in user satisfaction or task success. Conversely, a change that barely moves the needle offline might transform the user experience in unexpected ways. This gap between offline measurement and real-world impact is the focus of our online evaluation work. Through production telemetry, we study user-AI interaction patterns at scale. The objective is not simply to monitor system health, but to develop an empirical understanding of how users experience our AI features in context. In traditional software, production telemetry provides crisp, well-defined signals: uptime, latency percentiles, error rates. In AI, the equivalent signals — satisfaction, intent alignment, task success — are inherently noisier and harder to define. The central challenge here is alignment: do our offline metrics predict real user value? Answering that depends first on being able to measure value reliably in production at all. Consider a recent experiment on one of our top-of-funnel entry points — the most common way users first reach the assistant. The team suspected that engagement was low (around 1%) simply because users weren't noticing the entry point. So they ran a user-level A/B test across a sample of 900,000 Copilot-licensed users over 21 days, swapping the entry point's icon for a more contextually relevant one. The effect was a statistically significant 42% lift in click-through, alongside a 1.7% increase in active users. That result is encouraging, but it also illustrates a subtle nuance. We moved an engagement metric sharply without touching quality at all — this tells us that we had an education gap, but didn’t inform our understanding of the AI system’s performance. To get closer to that distinction, we looked at kept rate: the share of AI responses where the user does something that signals the answer was worth keeping — copying the result, clicking through to a citation or a suggested follow-up, or providing a thumbs up. And because it's captured passively, from actions users take anyway, it scales to every response rather than the small fraction where someone leaves explicit feedback. Even an indirect, partial signal like kept rate lets us close the offline-online loop. Once we have a read on what users valued, we can start to ask how well it correlates with our offline benchmarks. When offline gains track with a rise in kept rate, for example, it's early evidence the benchmark is steering us toward something real; when they are uncorrelated, it's a warning that we may be hill-climbing in a wrong direction. Beyond quality Quality matters — but in production systems, it is entangled with cost and latency in ways that cannot be evaluated in isolation. A high-quality response that is unacceptably slow degrades the user experience regardless of its correctness. Or a frontier model that is marginally better than a smaller alternative may not justify the cost differential. This is the next frontier of our evaluation work: learning to reason about quality, cost, and latency as a tradeoff surface rather than independent dimensions. The goal is to build the instrumentation and frameworks that make these tradeoffs visible and deliberate, so that teams can make principled decisions about how they ship. To make this concrete, consider some early findings from our internal evaluations. We took a range of system configurations — models, reasoning levels, tool access — and, for a set of representative tasks — QA over lists, the AppWorld public benchmark, and a collection of complex multi-step plans that stress-test the Copilot in SharePoint agent — plotted each one by the quality it achieved against what it cost to run. The result is a Pareto frontier: the curve of the best quality reachable at each price, with everything below it dominated by something strictly better. Two things stand out. First, different tasks live in different performance regions. Simple, factual lookups like those in ListsQA cost fractions of a cent; harder, more agentic tasks like those in AppWorld and Copilot in SharePoint run to cents or dollars; there is no single answer to what "good" costs. Second, the shape of each curve tells you where spending more is actually worth it. Where the frontier rises sharply, additional cost buys real quality; where it flattens, you have hit diminishing returns, paying more for gains a user may not notice. In short, the decision stops being "is the quality good enough to ship?" and becomes "which point on this curve is right for this scenario?" given budget and latency constraints — a question a feature crew can answer, with the tradeoffs in front of them. What we've learned so far We are still early in this work. Models are improving rapidly, user expectations are evolving, and the definition of quality continues to shift. But several principles have become clear to us. No single evaluation approach is sufficient. Inner-loop checks catch regressions but cannot establish absolute quality. Offline benchmarks provide rigor but go stale. Customer feedback grounds evaluation in real needs but covers only the cases where dissatisfaction is expressed. Online metrics reveal real behavioral patterns but cannot always explain the mechanisms behind them. A credible evaluation practice requires all of these, operating in concert and informing each other. Evaluation is not a gate you pass before shipping — it is a continuous discipline that evolves with the product. The teams that build the best AI experiences are not necessarily those with the highest benchmark scores, but those with the clearest understanding of where their systems fall short and the most systematic approach to closing those gaps. And measuring what matters is itself a scientific problem, one that demands the same rigor we apply to the systems being measured. Developing evaluation methods that are reliable, predictive of real user value, and robust to the rapid evolution of AI capabilities is core to our mission across OneDrive and SharePoint. It is how we work to earn the trust of the enterprise users who depend on these experiences, and we are committed to advancing this work and sharing what we learn.
Outlook Classic - Crashes When Drafting with Copilot in RDS environment
Hi all, I'm interested to see whether anyone else is experiencing this issue, particularly in an RDS environment. We have a number of users who have paid-for Microsoft 365 Copilot licences, including the integration within Office applications such as Outlook, Word and Excel. In Outlook Classic running on our Windows Server 2019 RDS environment, Copilot no longer works correctly. When a user presses Alt + I to Draft with Copilot, or clicks the Copilot pencil icon within the body of an email, and then enters a prompt, Copilot displays "Writing your email" and the blue progress bar starts moving from left to right. At that point it freezes, Outlook crashes, and closes. In some cases Outlook will automatically reopen after the crash. The Copilot integration appears to work fine in Excel and Word. Is anyone else running Outlook Classic in a Windows Server 2019 RDS environment with Microsoft 365 Copilot licences? I would be interested to know if you have experienced the same issue. I've tried repairing and reinstalling Office apps, and always ensure they are fully up to date. Thanks.Hands-on webinar: Set up your classroom in Teams for Education plus the new Study and Learn Agent
Join us on Wednesday, August 5th at 8:00 AM Pacific Time for a practical, 60-minute webinar to get your Microsoft Teams classroom ready for the new school year in the Northern hemisphere. Get your class set up in Assignments and Classwork, learn about new tools like Learning Activities, use Student AI Guidelines to set the right expectations for your students, and see how the Study and Learn Agent can be a study partner for your students. Follow along with your own Microsoft 365 Education account as we walk through each one. Register here: https://aka.ms/August5Training The session will be recorded and posted to the Microsoft Education YouTube channel so you can watch it later or share it with colleagues. Agenda - Get your Teams EDU classroom ready and learn about the Study and Learn Agent. ✅ Teams EDU Classwork / Assignments setup ✅ Learning Activities in Assignments and Classwork ✅ Student AI Guidelines in Teams Assignments ✅ Copilot Study and Learn Agent We look forward to seeing you on August 5th! Also, be sure to check out and sign up for our Microsoft Elevate Educator community. Mike Tholfsen Group Product Manager Microsoft EducationSizing Copilot Credits for Cowork? Let Your Users Use Cowork Investment Advisor Agent.
Right, let's talk about a headache. If you're helping a customer allocate Copilot Credits for M365 Copilot Cowork, you have to size it all up first — and doing that by hand is a fiddly, time-consuming job. Here's the problem, and a much easier way to solve it. Start with the Cowork Estimator Here's the good news: you don't have to start from scratch. Microsoft has published the Customer Cowork Estimator — a handy tool that turns personas, prompt complexity and expected usage into an estimated credit number. It's the perfect place to begin, and it does the core maths for you. To get the most out of it, you just need to feed it good inputs — and that's where a little groundwork comes in. For each part of the business, you'll want to: Work out who's who. There are four types of user — corporate knowledge workers, management and senior leaders, customer-facing folks, and technical staff. Count how many of each. Quick for a small team, a bit more involved for a big one. Pin down what they'd genuinely use Cowork for. The real multi-step workflows that hop across apps and actually do things — not just a quick chat or a summary. Judge how heavy each workflow is. Light, Medium or Heavy — since each level uses a different number of credits per run. Estimate how often it runs. Daily adds up to a lot of runs a month; weekly is far fewer. The estimator handles the sums beautifully once those inputs are in. Gathering the inputs themselves — persona by persona, workflow by workflow, across a few thousand people — is simply the part that takes time. And that's exactly where this agent lends a hand: it builds on the estimator by automating the groundwork that feeds it. How this agent helps This agent takes on that groundwork for you. Instead of sizing everyone from the outside, the admin simply switches the agent on for every user. Each person then sizes their own needs — and the agent does the clever bits for them, ready to drop into the estimator. Here's what it does behind the scenes: Spots the right persona. It works out which of the four personas each user fits. Finds the real workflows. It looks at the top Cowork scenarios the user would actually run. Keeps it honest. It checks each one is a genuine Cowork job — several steps, more than one app, real actions and a bit of decision-making — not something a Scheduled Prompt or plain Copilot Chat could do just as well. Grounds it in evidence. It reads the signals from recent work — emails, meetings, documents and Teams chats — so the estimate is based on what people actually do, not thin air. Does the sums. It maps each workflow's complexity to credits per run and totals it up — giving you numbers that line up neatly with the estimator. Shows the value. It gives a view of pay-as-you-go versus a pre-purchase plan, and a sense of the return on the spend. Stays transparent. It states its assumptions, flags how confident it is, and sticks to permitted data and the usual privacy and compliance rules. And here's the kind of report it hands back — persona, the top workflows, complexity, credits, cost and a clear recommendation, all in one place: Why this approach works better So why hand it to the users? A few good reasons: More accurate. The numbers come from each person's real workload, not a top-down guess. Consistent by design. Everyone follows the same method — same personas, same complexity bands, same maths — so the results line up and roll into one clean figure. No over-buying. Because it weeds out the workflows that don't really need Cowork, your customer only pays for credits they'll genuinely use. A proper business case. You get cost clarity and a feel for the return, so you're handing over more than just a number. It scales. Ten users or ten thousand — the effort on your side stays much the same. It saves you hours. You swap manual sizing for gathering and rolling up. Your time goes on advising, not tallying. Not ready to roll it out? Other ways in If an admin isn't quite ready to switch the agent on for everyone, that's OK— there's no need to. This agent is an M365 Copilot agent, and it has free access to Work IQ — the same engine that will eventually power Cowork. Because that access is free, the agent can read how people really work and take the guesswork right out of sizing. And there's more than one way to get at it: Build it with Agent Builder. Ready-made instructions, a description and a starter prompt are all sitting in the GitHub repo. Anyone with access to M365 Copilot can pop them into Agent Builder and stand the agent up in minutes. Prefer not to build an agent? Just use the prompt. There's a comprehensive prompt you can drop straight into the M365 Copilot Chat experience. Same sizing, same evidence — no agent to create. Ready to give it a go? Whichever route suits you best, getting started is dead simple. If you're rolling the agent out to your users: Have a quick word with your customer's admin about switching the agent on for their users. Let each person size their own Cowork needs. Gather it all up and roll it into a single estimate. Prefer to keep it in your own hands? Build the agent from the GitHub repo with Agent Builder, or drop the comprehensive prompt into M365 Copilot Chat — you'll get to the same place with even less setup. THE BOTTOM LINE That's the heavy lifting done for you. You'll save yourself hours, spare yourself the guesswork, and hand your customer a credit plan they can genuinely trust — with the numbers and the business case sitting right behind it. Give it a spin on your next engagement and see how much quicker it gets you there. Resources Everything you need is in one place: Customer Cowork Estimator — https://aka.ms/CustomerCoworkEstimator GitHub repo — agent instructions, description, starter prompt and the full Copilot Chat prompt: Cowork Investment Assessment
Copilot meeting recap/summary not working with channel meeting
The meeting recap function from copilot seems not to work with channel meetings. We arrange meetings through teams channels, but meetings from channels to not have the meeting recap function as in regular meetings. After the meeting is over, we are not able to use the copilot for these transkripts and meetings. How can we solve this issue? Is this on purpose from MS?
Launching DIY Data Control for Nonprofits
I want to create a library of open-source resources that helps self-taught IT champions in nonprofit organisations build fully governed, secure shared data systems. I have plenty of ideas about how to do this, but before I press ahead, I want to listen to the people I hope to support to ground those ideas in reality. For my first project, I want to draw on part of the Microsoft ecosystem, which provides some useful tools for safely building your own data systems: Microsoft Learn: Microsoft provides a wealth of free learning resources. I use them a lot and they are as good as other resources that I have happily paid for. The two big barriers to using them are finding time and working out where to start. The Common Data Model for Nonprofits: This is an open-source resource from Microsoft, it describes the tables of data that a nonprofit organisation needs, and the relationships between them. Once you add your own data it becomes a shared functioning model of your organisation. Role based column and row level security: This is the revolutionary part that lets you safely replace scattered spreadsheets with a single, comprehensive, shared model of your organisation. It lets you decide exactly which parts of which records people are allowed to see or change, so everyone who interacts with your shared model can only see and change the things that they need to. Model-driven Power Apps and Power BI: Once you have a detailed model of your organisation with governance baked into it, adding tools to interact with it becomes straightforward. Both Model-driven Power Apps and Power BI can understand the structure of your organisation from your model, and they will respect the governance policies that you built into it. In theory, these should provide all the tools you need to bring together scattered data in siloed spreadsheets into a single, secure, auditable shared source of truth. But there are gaps, and I want to find out what guides, signposts and tools would be needed to bridge them. Later I will want to explore the features that you could add with Copilot Studio if you wanted to. Once you have established a clearly defined, precisely secured data environment, Copilot Studio can provide the tools to develop and deploy AI agents safely. But for now, I will focus on the foundations of well-defined, well-governed, accessible data. If you have any thoughts about this project then I would love to hear them, and I’d especially like to find out what pain-points there are that I can target. So please do get in touch. Patrick Killeen Head and Heart CIC email address removed for privacy reasons https://www.headandheart.info/ This work is released under the MIT Licence and is available at https://github.com/head-and-heart-cic/public/blob/main/in-practice/2600707-launching-diy-data-control-for-nonprofits/README.mdDynamic Mandatory Fields
In a SharePoint library, I have folders which are = a. Admin b. Events c. Furniture and Moves d. Janitorial and Maintenance e. Parking and Transportation f. Shipping and Receiving g. Supplies and Equipment h. Waste and Recycling I have Meta data across the library whose data type are all choices and are: a. Document Type = Contract, Financial, planning b. Building = Gym, Garage, Heating c. Asset Category = Office, Playground d. Fiscal Year = FY23, FY24, FY25, FY26, FY27 e. Vendor = Maple Leaf, Canadian Tire, Home Depot f. Status = Active, Pending, Not Active g. Retention Label = 3 years, 5 years h. Service Type = Admin, Events, Furniture and Moves, Janitorial and Maintenance, Parking and Transportation, Shipping and Receiving, Supplies and Equipment, Waste and Recycling Service Type and Retention Label are mandatory fields, with the Rule below for all the files in the various folders: IF Folder Name = Admin, then Service Type = Admin and Retention Label = 5 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Events, then Service Type = Events and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year, Building and Vendor IF Folder Name = Furniture and Moves, then Service Type = Furniture and Moves and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Building IF Folder Name = Janitorial and Maintenance, then Service Type = Janitorial and Maintenance and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Parking and Transportation, then Service Type = Parking and Transportation and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Shipping and Receiving, then Service Type = Shipping and Receiving and Retention Label = 3 years; the mandatory fields should be Document Type, Status IF Folder Name = Supplies and Equipment, then Service Type = Supplies and Equipment and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Waste and Recycling, then Service Type = Waste and Recycling and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Vendor I have used Column Default Value Settings for SharePoint to display Auto-Display the Service Type and Retention Label, but I cannot seem to perform the conditional mandatory fields using Validations setting for the other requirements. Please helpCopilot on Edge Android InPrivate Now Requires Sign‑In — Guest Mode No Longer Accessible
Hello, I’m experiencing an issue when trying to use Copilot on the web while browsing in InPrivate mode on Microsoft Edge for Android. Until recently, I was able to open Copilot and start a guest conversation without signing in. This allowed me to keep separate chats easily. Starting today, whenever I open the Copilot website in an InPrivate tab, I immediately get a pop‑up screen that says: > Sign in to Copilot > Upload files, use Voice without limits, and make Copilot yours with memory across conversations. It then gives me three sign‑in options: Microsoft, Apple, and Google. None of these let me continue as a guest, and there is no “Maybe later” or “Continue without signing in” option anymore. Problem I am no longer able to access Copilot as a guest. The sign‑in screen appears every time, and I cannot bypass it. It seems like guest access has been removed, at least on Edge Android InPrivate. Expected Behavior Previously, Copilot allowed free guest access without requiring an account login. I would like to continue using Copilot in this way, especially for keeping conversations separate. Actual Behavior Copilot forces a sign‑in screen and does not allow guest access at all. Questions 1. Has guest access to Copilot been officially removed? 2. Is this change intentional or a temporary bug? 3. Can the previous behavior be restored so users can chat without signing in? Scenario Summary - Service: Copilot - Issue: Unable to open Copilot without signing in - Result: Copilot shows the “Sign in to Copilot” screen and blocks guest access - Device: Microsoft Edge (Android), InPrivate mode Any clarification or fix would be appreciated. Thank you.
Goodstack-Validated Nonprofit Rejected After Forced Resubmission — No Escalation Path
I am posting this because Microsoft Elevate frontline support told me there are no further escalation paths available, and I believe this may affect other nonprofits. Timeline of facts: - June 19, 2026: Goodstack, Microsoft's authorized validation partner, confirmed our nonprofit (Opera Verace Foundation, EIN 33-2305878, California 501(c)(3)) was approved for Microsoft nonprofit grants and discounts. - June 23, 2026: Microsoft Elevate support informed me the original application was in an unrecoverable system error state due to an unrecoverable error in their system, and they instructed me to resubmit under a different email address. I only had one email directed to my business email and asked if I could use a Yahoo email. - June 30, 2026: The same Elevate representative confirmed in email to me that using a Yahoo email address as a temporary workaround was fully supported and "the correct and supported path forward." - July 2026: A different Microsoft Validation Team (not the one I had worked with originally) rejected the resubmission (likely due to use of a yahoo.com email as my business email address) and demanded documents not listed in the published eligibility requirements, including a bank statement. They stated the original Goodstack approval cannot be reinstated. - When I pointed out that Goodstack's validation was never rescinded, that my organization's nonprofit status can be confirmed on propublica online, and that the resubmission existed solely due to Microsoft's own system error and instructions, I was told this was a determination of another team and no further escalation paths exist. The core issue: Goodstack validated our organization on Microsoft's behalf. Microsoft's own system error forced resubmission. Microsoft's own representative authorized the (incorrect) workaround in writing. The Validation Team is now treating the workaround submission as a brand new independent submission requiring extraordinary measures for re-validation, ignoring the Goodstack validation, ignoring the request to check propublica, and ignoring the fact that thier reuest for additional documents is nowhere to be found in Microsoft's own document requirements in Microsoft's published nonprofit eligibility policies. Ticket number: 2606210040000788 Is anyone at Microsoft able to escalate this to someone with authority over the Validation Team? Has anyone else encountered this after being directed to use a personal email for resubmission?
