Sigma's write-back capabilities have made a new category of warehouse-native applications possible: forecasting tools, approval workflows, operational trackers, and lightweight CRMs built directly on top of your data platform, without stitching together external tools or moving data somewhere else just to edit it.
For most teams it starts simply. One input table, one workflow, a small group of users. Clean, fast, easy to get off the ground. The problem is what happens next.
The moment users can create, edit, approve, or delete records, you're no longer building a dashboard. You're building an application. Dashboards consume data. Applications create and modify it. Where a dashboard prioritizes insights, an application has to prioritize governance, validation, auditability, and reliability. The data coming out of it is only as trustworthy as the process that put it there.
Six months in, that simple input table is often supporting multiple teams, feeding operational reports, and sitting at the centre of approval processes no one originally planned for. This is where the sequencing mistake tends to surface. Most teams design around the interface rather than the underlying process. Sigma makes it fast to get something working, which is genuinely valuable, but the interface is the easy part. The data model underneath it is what determines whether the application can grow, and it's much harder to change after the fact than the interface is.
Before opening a workbook, it's worth sitting with a few questions:
- Will multiple users be updating the same records, and how should conflicts be handled?
- Does the process require an audit trail, or will knowing the current state be enough?
- Could additional approval steps be introduced as the workflow matures?
- Will this data be consumed outside Sigma, in reports, pipelines, or downstream systems?
- Is there any reason to expect this workflow to expand beyond its initial scope?
There are no universally right answers. But asking them early changes the decisions you make about table structure, storage patterns, validation, and how users interact with the data. The goal isn't to over-engineer something simple. It's to avoid building something you'll need to tear down.
This guide works through important decisions that will be guided by your answers to the questions above. Each is framed as a choice, not a prescription, because the right answer depends on your workflow, your users, and how much the process is likely to evolve:
- Table type - Empty input table vs. linked input table, and what that means for key management and record creation
- Storage pattern - Append vs. overwrite, and when history matters
- Data model structure - Normalized vs. denormalized, and the trade-offs for long-term maintenance
- User interaction mode - Direct entry vs. form-based updates, and when each is the right fit
Design Decision 1: Empty Input Table vs. Linked Input Table
The first decision shapes everything that follows: what kind of records are you storing, and where do they come from?
With an empty input table, users create and manage records from scratch. There are no built-in controls around record creation, duplicate prevention, or key management, which makes them flexible, but the governance burden sits entirely with the developer. That means building in validation deliberately, because the table itself won't enforce it.
Designing that validation requires careful consideration. Validation needs to be built explicitly, typically through form-based actions and conditional logic. Design decision 4 covers the options for doing that in more detail.
Empty input tables are the right choice when:
- Users are creating records that don't exist anywhere else
- You're capturing transactions, logging events, or building something net new
- Requirements are uncertain and you need room to adapt
Linked input tables start with an existing parent dataset, and users provide information tied to those records. The parent dataset defines the keys, and you can't change them after creation. That sounds like a constraint, but it's also a feature: users can't accidentally create orphan records, and keys stay synchronized with the source dataset automatically. They're well suited to enriching existing records, like adding a forecast override against an account that already exists in your CRM data or annotating a transaction that lives in the warehouse.
Where they fall short:
- History matters. Linked input tables only support overwrite actions, meaning you can update a record but can't preserve what it looked like before. That rules them out for approval workflows or any use case where the trail of changes has business value. The workaround is a separate empty input table with an append action, though it adds setup overhead.
- The key structure may change. If the parent dataset is likely to evolve, or future workflows might need records outside its scope, the structural dependency becomes a liability.
Design Decision 2: Append vs. Overwrite
Once you know what you're storing, the next question is how it should change over time. The choice is between two approaches: append, where each update adds a new row, and overwrite, where each update replaces the existing one. Both are valid. The question is which one matches how your workflow actually behaves.
Append is the right default when history matters. If your workflow involves multiple states, an audit trail, or any chance that two users might update the same record at the same time, append gives you a safety net. Every change is preserved as a timestamped event, which makes debugging easier, compliance simpler, and rollbacks possible. If you're unsure whether history will matter, lean toward append.
Overwrite makes more sense when the current state is all that matters. Configuration values, operational parameters, or any setting where previous values have no business relevance are good candidates. It's simpler to work with and easier to query, and for the right use case there's no reason to reach for append.
The practical difference becomes clear when you look at how each approach handles a workflow. The instinct is often to track status with separate fields: Is Submitted, Is Approved, Is Rejected. But that produces impossible combinations and gets harder to extend as the process grows. A cleaner approach is a single state field that moves through defined stages:
Draft → Submitted → Under Review → Approved
With overwrite, you update that field in place. You always know the current state, but you lose the trail of how you got there:
With append, each transition becomes its own row: a business event with a timestamp and an owner.
Reporting, validation, and permissions all get simpler as a result, and when the process changes, adding a new stage or routing rule is straightforward rather than a redesign.
One thing worth checking before you build: Sigma already versions write-back activity behind the scenes, so basic historical states can be reconstructed through the audit log. For lightweight workflows that may be enough. For anything requiring reviewer comments, decision rationale, or a clear escalation trail, appending those details as part of the record rather than relying on Sigma’s native log is worth the extra effort.
Design Decision 3: Normalized vs. Denormalized
How you structure the data itself has long-term consequences that aren't always obvious when you're building the first version.
A useful rule of thumb: normalize reference data, and store only user-generated facts. Reference data is anything that already exists elsewhere, like account names, regions, or product codes. User-generated facts are the values your workflow produces like approvals, requests, or status updates.
A normalized design separates those two things. The reference data lives in the data platform, and the input table stores only the values users contribute. The two are joined downstream to build the reporting view, keeping the storage layer clean and the reporting layer flexible.
Take a forecast override workflow. The account data already exists, so you just need to store the number the user entered against the right account ID.
Reference Data:
Input Table:
Account information stays centralized, and every report reads from the same record. If Acme Ltd moves from EMEA to APAC, that change propagates everywhere without touching the input table. The trade-off is that it requires joining tables to produce your reporting view, which takes a little more setup. That's worth it, though: if the data already exists elsewhere, there's no reason to duplicate it.
A denormalized design stores everything in one place:
It's simpler to build, easier to read at a glance, and a reasonable starting point for prototypes or short-lived solutions. The problem is what happens as the application grows: reference data goes stale, the same fact appears in multiple places with different values, and reconciliation becomes expensive.
The one case where denormalization makes sense deliberately is point-in-time snapshots, where you want to preserve the value as it existed at the moment of entry: a contract price, a quoted rate, an approval decision. That's a deliberate choice, not a default.
Design Decision 4: Direct Entry vs. Form Based Updates
The final decision is about how users interact with the data, and it's one where the right answer often runs counter to what feels most intuitive.
Direct entry optimizes for convenience. Form-based updates optimize for control and governance. Neither goal is wrong. They just pull in different directions, and the right balance depends on your users and your use case.
Direct entry lets users edit the input table directly, with a spreadsheet-like experience that feels immediately familiar. It's a natural fit for bulk editing and copy-paste workflows. The limitations emerge quickly in more complex scenarios:
- Validation is limited. There's no natural place to enforce conditional rules or check that field combinations make sense before a value is written.
- Filters affect downstream references. Filters applied to a direct-entry input table at publish time flow through to all downstream references, including Sigma Warehouse Views (the connection point between your input table and the data platform), which can produce surprising behaviour.
- Concurrency is invisible. When two users update the same record at a similar time, the last write wins with no visibility into the conflict.
Form-based updates handle these scenarios considerably better. Updates go through defined action sequences, giving you a natural checkpoint for validation before anything is written. Dropdowns can pull values from any Sigma data element, for example, a status field that only shows valid next states based on the current record. If a request is Under Review, only Approved and Rejected appear as options. That kind of conditional logic isn't possible to enforce in direct entry.
The trade-off is that forms take more effort to set up. For simple, low-stakes use cases, that overhead isn't always worth it. But for anything in production or used by multiple teams, form-based updates are much easier to extend over time.
One principle that applies regardless of which approach you choose: every free-text field eventually becomes a data quality problem. Wherever reference data exists, use dropdowns and validated selections rather than free-form text.
Final thoughts
The four decisions in this guide all come back to the same underlying question: are you building something that can absorb change, or something you'll need to replace?
It's a different question from "how do I let users edit this table?" One that asks you to think about the process, not just the interface.
The write-back applications that last are designed for what comes next. Not because anyone predicted every change, but because the underlying model was flexible enough to absorb them. Invest time upfront in data modelling, workflow design, validation, and governance. The result is a write-back application that's easier to extend, easier to maintain, easier to trust, and ultimately one that doesn't require a full redesign every time the business evolves.
Sigma's write-back capabilities are also continuing to evolve. Features like Sigma Tables and bulk inserts are expanding what's possible, and the patterns for error handling, governance, and more advanced workflows will develop alongside them. We'll be covering those in future posts. But the foundation stays the same. A well-designed data model gives you the flexibility to take advantage of new capabilities as they arrive, without needing to rebuild from scratch every time the platform moves forward.
Further reading
New to write-back in Sigma? These docs are a good place to start:
- Input tables overview
- Actions and form-based updates
- Input table audit history
- Sigma Warehouse Views
.png)
