A new Excel Think Tank
After nearly 30 years of using Excel commercially, I am now coming to retirement. But before I finally hang up my Excel boots, I have setup a small Excel think tank. The idea being people can send me their issues and I will work with you to build your permanent solution in Excel. I have created a number of solutions from Email Validator, Automatic dashboard creators, Fraud analysis, Auto resume makes, Music Syns (All in Excel), so if give it try.
Excel App Builder: Should Excel Support Turning Workbooks into Standalone Low-Code Applications?
Excel has been much more than a spreadsheet application for a long time. In many organizations, Excel is already used as an informal low-code development platform. Advanced workbooks often contain not only data and formulas, but complete domain-specific logic: calculation models, planning tools, dashboards, input forms, reports, simulations, administrative workflows, and sometimes even small internal business applications. This is one of Excel’s greatest strengths. It allows domain experts, power users, analysts, engineers, teachers, consultants, and small businesses to build working tools without becoming full-time software developers. However, there is a structural limitation: the final product usually remains an Excel workbook. That creates several problems: the user needs a compatible Excel installation, macro security and Trust Center settings can block functionality, formulas and business logic are difficult to protect properly, distribution and updates are not as clean as with real applications, workbook-based tools often look less professional than standalone software, user interface, data, and logic are often mixed together in the same file. I believe Microsoft could turn this existing reality into a major strategic opportunity. Core proposal: Excel App Builder / Excel Runtime My suggestion is an official Excel App Builder or Excel Runtime. The idea would be to allow selected Excel workbooks to be packaged as protected standalone applications. Excel would continue to serve as the calculation, data, and automation engine in the background. The end user would not necessarily see the workbook itself. Instead, they would interact with a clean application interface: input forms, buttons, dashboards, charts, reports, controlled tables, and export options. Possible output formats could include: Windows apps, web apps, Teams apps, SharePoint apps, mobile-friendly internal tools, protected specialist applications. This would not replace Power Apps. In my view, it could complement Power Apps very well. Excel could remain the place where fast domain logic, calculations, prototypes, and models are created. Power Apps, Dataverse, Azure, and the wider Microsoft ecosystem could then support larger, scalable, enterprise-level workflows. In other words: Excel could become the natural entry point into Microsoft’s low-code ecosystem. Why this could matter strategically Excel already has an enormous “hidden developer base”: people who are not traditional programmers, but who build useful tools with formulas, tables, Power Query, Power Pivot, VBA, Office Scripts, and now AI assistance. This is a unique market position. Many of these users would not start with C#, JavaScript, Python, or a full application framework. But they already start with Excel. They already build the logic there. The missing step is a professional way to package, protect, distribute, and update those solutions. An official App Builder could: strengthen Excel’s long-term relevance, differentiate Excel from simpler spreadsheet competitors, create a stronger bridge between Excel and Power Platform, give power users a professional deployment path, create new commercial licensing opportunities, reduce the need for fragile VBA/UI workarounds, make Excel-based tools more secure and maintainable. Example use cases A small engineering office creates a technical calculation workbook and exports it as a protected customer tool. A school or university builds a grading, diagnostic, or planning tool with Excel logic but provides staff with a clean app interface. A small business turns an Excel-based quotation calculator into an internal sales app. A finance department packages a planning model as a controlled scenario tool for managers. A consultant builds specialized calculation tools and distributes them professionally without exposing the workbook structure. These are not exotic scenarios. Many people already build this kind of logic in Excel today. The difference would be that Microsoft could provide an official, safe, and professional deployment path. Supporting features that would make this stronger 1. Modern UI layer for Excel-based apps Excel-based applications would need a modern interface layer: forms, dialogs, navigation pages, buttons, card layouts, dashboards, responsive views, mobile-friendly layouts, role-based views, binding to cells, tables, named ranges, and data models. This would create a clearer separation between data, logic, and user interface. 2. Protected workbook logic A professional app export would require strong protection options: hidden formulas, protected named ranges, protected scripts or macro logic, defined input areas, digital signing, controlled editing, update mechanisms, possible licensing controls for commercial distribution. 3. Formula cells with controlled manual override One frequent Excel problem is that users overwrite formulas. A useful new cell mode could be: default formula + optional manual override The cell would keep the original formula internally but allow a controlled manual exception value. Excel could show whether the formula is active or manually overridden. This would remove many helper-column and VBA workarounds in planning, pricing, grading, budgeting, and technical models. 4. Native database layer inside Excel Excel is widely used as a database, even when that becomes fragile. A native database layer could support: primary keys, relationships between tables, required fields, validation rules, change history, duplicate detection, form views, simple queries, optional cloud synchronization. This should feel like a natural extension of Excel tables, not like a separate database product. 5. Multidimensional workbook models Many workbooks use separate sheets for months, locations, versions, departments, or scenarios. This often creates duplication and maintenance problems. Excel could support native dimensions for tables and models, for example: time period, location, scenario, version, department. Formulas, charts, dashboards, and PivotTables could become dimension-aware. This would be especially useful for financial planning, controlling, simulations, scientific models, and project planning. Why now? AI is changing how people build with Excel. Copilot and other AI tools make it easier for non-programmers to generate formulas, scripts, models, and structured workflows. That means more users will be able to build complex Excel-based solutions. But if AI helps users create more advanced workbooks, the next logical question is: How can these workbooks be safely packaged, shared, protected, and used as real tools? An Excel App Builder could be the answer. Possible first step This does not need to start as a massive platform. A realistic first version could be experimental: selected workbook ranges, simple input forms, protected formulas, dashboard view, Windows or web runtime, export as an internal app, optional Teams or SharePoint integration. It could even begin as an Excel Labs / Microsoft Garage style experiment to test demand and gather feedback from power users, developers, and organizations. Core question for the community Excel is already used as a hidden development platform. Should Microsoft make this official? Would an Excel App Builder / Excel Runtime be useful for your organization, clients, or internal tools? Which feature would matter most in a first version? protected workbook runtime, modern UI layer, formula override cells, native database layer, multidimensional models, Power Platform integration, commercial app distribution? I would be very interested to hear how other Excel users, developers, MVPs, and Microsoft product people see this idea. In short: Excel already allows millions of people to build domain-specific logic. Microsoft could turn that strength into an official, secure, and economically attractive low-code application platform.
How can I overcome the HYPERLINK Functions 255 character limit?
Hi! I am trying to workout how to overcome the 255 character limit for the hyperlink function in excel. Currently I have formulated a HYPERLINK link which pre-populates information for a 3rd party form (JotForm) with values from my spreadsheet. It displays #VALUE! in the cell. Does anybody have any suggestions or solutions for overcoming this issue? Thanks!
I want to record a VBA macro. The Record Macro button only records OfficeScript. How?
I saw another post drawing the disctinction between the Automate toolbar tab and the Developer tab, but that distinction doesn't seem to work anymore. The Record Macro button only produces script. Is there another way to get VBA recording?
Excel Macros Spreadsheets Not Loading
I've spent some time with Microsoft Support (almost 3 hours, including uninstalling my MS 365 and reinstalling it), but I'm having an issue with my Excel Macro spreadsheets not loading at all. This is what I get each time. Also having an issue with non-Macro spreadsheets that I'm unable to use the Bold, Italic, and Underline functions (get the spinning wheel and then Excel Not Responding), as well as not able to use the Format function (get the same spinning wheel and then Excel Not Responding). I've been using these same Excel Macro Spreadsheets for over 15 years. Please help!Excel repair strips all formulas from large .xlsm after March 2026 security update (KB5002849)
Hi everyone, I'm a master's student at Karolinska Institutet in Stockholm. My thesis is a health economic cost-effectiveness model built entirely in Excel — a gender-neutral static Markov cohort model with 34 worksheets. The file has become completely unusable after what I believe is the March 2026 security update, and I'm running out of options. The file: - .xlsm, ~46.5 MB compressed, ~370 MB uncompressed XML - 34 worksheets, four of which are 73–92 MB each (Markov trace sheets) - ~65,000 formulas, ~33,500 shared formulas - Heavy use of LET, LAMBDA, XLOOKUP, XMATCH, CHOOSECOLS, TAKE, MAP, SWITCH - 771 defined names including ~147 hidden _xlpm.* LET/LAMBDA variable placeholders - Stored on OneDrive via KI SharePoint, 34,000+ AutoSave revisions - Contains VBA (vbaProject.bin) The problem: Every time I open the file — on Excel for Mac or Excel Online — the repair engine triggers and strips ALL formulas from every sheet, replacing them with cached values. The file shrinks from ~46.5 MB to ~26 MB. Clicking "No" on the repair dialog just closes the file. There is no way to bypass the repair. What I've verified: - Extracted the .xlsm as a ZIP and confirmed all formulas (<f> tags) are fully intact in the raw XML - Libr€Office Calc can read the formulas but cannot execute them (Err:508 — no LET/LAMBDA support) - Removed 158 broken named ranges (#REF! and #NAME? entries) from workbook.xml and rebuilt the archive — repair engine still strips all formulas - The issue reproduces on every OneDrive version history copy (up until I largely used LET formulas in my sheets - but there is still 1,5months of changes lost) - The issue reproduces on both Excel for Mac and Excel Online Suspected cause: The March 10, 2026 security update (KB5002849) patched CVE-2026-26108, a heap overflow in Excel's file parsing during loading. The same patch was applied to Office Online Server (KB5002846). I believe the tightened parsing now rejects or flags my file's large XML structures as potentially malicious, triggering the repair engine to strip all formulas. This is consistent with: - The known _xlfn. namespace bug on Excel for Mac (reported by multiple users on Microsoft Q&A since late 2024) - The timing - the file was working before this update flawlessly up until March 16th - The fact that Excel Online is also affected (same server-side patch) My questions to the community: 1. Has anyone else experienced formula stripping on large workbooks after the March 2026 update? 2. Is there a way to bypass the repair engine on Mac, or roll back the specific security patch without downgrading all of Office? 3. Would opening this file on Windows Excel (pre-patch or current) preserve the formulas? If anyone with a Windows PC would be willing to try opening and re-saving this file, I would be incredibly grateful. 4. Is there now effectively a size/complexity ceiling for Excel workbooks that makes models like this unviable? If so - should I be migrating this to another environment (R, Python, etc.) going forward? This file represents six months of thesis work. The formulas are all there in the XML. I just need Excel to stop destroying them on open. Any help, pointers, or similar experiences would be hugely appreciated. Thank you, Florian Boschek
A 40,000+ VBA line Block and Stack workplace planning tool made in Excel
Hi all, I’ve been an Excel user for a long time, but until the last 8 months I had never really explored the full power of Excel/VBA. With AI’s help, I’ve been building a workplace Block and Stack planning tool called Work Stack. It’s a niche use case, but a very real one in my industry, supporting corporate office planners, workplace teams, and anyone trying to move and reorganise teams within an office. When I first started, I thought an AI agent would simply be able to generate the answer for me. I quickly realised that wasn’t enough, especially when it came to reliably recreating the block and stack image and handling the planning logic behind it. That was when I decided to build it properly. I have zero coding background, but 15+ years of workplace experience, so the setup became: AI as the code developer, and me as the product owner, logic lead, tester, and relentless breaker of whatever had just been built. I moved very quickly at first and had a “working model” within about 6 weeks. The problem was that it produced all sorts of crazy results and was basically unusable, untestable, and unfixable. That was where I learned some hard lessons about relying too heavily on arrays and not being disciplined enough with separation of concerns. Version 1 was a false start, but a very useful one. I scrapped it and rebuilt the tool properly from scratch. The rebuild took 6+ months rather than 6 weeks, but Work Stack is now at beta stage and is being tested and demoed by industry peers. Attached are 3 images: Image 1 — Current Stack This is a standard desk-sharing workplace stack. It shows teams grouped into functions, some placed in neighbourhood zones, some co-located with other teams (shown with the two-headed arrow), and some “breached” teams shown with a red border where they are sharing desks more aggressively than the building guideline allows (80% in this example). There are also scattered spare desks shown in white blocks at the end of floors. As teams move, the team blocks, floors, and footer totals all recalculate automatically. Image 2 — AutoStack Output This is the result of running the most complex feature in the tool: AutoStack. It assesses the current stack and then restructures it based on the user’s instructions. In this example, I asked it to fix all breached teams, reunite teams with their function groups, dissolve neighbourhood zones and co-locations, and consolidate spare desks where possible. Something that would normally take a space planner weeks of effort can now be done by VBA in Excel in seconds. That part still blows me away. Image 3 — Stack Editor This is the main parent form, called Stack Editor. It acts as the control hub for creating, editing, and customising the stack. At the moment it has 37 features and counting. Under the hood, the rebuilt version is structured far more seriously than the original. It uses an object-oriented VBA model built around core class modules for the plan, floors, and teams, with supporting classes for things like zones, functions, financials, and rendering. In other words, the stack is modelled as real objects rather than just spreadsheet rows. I also rebuilt it with much stricter boundaries between logic, persistence, rendering, and UI. That discipline is what made the second version stable enough to keep growing, and it is a big part of why the codebase has now grown to 40,000+ lines without collapsing under its own weight. I mainly wanted to share this with people who might appreciate this very specific use case in VBA. At some point I may need to port it to Python or something similar, but for now I’m honestly amazed at how far this 30-year-old language can be pushed.
