Snowflake application guide
Can you build a customer portal on top of Snowflake?
Yes. Use Snowflake for governed analytical data, then place a server-side application layer in front of it for customer identity, tenant scope, predictable queries, clear freshness and operational workflow.
The direct architecture
Build the portal as a separate application. Authenticate the customer in the application, resolve their organisation and role, and translate the requested task into a bounded server-side query against approved Snowflake views or tables. Return a deliberate customer-facing response, not a copy of the warehouse schema.
Use an application database for users, memberships, permissions, workflow state and support. Use source-system APIs or queues for operational actions. This gives Snowflake one clear role: governed analytical data for customer decisions.
01
Use Snowflake when the customer need matches warehouse strengths
| Customer need | Snowflake fit | Application responsibility |
|---|---|---|
| Integrated history from several systems | Strong | Explain periods, sources and customer meaning |
| Governed measures and trends | Strong | Apply entitlement and present definitions |
| Filtered detail and scheduled exports | Potentially strong | Bound queries, queue large work and secure files |
| Current operational status | Depends on ingestion latency | Combine with a live source API where necessary |
| Immediate transaction | Usually not the primary path | Write to the system that owns the workflow |
If the platform choice is not yet fixed, start with the wider guide to building a portal on top of a data warehouse. Snowflake should support the customer outcome, not define it.
02
Separate warehouse, serving and application responsibilities
Warehouse
Trusted analytical model
Owns integrated history, governed transformations, approved views and refresh evidence.
Data service
Bounded query contract
Uses approved statements, parameters, paging, timeouts, limits and customer scope.
Application
Identity and experience
Owns users, organisations, roles, navigation, response meaning and support.
Operational systems
Business transactions
Accept authorised commands and remain the source of truth for workflow state.
Snowflake documents a REST SQL API and supported drivers for executing statements. These are server-side integration options, not reasons to send warehouse credentials or arbitrary SQL to a customer browser.
03
Apply customer access before every Snowflake query
- Authenticate the user through the portal identity flow.
- Resolve an active organisation membership and permitted role on the server.
- Map the organisation to governed Snowflake customer keys.
- Select an approved query or data contract for the requested task.
- Bind customer keys and other permitted filters as parameters.
- Apply database policies as defence in depth, then minimise the response again in the application.
- Record sensitive exports, permission changes and customer actions.
Snowflake row access policies can determine which rows a query returns. They strengthen the design, but they do not replace portal membership, feature permission, field approval or application-level tests. Review the broader pattern for secure external customer data access.
04
Design a predictable public workload
- Use approved queries or stored data contracts rather than customer-authored SQL.
- Limit date ranges, filter choices, rows, columns, concurrency and execution time.
- Page detail results and generate large exports in background jobs.
- Cache safe, tenant-specific responses where freshness permits.
- Separate interactive portal work from analyst and transformation workloads.
- Monitor query duration, queued work, warehouse consumption, failures and customer-facing latency.
- Show the data cut-off and last successful refresh close to each result.
Test with realistic customers, filters and concurrent traffic. A query that works for an analyst may be too expensive or variable for a public application.
05
Keep customer actions on an operational path
A customer may query a result, upload evidence, acknowledge a variance or approve a next step. Preserve the Snowflake record identifiers, reporting period and visible values with the request, but write the action to the application or operational system that owns it. The guide to adding workflows to customer reporting covers this boundary in more detail.
06
Deliver one secure customer decision first
- Define the customer decision and the service outcome it should improve.
- Confirm source ownership, Snowflake refresh timing and approved customer fields.
- Map portal organisations to warehouse customer keys and test difficult relationships.
- Prototype the highest-risk permission and most expensive representative query.
- Choose the server-side interface, workload limits, caching and export approach.
- Add support, audit, data questions and source-failure states.
- Pilot with representative customers and reconcile outputs before expanding.
Sources
Primary references
Questions
Frequently asked questions
Can Snowflake power a customer portal?
Yes. Snowflake can supply governed analytical data to a customer portal. Keep customer authentication, organisation membership, authorisation, response shaping and workflow in a server-side application layer rather than connecting the browser directly to Snowflake.
Should portal users receive Snowflake credentials?
Normally no. Human portal users should authenticate with the application. A constrained server-side service identity can query approved Snowflake objects after the application has resolved the customer and permitted action.
Is Snowflake the portal database?
Snowflake can own analytical history and reporting data, but the portal still needs an operational store for users, organisations, permissions, workflow state, support and other application concerns.
Can customers take actions from a Snowflake-backed portal?
Yes. Use Snowflake data as context, then send approved actions to the system that owns the operational process through a supported API or queue. Do not treat an analytical query path as the default transactional write path.
When is Snowflake a poor fit for a portal?
It is a poor primary source when the portal mainly needs low-latency operational transactions, the required data is already available from a well-supported source API, or the customer need can be met by a simpler reporting or document solution.
Plan the application layer
Bring the customer need, Snowflake model and operating constraints.
LCR can help define a focused customer-facing application without turning the project into a warehouse replacement or an unrestricted data interface.