Access and SharePoint Integration May Be Broken
I am posting this here in the hopes that a Microsoft MVP or employee may see it, verify the issue, and report it to the right people at Microsoft. We have a fairly significant LOB application with the front-end hosted in Access and the back-end hosted in SharePoint Online lists. This application has been working well for several years. Sometime in the past few weeks (last known good date was June 23), a change in either Access or SharePoint (or maybe the Windows OneDrive sync client) seems to have broken integration between the products. When the modern cache format is enabled (the default), all SharePoint calculated columns unexpectedly show errors, as shown here (in a fresh database where I imported just one list from our site as a test): Naturally, this completely borks the application, with VB code throwing errors at startup. Using the legacy cache format, or disabling caching altogether, seems to restore functionality--(though this would come at a cost to performance): But there is a major caveat to this. Other functionality is apparently broken. We have straightforward update queries, for example, the hang indefinitely in these modes, rendering this an unacceptable work-around. I have been able to replicate this on several different PCs. Also, on several different SharePoint sites in our tenant. Currently, this is blocking work for us, and we are hoping to see it resolved as soon as possible. If anyone with knowledge of the right people at Microsoft to call attention to this, we would be grateful for any help. I am using the Access forum because the last time I tried to get help from SharePoint Online support for an Access-related query issue using SP list data, they had no idea what I was talking about. (Also, for Access database experts: please do not suggest that we avoid using calculated columns in SharePoint lists. This is a hybrid app with most of our users working with data strictly through SharePoint, and SharePoint views do not support the same features as queries do in Access. Making use of these SharePoint features are essential for these users.) Our Access version: Microsoft® Access® for Microsoft 365 MSO (Version 2607 Build 16.0.20228.20124) 64-bit Thank you in advance for any help.AutoSave disabled when opening SharePoint-synced files from Finder after macOS Tahoe 26.6 update
Files stored in SharePoint Online and synchronized locally through OneDrive are opened as local documents when launched from Finder. Office applications display "Saved to my Mac" and AutoSave is turned off by default. However, opening the exact same files through Word/Excel > Open > Sites, or via SharePoint "Open in Desktop App", correctly identifies them as cloud documents. In that scenario, AutoSave is enabled and collaboration/version history features work as expected. Troubleshooting already performed: OneDrive reset and re-linked SharePoint library re-synced Signed out and back into both Office and OneDrive Removed Microsoft credentials from macOS Keychain and re-authenticated Recreated local OneDrive sync relationships Verified OneDrive File Provider extensions are enabled Verified Office applications and OneDrive are fully up to date Tested with newly created files and existing files Tested "Always Keep on This Device" with no change in behavior The issue appears to be specific to the Finder-to-Office launch path after upgrading to macOS Tahoe 26.6. Before upgrading to macOS Tahoe 26.6, opening the same SharePoint-synchronized files directly from Finder correctly preserved cloud document identity and AutoSave was enabled as expected. I discussed this issue in detail with Apple Support, but they quickly dismissed it, saying that the problem is not on Apple's side and that I should contact Microsoft instead.
A new SharePoint Look and Feel: What’s Changing and Why It Matters
SharePoint is getting a refreshed look and feel designed to make the product feel simpler, clearer, and more focused on your content. We’ve recently introduced a new SharePoint experience, organized around helping you discover knowledge, publish content, and build solutions. Along with that new experience, we’re introducing visual updates across key product surfaces that reduce visual noise, improve readability, and bring more consistency to the interface while preserving the branding investments your organization has already made. We call this work the SharePoint visual refresh: a thoughtful update to the product’s visual language that helps SharePoint feel more modern, approachable, and easier to use. Background Over time, SharePoint’s capabilities have continued to grow, which has given us an opportunity to update the look and feel as well. These updates not only make the SharePoint UI fresh, but it ensures that we are consistent across M365. The SharePoint visual refresh, rolling out to general availability now, is part of a broader collaborative effort across Microsoft 365 to modernize the suite and improve usability with this bold, new visual design, while also responding to customer feedback about visual clutter and the need for clearer focus on content. These updates are grounded in core design principles that prioritize usability, coherence, and a sense of delight in everyday interactions. This bold, new design is part of a larger update across many apps (such as Microsoft 365 Copilot) and platforms that family together to create a cohesive, modern look and feel. Goals The Visual Refresh is guided by several key goals: Deliver a more contemporary, polished look aligned with the broader Microsoft 365 experience to existing and new SharePoint experiences Improve consistency, usability, and accessibility across key SharePoint surfaces, including Sites, Pages, and Document Libraries and the new Discover, Publish, Build destinations. Reduce visual clutter to improve focus on what matters most: your content Create a design system that scales, from simple team sites to complex enterprise scenarios Consistency Across Experiences Once adopted, the visual refresh will strengthen alignment between SharePoint, OneDrive, Teams and the Microsoft 365 shell, reducing visual fragmentation across navigation, pages, and components. By aligning how our UI looks and our theming approaches, we aim to create a more predictable experience for users moving between tools and surfaces, helping avoid visual dissonance and reducing cognitive load across day‑to‑day workflows. What’s being updated Canvas elevation: putting content in the spotlight One of the most noticeable changes is the elevation of the SharePoint site canvas. By adding a subtle shadow, refined spacing, and a light gray shade to backgrounds, the refreshed design helps your content stand out, making it easier to scan, read, and interact with pages. Importantly, this is not achieved by changing your content. Instead, the improvements come from thoughtful adjustments to padding, layout spacing, and visual framing, ensuring that the emphasis remains on the information you create and manage. This does not effect existing layouts or how sites reflow. Neutral theming for app surfaces We’re also evolving how themes are applied within SharePoint to improve consistency, accessibility, and clarity across experiences by separating the core SharePoint user interface from customer content. Updated neutral theming of app surfaces provides a more stable visual foundation and establishes a unified set of navigational UI, where the customer brand remains in an anchor position and is in harmony with the new neutral navigation. This approach allows customer branding to be expressed more clearly without competing with structural UI elements, clarifies the distinction between customer branding and the SharePoint app, reduces visual competition, and improves focus on primary content. ual noise, improving usability. Styling updates Additional updates to typography, spacing, and corner rounding introduce a more cohesive and contemporary visual language across SharePoint surfaces. Updated typography and spacing enhance readability and create more consistent rhythm across pages and components, making information easier to scan and interact with. At the same time, increasing corner radius of the UI makes it feel more approachable, and through a flexible system brings greater consistency to our products, helping related components feel more integrated and visually connected. Together, these refinements simplify the overall interface, reduce unnecessary visual noise, and contribute to a lighter, more modern experience that aligns more closely with the broader Microsoft 365 design ecosystem. What’s Not Changing While the visual refresh introduces meaningful visual improvements, core SharePoint concepts and workflows remain familiar. Your content, structure, and brand are preserved Existing site architecture remains unchanged Day‑to‑day workflows continue to work unchanged There is no impact on existing SPFx extensions or solutions with this change This update focuses on evolution, not reinvention, so users can benefit from improved clarity and modern visuals while familiar work flows and patterns remain the same. Evaluated with Research Across our research studies, participants consistently favored the Visual Refresh due to the cleaner and more contemporary look and improved labeling and structure. A calmer, more modern UI that’s easier to scan. Elevation + neutral theming made the page feel cleaner and it is easier to focus on the content. Clearer actions in the command bar. Stronger affordances (like button outlines) make common tasks - edit, undo, save, share - more obvious and easier complete workflows. Less guesswork when navigating. Icons and labelling in the app bar reduced friction and participants spent less time hovering and interpreting icons, especially those less familiar with SharePoint. Overall, the Visual Refresh provides users with a new look they prefer without slowing down their workflow. Looking Ahead The SharePoint Visual Refresh is part of an ongoing journey. We’ll continue refining the experience, learning from customer feedback provided directly in-product, and shipping improvements incrementally, so SharePoint keeps getting better without disrupting how people work. Familiar workflows will remain in place, now enhanced by improved clarity, consistency, and a more modern feel. We welcome all feedback! See this post for more information about SharePoint’s exciting next chapter.
Extreamly frustrated that I cannot get help for a serious problem
What the devil do I have to do to get help with a serious problem with the cloud for our non-profit business account for our small charity. I have 'lost' sight of a large number of documents from the cloud since we had to start paying for our subscription. After many chats with ai and emails and the problem being escalated I have now been told to go back to where I started at Non-profit support and put a support ticket in. Doesnt matter what machine I use, what browser I use, what network I use, I cannot get past the submit form page and keep getting an error message - this has been going on for weeks now. Ive tried ringing and the call keeps dropping while on hold - no one, no-one will call me about the problem and no one seems interested in dealing with the problem and its not just affecting me on our system either. Please will someone tell me how to get to a human for support without using an AI help system,SharePoint Showcase: 10 Custom AI Skills Every SharePoint Site Owner Should Build
In this edition of SharePoint Showcase, we explore how skills work, how to create or install them, and ten practical examples to help SharePoint site owners get started. These examples are not an exhaustive list, but a curated starting point for identifying everyday processes that can become reusable, team-ready skills.Web invoke in power automate says unauthorized but can browse from browser
I am able to browse to this url directly from browser https://my365.crm9.dynamics.com/api/data/v9.2/audits?$filter=objecttypecode%20eq%20%27myissuetable%27%20and%20_objectid_value%20eq%20%271de46d6b-b986-f111-ab0e-001dd80b339b%27&$select=_objectid_value,objecttypecode,changedata,createdon,_userid_value but when i use the invoke http from power automate it says unauthorized. i am using the same account. What is the issue is there anything i need to do so that it works?Which SharePoint Communication Site layout has worked best in your organization?
Hi everyone, We're redesigning our SharePoint Online communication site and comparing different homepage layouts for HR, IT, Finance, and Corporate Communications. I'd like to hear from the community: Which homepage layout has worked best in your organization? Which web parts do you consider essential? Have you found any design patterns that significantly improved user adoption? Looking forward to learning from your experiences and recommendations.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.
