Office Script Buttons in Excel on the Web don't work

Anonymous8 85 Reputation points
2026-08-24T19:49:04.88+00:00

We use buttons to run office scripts in excel on the Web. the button keeps on losing its functionality, it becomes a lifeless shape and doesn't respond when pressed. when running the script from the automate tab it works well. The issue is not with the script or sharing permissions, it is only the button that doesn't work. after playing around with the workbook (opening in desktop, pausing and resuming the sheet protection, etc.) the button can start working again but it doesn't last long.

User's image

Microsoft 365 and Office | Excel | For business | Other

2 answers

Sort by: Oldest
  1. Kai-L 18,970 Reputation points Microsoft External Staff Moderator
    2026-08-24T20:19:43.2666667+00:00

    Hi Anonymous,

    Since the script runs correctly from the Automate tab, the script itself looks healthy. The problem appears to sit with the button object and its link back to the script inside the workbook. The two things that temporarily bring it back, opening in desktop and toggling sheet protection, are useful clues, so a few details would help narrow this down:

    • Does the button lose its function for everyone, or only for certain users?
    • Does it break after a specific action, such as someone opening the workbook in the Excel desktop app, or after the sheet is protected?
    • Is the button placed on a protected sheet, and is the shape itself locked?
    • Is the workbook stored in OneDrive or SharePoint, and is anyone editing it in the desktop app at the same time?
    • Does the script run under your account or a shared one, and is it stored in your own OneDrive or shared to the workbook?

    While you gather that, it is worth testing a few things:

    1. Keep the workbook in the browser only for a few days and ask everyone to avoid the desktop app. Script buttons are a web feature, so a desktop editing session is the most likely candidate for breaking the link.
    2. Delete the broken button and add a fresh one from Automate, then note exactly what happens just before it goes inactive again.
    3. Test the same button on an unprotected copy of the sheet to see whether protection is involved.
    4. Try it in a different browser and in a private window to rule out a local caching problem.

    If the button still fails with the workbook kept in the browser and protection off, that points to a product side defect. At that stage it is worth having your admin raise a support case so it can be logged and escalated, and you can also report it through Help > Feedback in Excel for the web. For guidance on opening a case, see Get support - Microsoft 365 admin. If you don't know who your IT administrator is, please refer to this article: How do I find my Microsoft 365 admin? - Microsoft Support 

    I hope this helps. Looking forward to your reply.


    If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment".  

    Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?


  2. concerneduser-6265 0 Reputation points
    2026-08-27T14:40:11.5966667+00:00

    Hi Kai-L,

    Another data point from a different environment, in case it helps.

    We have Excel workbooks with Office Scripts attached to worksheet buttons. They worked normally for a long time and then suddenly stopped, with no changes on our side to the scripts, the workbooks, or the sharing settings as far as we know. Clicking a button returns "The button cannot run because the script was unshared. Contact the owner to share it again."

    We are the owner of the script, so there is no one else to contact, and it was never unshared on our side. The script still runs correctly from the Automate tab. Only the button path fails.

    One detail that may be relevant to your hypothesis that a desktop editing session breaks the link: we reproduce this consistently in BOTH Excel Desktop and Excel for the web, on the latest Excel version 2607. The failure is not confined to the web client, which points to the service side rather than something introduced by a desktop session.

    Given how many separate reports show identical behavior, could this be escalated to the Office Scripts product team as a possible service-side regression, rather than being handled case by case as a configuration issue?

    Thank you!

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.