How to build a data app: A step-by-step guide

Enterprises need data apps, interfaces that let business users act on live data instead of just looking at it, submitting a forecast, approving a budget line, or correcting a record without leaving the interface. But until engineering has the bandwidth to build one, or the company signs off on a round of custom software development, the work stays where it's always been. Budget approvals continue in email threads and forecasts need to be reconciled across multiple versions of the same spreadsheet.

This guide covers how to build a data app step by step without a custom development project or a slot on the engineering roadmap.

What is a data app?

A data app gives people an interactive way to explore data and carry out data-driven work. It can combine live data, user inputs, and workflow logic in one interface. It lets people act on what they see, submitting a forecast, approving a budget line, correcting a record, or triggering a downstream step, rather than only viewing it, with the result written back to the source.

The difference from a dashboard shows up once someone spots a problem. A legacy BI dashboard only lets people view and analyze data, so fixing anything means stepping outside the tool entirely into an export, edit, and email loop. A data app closes that loop inside the interface: the correction gets captured, written back to the source, and carried through whatever governed, audited workflow comes next, instead of disappearing into an inbox with no shared record of what changed.

Data apps are also increasingly called AI Apps because AI now does more of the work of building and operating them (assembling the interface, wiring the logic, running parts of the workflow after launch) than a human does by hand. Sigma, the runtime layer for analytics, apps, and agents built directly on live data in cloud data warehouses, uses AI App as its branded term for exactly this. The rest of this guide uses Sigma as the working example of how to build one.

What you need to build a data app

Data apps (or AI Apps) generally need three parts working together: a user interface, a connection to trusted data, and logic that moves work forward after an interaction. How each part actually gets built depends on the platform. In Sigma, those three parts map to a workbook for the interface, Input Tables for the data layer, and Sigma Actions for the logic layer.

A workbook for the interface layer

The interface is a workbook, a canvas that combines spreadsheets, charts, forms, buttons, and modals in one document. Built on a familiar spreadsheet interface, it lets the people who run the workflow work in it directly, without learning a separate tool.

Input Tables for the data layer

Input Tables are editable tables inside a workbook that support insert and update operations directly against the warehouse. When a user types a value, submits a form, or edits a record, Sigma writes that change back to the cloud data warehouse and logs it. They are how a data app captures input instead of only displaying output.

Sigma Actions for the logic layer

Sigma Actions are pre-built, no-code interactions you attach to supported UI trigger elements, such as buttons, forms, or images: open a modal, insert a row, update a status, and send a notification. You configure and sequence them through the interface rather than writing custom code; chained together, they define the workflow.

1. Plan the workflow before you build

Whiteboarding the workflow before you open the canvas is the single biggest predictor of whether a build avoids costly rework. Mid-build changes are possible, but they mean re-wiring actions, and that friction compounds fast. Map the process first so the team agrees on roles and routing before configuration begins, rather than automating an inefficient process.

That planning conversation can also happen inside Sigma Assistant's plan mode: chat through what you want to build before committing to anything, then switch to build mode once you're ready to generate it.

Map the roles and handoffs in your workflow

Write the path on one page before opening the canvas. Every workflow has its own version of this sequence: submitting a forecast, correcting a record, routing a request, but an approval workflow is a common enough pattern to use as a concrete example:

• Submit: who enters the initial request or data
• Review: who checks it before a decision gets made
• Approve or reject: who has authority to decide, and under what conditions
• Close: who confirms the workflow is complete and logs the outcome

Name the role and what they need to see at each step, and record what that role can decide. Assign one accountable approver to each decision point, and distinguish approving, requesting changes, and editing as three separate permissions where your workflow needs that distinction. Decide during planning whether steps run in sequence or in parallel.

Decide data permissions before you build, not after

Permissions determine what data the app reads, what each role sees in every chart and Input Table, and which actions are safe to expose. Changing them after the data app is built requires re-scoping data models, re-testing every view against each role, and often rewriting actions that assumed broader access than a role should have. The rework compounds because permissions touch every layer of the app at once, and mistakes here can leak salary data to peers or expose customer records to the wrong team.

Decide which roles see which rows before the first chart exists, and define those rules in the warehouse itself through row-level access controls. Sigma inherits those controls at query time, while Sigma roles and workbook-level grants control who can access the app.

2. Start with Sigma Assistant or a template

If you're building your AI App in Sigma, two starting points can put a working draft on the canvas before you wire anything by hand: Sigma Assistant or a template.

Sigma Assistant builds from a natural language description

Describe the app you want, and Build with Sigma Assistant selects the data sources, prepares the data, builds the components (charts, tables, KPIs, Input Tables, and actions), and positions them on the canvas. It works one-shot or turn by turn, and the output consists of Sigma workbook elements you can inspect and edit. Prompt-to-app building by citizen developers can create quality risks when generated code isn't validated against business rules, so map the workflow first, then generate.

Templates with actions already wired

Templates start you from a working app with layout and actions already connected, covering common use cases such as revenue forecasting, project management, territory management, and marketing analytics. Swap in your own warehouse tables, adjust statuses and routing to match the workflow you mapped, and move on to testing. Either starting point still follows the same steps.

3. Connect a data source

Next, connect the app to your warehouse. Until this happens, everything on the canvas is a read-only mockup.

Read and write access to warehouse tables

Connect Sigma to the warehouse where the data already lives, such as Databricks, Snowflake, BigQuery, or Amazon Redshift. Read access powers queries, which Sigma pushes down to run inside the warehouse against live data, so the app always reflects the current source of truth rather than an extracted or cached copy. Write access gives Input Tables a destination: New records land in a separate schema without deleting or overwriting original warehouse data.

Connect data to make the app live

A connection turns a workbook mockup into a live experience. Because Sigma pushes queries down to run inside the warehouse rather than pulling data out, the app reads the same rows the warehouse holds at that moment, and the writeback lands in a schema the warehouse governs alongside the source data.

Before building further, confirm both directions of the connection actually work: run a query against a live table and check that the result matches what's currently in the warehouse, then submit a test change through an Input Table and verify it persists as a new row users with the right permissions can see.

4. Build an Input Table

Once the connection is live, the next step is giving people a way to write back to it. This pivot point moves the app from read-only analytics into a working application.

The shift from read-only to interactive

Adding an Input Table is the moment the app crosses from viewing into doing. A controller enters flux commentary, an analyst saves a forecast scenario, an operations lead corrects a mapping, and each entry writes back to the warehouse where downstream queries can use it. Under the hood, an Input Table supports the three operations users expect from a spreadsheet: insert a new row, update an existing one, and delete one that shouldn't be there. Sigma applies each one directly against the warehouse table.

Review the audit trail for row changes

Every write is captured with the original record, the new record, who made the change, and when. Input Table audit history exposes that row-level detail and also records versioned snapshots of row and schema changes over time, though it doesn't capture changes to column names. Builders decide what end users see, so they can expose, hide, or layer the log with conditional rules. For teams answering to auditors, expose that history so they can reconstruct changes without relying on a spreadsheet.

Sigma Tables for writeback across multiple workbooks

A single Input Table only accepts writes from the workbook that created it, which works well until multiple teams need to share and write back to the same underlying table without maintaining disconnected copies. Sigma Tables extend the same writeback model, including the spreadsheet interface, warehouse-native storage, and inherited permissions, so any number of workbooks can read from and write back to the same table with the right permissions.

A finance team entering headcount targets in one app, a customer success team annotating account risk in a second, and an operations team managing exceptions in a third can all write to the same underlying table instead of three disconnected copies.

Because a Sigma Table is a flat table in the warehouse, external systems can also read and write to it directly using standard database operations, so an upstream service or a scheduled job can update the same table a Sigma app reads from.

5. Wire actions to complete the workflow

When you're building in Sigma, actions define what happens when someone interacts with the app. Pre-built, no-code Sigma Actions attach to UI trigger elements like buttons, forms, and images, and you configure them through the interface:

• A button opens a modal for click-to-detail
• A submission inserts a row and sets a status
• A condition trigger fires an email or Slack notification when inventory drops below a defined threshold

Chain these actions together to run the workflow you whiteboarded earlier. One sequence can capture a submission and route it to the approver; another can record the decision, update the status, and alert the submitter. Because you settled the routing during planning, this step becomes assembly rather than design. And because no action is code, an engineer isn't on the critical path to ship the app.

6. Confirm your app is production-ready

Before handing an app to a team, review it against four practical criteria:

Treat any unresolved item in this table as a launch blocker rather than a follow-up task.

7. Roll out your data app to the team

A production-ready app isn't the same as a fully adopted one. Start with a small pilot group, ideally the people who will use the app most and can spot a broken workflow quickly, rather than rolling access out to everyone at once. Watch how they actually use the app against the workflow you mapped: which fields get skipped, which approvals stall, and which steps people work around instead of using as designed.

Fix what the pilot surfaces before expanding access, since a pilot limits support demands before department-wide rollout. Once the workflow holds up, widen access in stages, department by department or region by region, so any remaining issue shows up in a small group instead of all at once.

Expand the functionality of your AI App with Sigma Agents

Once an app is live, Sigma Agents can add scoped agentic workflows without another full build cycle.

Sigma Agents extend what an app can do after launch

A live AI App can grow through configured agentic workflows. Sigma Agents are scoped workflows a builder configures inside the workbook: plain-English instructions, data access inherited from the workbook's existing security model, and a defined set of actions the agent may run. In a customer feedback app, for instance, an agent can report sentiment trends, flag a slipping average rating, and write the recommendations a user selects back to an Input Table as prioritized to-dos.

Human-in-the-loop or autonomous, depending on the workflow

Agents support three interaction modes. Conversational agents answer and explore when asked. Human-in-the-loop agents propose, and the user approves before anything is written or sent, which fits approvals and policy checks. Autonomous agents run work on the user's behalf, including on a schedule, such as summarizing forecast changes before a recurring review. In each mode, the work begins with human instruction: The agent carries forward a goal a person set and runs unattended only because a builder configured it to.

Best practices when building AI Apps

A handful of practices separate the data apps that ship cleanly from the ones that stall in rework. Use this as a quick pre-flight before you start, and again before you hand the app to a team:

• Whiteboard the workflow before you configure anything. Map the roles and handoffs in your workflow, and the routing between them, on one page before you open the canvas. Mid-build changes mean rewiring logic that already assumed the old routing, and that friction compounds fast.
• Set data permissions before the first chart exists. Decide which roles see which rows at the source, and define those rules in the warehouse itself rather than in a separate layer on top. Retrofitting permissions later touches every part of the app at once and is where sensitive data most often leaks.
• Verify the data connection in both directions. Before building further, confirm a live query returns current results from the source and that a test write persists as a new row visible to users with the right permissions. Silent failures on either side are much harder to catch once real workflows are running through the app.
• Treat production-readiness criteria as launch blockers. Any unresolved item across appearance, workflow correctness, performance, and permissions should hold the launch rather than become a follow-up task. Apps that ship with known gaps rarely get those gaps closed once users are working around them.
• Roll out to a pilot before the whole team. A small group of users who know the workflow surfaces the fields they skip and the approvals that stall. Fixing those in a pilot is far cheaper than fixing them after a department-wide rollout is already underway.

Treat these as the discipline that makes the seven build steps hold together, not as a separate checklist. The teams that ship data apps quickly are the ones that plan the workflow, lock down permissions, verify the connection, honor their launch criteria, and pilot before they scale, in that order.

Launch an AI App with Sigma

The next workflow worth building is the one still running through a spreadsheet or email thread today. You already know its submitters, reviewers, and failure points, which makes it a strong first candidate for this build. Because Sigma runs directly on the warehouse you already govern, the app inherits your security from the first query and moves from question to action on one platform.

Get a demo or try Sigma free and put that workflow into production.

Frequently asked questions about building a data app

How do you build a data app from scratch?

Start with a one-page map of the workflow, including roles, routing, and data access. Then connect read and write access to your data source, add a way for people to submit or edit data, configure the actions that move the workflow forward, and test the app before handing it over. In Sigma, that means connecting your warehouse, adding an Input Table, and configuring Sigma Actions, and you can generate a first draft by describing the app to Sigma Assistant.

What do you need before you can build a data app?

You need a cloud data warehouse holding the data, a platform that provides the interface and writeback, and a one-page map of the workflow covering roles, routing, and data permissions. Use the map to settle routing and security decisions before you start configuring.

Do you need to know how to code to build a data app?

No. Modern data app platforms let you configure an interface, connect data, and wire logic without writing code, using visual configuration instead of custom development. In Sigma, you can configure Input Tables, actions, and modals through the interface, and Sigma Assistant can build a working app from a natural language description.

How is an AI App different from a data app?

A data app is the older industry term for software that combines a live data connection, an interactive interface, and workflow logic. AI App is the newer term for a data app in which AI assistants can help build it, and AI agents can optionally extend it after launch with scoped agentic work such as drafting analysis, flagging anomalies, or routing approvals.