Working with multiple users in Excel at the same time
By Dennis Spoelder · published 31 July 2026
Where collaborating in Excel does work, and where it stops
Working with multiple users in Excel at the same time — multi-user, co-authoring or a shared workbook — genuinely works these days. With the file in OneDrive or SharePoint Online and in an ordinary Excel format, several people edit it at the same moment: you see where your colleagues are, and changes are merged automatically. Taking turns is no longer necessary for that.
Sorting and filtering need not get in anyone's way either. A Sheet View lets you sort or filter for yourself alone, while your colleagues keep their own view. That is precisely what collaborating in a file used to break on.
Whether a file is enough does not depend on how big it is, but on what it has to enforce: access rights managed in one place, data validation you can rely on, and simultaneous changes that are controlled. Where that is needed, a shared file runs into the limits below - which is why business-critical applications usually keep their data in a database rather than in a file:
"Upload Failed" or "Upload Blocked": your changes could not be merged
Excel uses both wordings for the same problem, and it is the message collaborating in a file can run into. It does not appear on every edit; it can appear when two people change the same cell at once, or when someone has been working offline for a while:
- "Upload Failed" or "Upload Blocked." Your work is still there, but the file on the server has been updated without you in the meantime. At that point there are two versions.
- If merging does not work, saving a copy is often the way out. That is how a row of files nobody can tell apart any more can come about.
- You can edit a macro file in the browser too; only the macros do not work there. Co-authoring works with .xlsx, .xlsm and .xlsb, so the file format is not the limit. Excel for the web opens and edits a workbook that contains macros, and the macros stay in it - but they do not run there, and they cannot be edited there. And the browser is exactly where simultaneous editing runs most smoothly. An application with buttons and forms therefore belongs on the desktop.
- One outdated Excel in the group locks the file for everyone. If someone opens the workbook in a version that does not support co-authoring, the others get the locked error. The same goes for the Strict Open XML format, which co-authoring does not support.
- If your SharePoint runs on-premises, simultaneous editing does not work. It requires OneDrive or SharePoint Online.
- Permissions apply per file, not per row. You give someone access to the whole workbook or to nothing. Showing or letting them change only their own department is not possible, and sheet protection is no answer to it: that guards against mistakes, not against unauthorised people.
- A check in the file only holds for that file. Excel can certainly refuse to save while a required field is empty: with a BeforeSave check in VBA that is ordinary work, and we build checks like that for clients. But the rule lives in that one workbook and only works while its macros run - not in Excel for the web, not when macros are disabled, and not for anyone who changes the data with another program. A database keeps the rule with the data itself, so it holds for everyone, whichever file or program they use to get at it.
Three routes, and where they part company
"Working with multiple users in Excel" is not one thing. There are three separate routes, and which one fits depends on what the file does — not, in the first place, on how many people use it.
1. A shared workbook, or co-authoring
Excel handles it itself, through OneDrive or SharePoint Online. That works well for a list, a schedule or an overview several people update at the same time - with Sheet Views each can keep their own sorting and filtering too. The limits above belong to this route: the file is the storage, so two people touching the same cell have to be merged, and permissions apply per file rather than per row.
2. Excel on a database
The Excel file stays the shell you work in, but the data lives in a central database. There is then nothing left to merge, because each piece of data sits in exactly one place. This route scales furthest: in the resource planning case, 7,500 people worldwide work in the same system this way. The trade-off is that you get an application rather than a file, with the administration, access rights and maintenance that come with it.
3. A custom web application
No Excel on the user's side at all. That is the route as soon as people need to work on a phone or tablet, from outside the company network, or without an Office licence. You do give up what Excel is good at: working something out yourself on the spot, adding a column of your own, exporting the way you are used to. See custom web applications.
Back to topWhat we do
We build routes 2 and 3. On route 2 you simply work in Excel, on your own computer; the difference is that your data doesn't only live in the file, but on a central server. Depending on your situation, you work entirely from that server, or your Excel file keeps its own working copy that's synchronised with the server.
Two changes no longer collide after the fact: the server allows one edit per record. If you want to change something a colleague is already working on, you see straight away who that is — no error message afterwards, but clarity beforehand. Viewing is no problem in the meantime: anyone with read access can retrieve the data while someone else is working. And you decide who can see and change what.
There is then one place where the data lives. So there is nothing left to merge, and no second version to mistake for the right one.
Back to topDoes this sound familiar in your organisation?
Briefly describe what you're dealing with, and we'll recommend the most suitable approach.