Sitecore Forms is great for straightforward data capture i.e. contact forms, simple surveys, basic lead generation. For anything more sophisticated like securely handling submitted data, integrating with backend systems, or supporting multi-step logic driven by real-time external data the platform is designed to work alongside a purpose-built data layer rather than handling it all natively.
That's a deliberate architecture choice, and it opens up more flexibility than a one-size-fits-all form builder ever could. Understanding how that layer works and how to design it well is one of the most practical (and valuable) pieces of architecture work.
That single design choice has a flow-on effect: anything beyond a basic contact form now needs an external layer to receive, process, and route the data whether that's a simple email notification, a connection to a CRM, or a fully custom system handling complex, multi-source lookups.
For most organisations, this only becomes visible the first time a form needs to do something more than "collect a name and email and send a notification." That's usually the moment a project either stalls or gets designed properly.
Not every form needs the same level of engineering. In our experience delivering complex, high-volume digital platforms, form requirements typically fall into three tiers:
1. Simple marketing forms
Contact-us forms, basic surveys, newsletter sign-ups. Sitecore Forms handles these natively, provided there's a lightweight solution usually email-based for what happens to the data after submission, since it can't be stored against the form itself.
2. Mid-complexity forms
Forms that need some logic or a single external integration, routing to a specific team, conditional fields, or a straightforward API connection. These sit between "native" and "fully bespoke," and the right call is often a hybrid: Sitecore Forms as the front end, with a purpose-built integration layer behind it.
3. Fully bespoke forms
Forms that depend on complex, real-time data, remote lookups, multi-step journeys, or data drawn from several systems at once. These need a custom-built solution from the ground up, designed specifically around the data and journey requirements, not retrofitted onto a form builder.
Knowing which tier a requirement sits in (before development starts) is what keeps a project on time and on budget. Treating a Tier 3 requirement as a Tier 1 form is a common and expensive mistake.
Ausgrid, the largest electricity distributor on Australia's east coast, needed a public-facing outage map and reporting system. The need was simple but critical: when the power goes out, people need to know it's already been reported, and when it's expected back.
The form itself needed to handle real-time data and route these reports to the correct team matching a reported location to live network data and getting it in front of the people who could act on it.
The solution required three distinct layers:
Bespoke, custom-built forms for outage reporting itself: handling complex journeys with remote data lookups (matching a reported address or fault to live network data) and mapping integrations. This tier was built entirely outside the native form tooling, because the underlying data requirements demanded it.
Standard marketing forms for simpler needs: general contact-us and survey-style submissions - handled through conventional form tooling with a secure email-based delivery solution, since submission data isn't stored natively.
A middle layer: sitting between the two, for submissions that needed more structure than a basic contact form but didn't require the full bespoke build.
The result was a system where the highest-value, highest-complexity component received the bulk of the design, QA, and testing investment, while simpler content and forms across the rest of the site were delivered efficiently using standard components. Getting that split right, early, was the difference between an outage map that genuinely worked under real-world load and one that looked fine in a demo.
If your organisation knows it has form requirements beyond basic contact capture, the questions worth answering early are:
- Does this form need to store or reference data beyond the initial submission?
- Does it depend on real-time data from another system?
- Does the journey branch based on external inputs, not just user selections?
A "yes" to any of these means the requirement sits in Tier 2 or 3, and the data and integration layer needs to be designed deliberately not assumed to be a configuration exercise inside the form builder.
If your team is scoping forms that need to do more than capture basic information and needs a more complex solution like real-time lookups, multi-step logic, or integration with existing systems, getting the data layer architecture right early is important.
Get in touch with Switch to talk through your requirements and keep your workflow moving forward.
Can Sitecore Forms store submission data natively in SitecoreAI?
No. SitecoreAI Forms uses a fire-and-forget architecture: submitted data is sent directly to a configured webhook and isn't saved in SitecoreAI or any other Sitecore system. The only exception is uploaded files, which are held temporarily and encrypted, then deleted immediately after successful webhook delivery (or within an hour to 24 hours otherwise, depending on submission status). Organisations need an external layer, at minimum an email-based solution, or a connection to a CRM or custom system to capture and process submitted data.
When does a form need a custom-built solution instead of Sitecore Forms?
When it depends on real-time data from another system, involves multi-step logic driven by external inputs, or needs secure handling of data that can't simply be emailed. Ausgrid's outage reporting system is an example: it required live network data lookups that a standard form couldn't support.
Is this a limitation common across headless SaaS CMS platforms?
It's common across headless SaaS platforms generally. Removing native data storage from the CMS layer is a deliberate architectural choice in the shift to composable, API-first systems; it just means the integration and data layer has to be planned as part of the project.
Subscribe for the latest news and events from our talented team and community network.