Sigma Input Tables: Write-Back for Budgets, Forecasts, and Overrides

Every finance team has the spreadsheet that sits next to the dashboard. The forecast lives there, the manual adjustments live there, and someone pastes them back into the warehouse at month end. Sigma input tables put that grid inside the workbook and write what people type to your warehouse.

They save the copy-paste step, but only if you set up the write destination, permissions, and keys properly. If you want help building a budget or forecast workflow this way, that's part of our Sigma Computing consulting work.

Key takeaways

• Sigma input tables are workbook elements for structured data entry. Sigma writes the data to a write schema in your warehouse, with an edit log, and doesn't overwrite your source data.
• There are three types: empty, CSV (up to 200 MB, UTF-8), and linked. A linked input table adds editable columns next to rows from another element, matched on a primary key.
• An admin must turn on write access for the connection first. Sigma recommends a dedicated writeback schema.
• By default only people with Can edit access can enter data, and only in the draft. You can allow edits in the published version per table.
• Sigma has no built-in approval button. You can build one with a single-select status column and an Update row(s) action.

What is a Sigma input table?

A Sigma input table is a grid in a workbook where people type or paste values, and Sigma saves them to your data platform. You can use the result as a source for tables, pivot tables and charts, or bring it into other data with Lookup and joins.

Input tables support keyboard entry, pasting up to 2,000 rows and 25 columns, data validation, protected columns, and data entry permissions. Columns can be text, number, date, checkbox, or multi-select for entry, plus calculation and lookup columns, and system columns such as Last updated by, per Sigma's overview.

Which type of input table should you use?

Use a linked input table when people are adding numbers next to existing rows, such as a forecast for each department. Use an empty or CSV input table when the data has no home in the warehouse yet.

Pick the primary key carefully

A linked input table matches each row to one row in the parent through a primary key. Sigma's docs warn that if the key is duplicated, changed, or converted differently, existing input can appear to be missing.

Use a record ID or another stable unique value. Sigma says to avoid dates and timestamps, generated row numbers, and anything that can change, such as names, statuses, or categories.

How does Sigma write input table data back to the warehouse?

Sigma writes input table data to the write schema configured on the connection, and keeps a separate edit log for each table in the same schema. Those tables have names that start with SIGDS_, and Sigma says not to modify them.

Three things about storage that trip people up:

1. You can't query the stored tables directly. They're optimized for storage. To read input data from SQL or another tool, create a warehouse view for the input table.
2. Deleting the element doesn't delete the data. Sigma leaves the rows in your data platform. You remove them there.
3. Copies get new IDs. Duplicating the workbook, creating a tagged version, restoring a version, or swapping the connection replaces the input table with a copy, per the audit history docs.

Turn on write access first

An admin turns it on under Administration > Connections, edits the connection, and switches on Enable write access. The warehouse side differs for Snowflake, BigQuery, Databricks, Redshift, PostgreSQL, MySQL and AlloyDB. Sigma reserves the write schema for its own objects and hides it from the data catalog, so don't point it at a schema people use for reporting.

OAuth connections have extra steps, covered in About OAuth with write access.

A synthetic example: a Q4 department forecast

Here is a small synthetic forecast. Actuals come from the warehouse. Forecast, reason, and status are typed in.

The Q4 forecast totals $375,000 against $348,000 of Q3 actuals.

To build it:

1. Make a table of departments and Q3 actuals from your warehouse.
2. Click Add element, and under Input tables choose Linked. Pick the departments table as the source.
3. Choose Dept ID as the primary key, and link Department and Q3 actual.
4. Add a number column for Q4 forecast and a text column for Override reason.
5. Add a single-select column for Status with the options Draft, Submitted, and Approved.
6. Add the Last updated by and Last updated at columns so you can see who changed each row.

Who can edit an input table?

Editing depends on the account type, workbook access, and the table's data entry permission. Both drafts and published versions require the Edit input tables permission on the account type, per Edit input table data.

You change it with the Editable in label on the table, then publish. Sigma's data entry permission page notes that a table can't take entries in the draft and the published version at the same time.

For a forecast that budget owners fill in, the restricted published option is usually the right one. Owners enter numbers in the published workbook and click Save, and nobody needs edit access to the workbook design.

How do you build an approval workflow on an input table?

Sigma has no approval feature for input tables, so you build one from a status column and an action. The pattern below uses features Sigma documents, but test it with your own teams before relying on it.

1. Keep the Status single-select column from the example. Budget owners set their row to Submitted.
2. Add a table that shows Submitted rows, and a button labeled Approve.
3. On the button, add an Update row(s) action. Target the input table, update the row whose Dept ID matches the selected row, and set Status to Approved.
4. Add a condition to the action sequence with a custom formula such as CurrentUserInTeam("Finance Approvers"), so the update only runs for approvers.
5. Downstream, report only rows where Status = "Approved".

Sigma notes that users who can open a workbook can usually trigger its actions, which is why the condition matters. The edit history column and the audit history view show who changed what and when.

When should you use input tables, and when not?

Use input tables when people add judgment to warehouse data: plans, adjustments, labels, and mappings. Don't use them as a replacement for the system that owns a transaction.

If the edits need to reach other tools, a warehouse view on the input table is the hand-off point. We set this up in Snowflake for teams who want the forecast in the same place as the actuals.

For formulas that compare forecast to actual, the Sigma functions list and the Excel to Sigma functions cheat sheet cover Lookup, SumIf and the rest. To restrict which rows each owner sees, see row-level security in Sigma. The Sigma vs Omni comparison covers how write-back differs between the two.

Frequently asked questions

What to do next

Start with one forecast that already lives in a spreadsheet next to a Sigma dashboard. Build it as a linked input table with a status column, and have one budget owner use it for a cycle. If you want help designing the write schema, permissions and approval step, book a call with me.