How to Create and Edit Table With Enter Data in Power BI (Manual Tables) Easily 2026

From the ribbon in Power BI Desktop, click Enter Data. A dialog titled "Create Table" opens with a small spreadsheet-like grid, starting with a single column named Column1 and one empty row ready for input.

A Name field at the bottom renames the table before loading it. Power BI defaults to something generic like Table, so give it a descriptive name now instead of renaming it later once other visuals may already reference it.

Click the plus icon next to Column1 to add columns, and rename each one by double-clicking its header. For a simple product-and-price reference table, that might mean columns named Product and Price. Click into each cell and type values directly, pressing Tab to move across a row and Enter to drop to the next one, the same way you'd fill in any small spreadsheet.

Once the data is entered, click Load instead of Edit. Load brings the table straight into the model and closes the dialog, while Edit routes through Power Query first for transformations before the data lands. After loading, Power BI shows a confirmation dialog reporting how many rows loaded successfully, a quick way to catch a typo if the count doesn't match expectations.

Switch to Data view using the icon on the left sidebar, and select the new table from the Data pane to see it laid out as rows and columns, the same as any table pulled from an external source. To edit values later, there's no need to reopen Enter Data: select the table and use the transform tools on the ribbon, or return to Power Query's Edit Queries to adjust the source values in the same grid used originally.

One constraint is worth knowing before relying on this for anything shared with a team: Microsoft's documentation states that a manually entered table can only be updated, added to, or deleted from inside Power BI Desktop, then republished. Editing it from the Power BI service isn't supported, so a colleague viewing the published report in a browser can't patch a typo there.

Manual tables suit small, stable reference data: a mapping of region codes to region names, a short list of budget categories, or threshold values a report checks against, the kind of thing that might change once or twice a year at most. They're the wrong tool for anything that changes often or grows past a few dozen rows, since every update means manually reopening and re-editing the grid instead of refreshing from a live source. That manual step is exactly the kind of thing that gets forgotten when a report is handed off to someone else on the team.

Label manually entered tables clearly. A prefix like "Ref_" or "Manual_" in the table name makes it obvious at a glance which tables come from a live connection and which ones a person typed in by hand. This matters most when troubleshooting a report months later and needing to quickly tell whether a value needs updating in a source system or just needs a manual edit, especially when someone other than the original report author is doing the troubleshooting.

A manual table becomes far more useful once it's connected to the rest of the model instead of sitting on its own. Open Manage relationships and link its key column (Product, in the example above) to the matching column in a larger fact table, the same way any two imported tables would be related. Once that relationship exists, values from the small manual table can filter, label, or categorize the larger dataset, which is usually the whole point of building it by hand instead of leaving it as a disconnected reference list.