The Excel UserForm has been the power user's answer to messy data entry since Excel 97: a proper dialog with labeled fields, a dropdown, an OK button, so colleagues type into a form instead of poking around your worksheet. The form itself rarely fails. What fails is everything around it. IT tightens the macro policy and the dialog never opens. One colleague now works on a Mac, another lives in Excel in the browser, and the supplier who is supposed to submit numbers sits outside your company and cannot run your code at all.
This post covers both halves fairly: how to build a UserForm the classic way, where the VBA route genuinely stops, and how to get the same guided input experience in any browser without writing a line of VBA.
How to build a UserForm in Excel
UserForms live in the Visual Basic Editor, not on the ribbon. The short version for current Microsoft 365 Excel on Windows:
- Open the editor with Alt+F11 (or Developer tab > Visual Basic; enable the Developer tab under File > Options > Customize Ribbon if it is hidden).
- In the editor, choose Insert > UserForm. An empty form and the Toolbox appear.
- Drag controls onto the form: a Label and TextBox per field, a ComboBox for choices, a CommandButton for OK. Name and caption them in the Properties window.
- Double-click the OK button and write the code that moves values into cells, for example Worksheets("Entries").Range("B2").Value = txtAmount.Value, followed by Unload Me.
- Add a short macro that calls UserForm1.Show, wire it to a button on the sheet, and save the file as .xlsm, the macro-enabled format.
That is a working form in under an hour, and for more depth on events, validation, and control types, Microsoft's VBA documentation is the right reference. Within one trusted workbook on one Windows desktop, a VBA UserForm is still a perfectly good tool.
Where the VBA UserForm stops working
The limits only show up when the file starts traveling, which is exactly what data entry files do.
"Microsoft has blocked macros from running because the source of this file is untrusted." Since 2022, Office blocks VBA macros in files that come from the internet by default, and an emailed .xlsm counts. Every recipient sees that red banner instead of your form, and unblocking is a per-file, per-person ritual (file Properties > Unblock) that many company policies forbid outright. Microsoft's own guidance is clear that this default is there to stay, because macro-carrying attachments are a top malware vector.
No desktop Excel, no form. Excel for the web does not run VBA at all, so anyone working in the browser never sees the dialog. On a Mac, VBA runs but ActiveX controls do not, so forms built on them misbehave. Phones and tablets are out entirely. And a contributor outside your company would need desktop Excel, your file, and the nerve to enable macros in it.
The form ships inside the workbook. A UserForm is a front door bolted onto a file the person already has. Whoever gets the .xlsm gets every tab, every formula, and a copy that starts drifting from your master the moment it leaves your outbox.
A UserForm in Excel without VBA
The modern route keeps the workbook as the engine and moves the form out of the file: you build it as a small web app on top of the same spreadsheet. In airrange that works much like the UserForm toolbox, minus the code-behind. You pick input elements (number fields, dropdowns, date pickers, text fields) and bind each one to a cell, so an entry in the form lands in the cell your formulas already read. A dropdown can take its options straight from a cell range, the way a ComboBox takes a RowSource. Required fields replace your validation code: the submit button stays inactive until the listed inputs are filled, and an email field only counts once it contains an @.
The difference is who can use it. The form is a link that opens in any browser, so the Mac colleague, the browser-only colleague, and the external supplier all get the same dialog, with no Excel, no macro warning, and nothing to install on their side. They see the fields you placed and the results you chose to show, not your workbook.
Getting values back into Excel is the part UserForm builders usually ask about first. The submit button uses a Send to Excel add-in action: each input carries a target address in the receiving workbook: sheet, column, and row, each either fixed or driven by a variable your workbook calculates. The airrange add-in for Excel then merges incoming submissions into the master file, and you approve changes before they land, instead of finding them later. One honest limitation: there is no automatic "append to next free row" yet, so for a growing log you either drive the target row from a counter variable or collect submissions in a table and review them there. The master file itself can stay local or on your own infrastructure; the add-in works in any Excel version that can run add-ins from the Microsoft store.
For the broader pattern beyond the UserForm crowd, the Excel data entry form post covers access levels and where submissions are stored, and the online form to Excel guide walks through a build step by step.
Which form belongs where
Keep the VBA UserForm when the form and its users live inside one trusted file on Windows desktops, when it leans on ActiveX, or when it is part of a larger macro system that already works. It costs nothing new and nobody has to learn anything.
Switch to a web form the moment the form crosses a boundary: another machine, another platform, another company, or an IT department that blocks macros. That boundary is where the UserForm stops being a form and becomes a support ticket. Rebuilding the dialog usually takes an afternoon, because the hard part, your workbook logic, stays exactly where it is. The Excel form builder page is the place to start with the sheet your UserForm writes to today.