Most of what makes a vertical form solution vertical is capture, integration and evidence.
It is the part that changes per customer, per region and per regulation.
Not everything needs to be implemented in Odoo modules.
This paper sets out where that line sits, what the Nova Forms app gives on the far side of it, and four blueprints for solar, construction, field service and signed agreements.
Everything that follows is in the app today, not on a roadmap.
In short:
The same app also covers the everyday cases: customer satisfaction surveys, quotation and service requests, onboarding and calculations among them.
One form design, four contexts: the same form runs in the Odoo backend, on the portal, on the website, or embedded on a third-party site.
An Odoo partner that serves several industries can end up building the same thing again and again: a set of models for each vertical, then a fork of that set for every customer whose intake, checklist or sign-off document differs from the template.
The models are rarely the problem. A work order is a work order. Project tasks, pickings, leads, invoices: Odoo already has all of it, and the semantics are stable across every customer in the vertical. What differs, customer by customer, is the surface where and how reality gets recorded: which 28 fields the roof survey asks, which photo is mandatory before the crew may start, which inverter certificate number the regional grid operator insists on, which of the fourteen checklist items is a legal requirement this year and a recommendation the next, and whether any of it is answered on the website, in the portal or in the Odoo backend.
Put that surface in module(s) and every one of those differences becomes a field, a view override, a migration script and a line in the upgrade budget — repeated across every database under maintenance. The cost is not the first build. It is that the variable part and the stable part are now welded together, so the variable part's churn rate is inherited by the whole thing.
Nova Forms separates them. The capture surface becomes a form design (SurveyJS JSON stored in an Odoo record) that a consultant, or the customer, can change without a deployment. What the form produces stays where it belongs: real Odoo records, created and updated by configured mappings or by a server action the partner controls.
The claim
This does not replace a vertical module. It changes what has to be in it. The module carries the models, the business rules, the automations and the reports that are true for every customer in the industry. The forms carry everything downstream of "what exactly do we ask, and what must be attached" — and that is where the per-customer variance lives.
The dividing question is whether anyone has to be asked to provide a value. If a person supplies it, that is form or data intake, and the form captures it. It stays the intake layer even when the answer has work to do afterwards: a record mapping writes it onto the contact, the order line or the task in the ERP, where it can be summed, invoiced, scheduled or reported on like any other field. Intake and downstream processing are not a choice between two places. Nor does the channel move the line: the same form design runs in the Odoo backend, on the portal, on the website or embedded on a third-party site.
What belongs in a module is what nobody is ever asked: the models those records live in, the constraints that protect them, the business logic that runs on them, and the values the ERP derives for itself. A requirement someone has to answer is intake; one the ERP has to enforce or derive for itself is business logic.
| Signal | Belongs in a module | Belongs in the form layer |
|---|---|---|
| Authorship | Only a developer should ever change it. | A consultant, or a trained key user, should be able to add and change it. |
| Variance | Identical for every customer in the vertical. | Differs per customer, region, subsidy or certification scheme, or type of asset. |
| Lifetime | The concept outlives any particular questionnaire. | The question exists because a regulation, standard or customer asked for it this year. |
| Automation | Drives scheduling, stock, accounting or a deadline that escalates. | Triggers a downstream record when submitted, then stops. |
| Constraints | Needs a database constraint, a unique key, or must not be writable after approval. | Validation is per-submission and per-question; rules change as often as the form does. |
| Aggregation | Values that get summed, grouped or charted across many records: quantities, hours, amounts. | Values read one record at a time: observations, notes, conditions found on site. |
Many of the custom fields added to res.partner, sale.order, sale.order.line or project.task exist only so that something can be asked. Those move into the form. The few that feed logic stay as fields, written by the form's record mapping, so the capture surface still changes without a deployment.
Design it as a one-way door
Start a question in the form layer. If it later turns out that reporting needs it, add the field to the module and populate it from the mapping. Existing submissions already hold the value, so the migration is a backfill, not a re-collection. Going the other way is far more expensive. When in doubt, form first.
Grouped by the questions a solution architect asks.
One design, four rendering contexts. Build once, deploy anywhere it is needed:
Internal users, on the Forms app or bound to a record.
Assigned to a portal user, or selected and filled in by them, with their history and in the company’s own branding.
Drag-and-drop Form block on any page.
Copy-paste snippet on a third-party site.
Technically, rendering happens in an encapsulated DOM rather than an iframe:
The form’s (and form builder’s) markup and styles are encapsulated from the page around it.
So the form designer and form are part of the Odoo page itself (backend, portal, website).
Neither leaks into the other: no resizing, no style collisions with the host site, no cross-origin friction, and the same behaviour in all four contexts.
Public forms get a built-in proof-of-work captcha: no external service, no cookies, invisible to the visitor, verified server-side.
The ETL interface generates a model, table, views and menu from a form design and loads submissions into it as ordinary records that can be queried, exported and reached by any BI tool. Useful for trend reporting across many submissions of the same form.
Why not the Survey app, or Studio?
Neither carries the question types this work needs (signature, file upload, image marker, repeating matrices and panels), which on its own rules them out for evidence capture. Thirty-plus against nine, each one wired to Odoo through the field APIs: an image picker that lists a product’s own images for one or several to be chosen, a dropdown filtered against live records, a rating or slider whose value maps onto a field like any other.
Survey is built for questionnaires: nine question types, all of them choice, text, number, date, scale or matrix. Choices are typed into the survey, so a dropdown cannot show live products, contacts or assets, and logic is display-only: a question appears because an earlier answer was picked, with no calculated values and no API-driven rules.
Nor is a survey an artefact you ship. A submission links to a contact, but beyond saving an answer as the respondent’s email or nickname, nothing writes answers onto that contact, a task or an asset; they stay in the survey’s own tables. And there is no pack to version alongside the module and import into the next customer’s database, which is the whole of §04.
Studio is the module side of the §02 line: every question becomes a field and a view change in that database. It is not the tool for extensive logic, and each customisation is weight carried into the next Odoo upgrade. Right for what the ERP must enforce or derive; wrong for the twenty-eight questions a roof survey asks this year.
Export and import are what turn "we use forms" into a repeatable product. Nova Forms exports form builders and their surrounding configuration, and imports them into another database. That gives an owned template repository and/or reference database, and a distributable artefact.
The vertical pack is built and maintained once, in the partner’s own template repository and/or reference database.
Builders plus their settings, actions and translations, in one export.
Commit the pack, alongside the vertical module if there is one. It is the form-layer release.
Into the customer database, then adapt on site without a deployment.
The practical shape of a vertical release is therefore standard Odoo, extended by a vertical module where the vertical needs one, with the form pack on top. A module carries what must be code: models, groups, master data, reports and automations. The pack is the capture surface. Odoo and the module, where there is one, form the contract; the pack is what plugs into it.
Set the customisation policy on day one
Once a customer edits an imported builder, a later re-import needs a decision each time. Agree upfront which builders the partner updates and which the customer owns; ship the customer-owned ones as starting points and keep the maintained set separate. This is a governance choice, and the cheapest time to make it is before the first go-live.
The vertical with a high ratio of capture to transaction: every installation is a survey, a design, a permission, an execution and a certificate, and almost all of it is evidence that must be kept and produced on demand.
| Form | Runs in | Becomes / updates in Odoo | Relies on |
|---|---|---|---|
| Rooftop intake | Website + embedded | Contact and CRM lead, with roof type, consumption and address prefilled onto the lead. | Record mapping · CRM & contacts · website form block |
| Site survey | Backend / portal, on a tablet | Attached to the lead; one row per roof plane (orientation, pitch, area) as One2many children. | Record mapping · image marker |
| Electrical & meter check | Backend | Photos of the meter cabinet and the main fuse rating, stored with the survey. | File upload |
| System configurator | Portal | Quotation lines: panel, inverter and mounting filtered by the Domain API, prices updated by the Change API. | Domain & change APIs · sales integration |
| Grid-connection application | Backend | PDF in the operator's required layout, prefilled from the contact and installation address, emailed on submit. | Prefill API · PDF generation |
| Installation checklist | Portal, per crew | Closes the task; string layout as a dynamic matrix; panel and inverter serials passed to a server action. | Dynamic matrix · projects & inventory |
| Commissioning report | Portal | Test values plus technician and customer signature; a certificate PDF emailed and archived. | Signature · PDF generation |
| Annual O&M inspection | Portal | Scheduled by reminder rule; a failed check opens a helpdesk ticket. | Reminder rules · helpdesk |
stock.lot, not only into the submission JSON.Here the driver is not efficiency but defensibility. Safety and quality records must exist, be timestamped, carry evidence, and be producible years later. The failure mode of a paper or spreadsheet process is not slowness. It is a record nobody can find or interpret well.
| Form | Runs in | Becomes / updates in Odoo | Relies on |
|---|---|---|---|
| Work request / RFQ | Website + embedded | Lead or draft quotation, with scope, site address and desired dates. | Record mapping · CRM & sales |
| Subcontractor onboarding | Portal | Contact plus certificates and insurance as attachments; reminder rules chase expiry. | File upload · reminder rules · contacts |
| Start-of-shift risk check (LMRA) | Portal, phone | Logged against the task; a flagged hazard makes an evidence photo mandatory and raises a blocking activity. | Conditional logic · projects |
| Toolbox talk | Portal | One row per attendee in a dynamic panel, each with its own signature. | Dynamic panel · signature · PDF generation |
| Quality inspection round | Portal, tablet | Observations pinned on the floor plan with the image marker; each becomes a task with a photo. | Image marker · record mapping · projects |
| Snag / punch list | Portal, client-visible | One task per snag; closing requires an evidence photo; the client sees status in their portal. | Dynamic panel · portal · projects |
| Site delivery note | Portal | Confirms or corrects a receipt, with damage photos, and validates the picking. | File upload · inventory |
| Handover certificate | Portal | Client signature, reservations list and a countersigned PDF stored on the project. | Signature · PDF generation |
0 to keep them indefinitely.Field service sits across verticals: the solar installer and the contractor both end up here once the asset is theirs to maintain. What is distinctive is recurrence against an asset: the same checklist, at intervals, over a fleet of installations, where the value is in the comparison across visits.
| Form | Runs in | Becomes / updates in Odoo | Relies on |
|---|---|---|---|
| Asset condition checklist | Portal, phone | Bound to the asset record; identification, location and last-visit data prefilled by the Prefill API. | Prefill API · form bound to a record |
| Periodic inspection | Portal | Issued on an interval by reminder rule with its mail template; completion closes the cycle. | Reminder rules · mail templates |
| Defect report | Portal + public | Helpdesk ticket with severity, fault photos and the asset reference. | Reminder rules · helpdesk |
| Measurement round | Portal | Readings as dynamic matrix rows, mapped to child records so values can be compared visit over visit. | Dynamic matrix · record mapping |
| Customer sign-off | Portal, at the door | Signature and work summary; service report PDF emailed on submit. | Signature · PDF generation |
| Warranty / RMA intake | Website + portal | Ticket with proof of purchase and fault description; captcha on the public form. | Reminder rules · helpdesk |
This is a pattern that spans industries, and the one that most often gets built twice: the deliverable is a signed legal document whose contents only the customer can supply. A signature is worth little if the details in the document were typed by somebody guessing, so capture and signing have to be one unbroken chain: from a known person, through a form, into the agreement they sign.
A provider takes a vehicle or a device under a legal service agreement. The provider knows who the customer is and what the terms say. It does not know the registration plate, the VIN or serial number, the odometer or usage reading, or the condition of the item on the day it is taken on. Those come from the customer, and they have to appear verbatim in the agreement, because they are what defines the item the agreement covers.
| Step | Runs in | Becomes / updates in Odoo | Relies on |
|---|---|---|---|
| Portal invitation | Backend | A name and an email address are what's necessary. A wizard (eg by automation rule) does the rest: the invitation, the sign-up or log-in, and the landing on the assigned form. | Portal (form) invitation wizard · automation rule |
| Registration form | Portal | Name and address arrive already filled from the contact. Plate, VIN or serial and other details are captured, and the record mapping creates the fleet.vehicle record from them. | Prefill API · record mapping |
| Condition evidence | Portal | Photos and documents kept with the submission, timestamped against a known user. | File upload |
| Signature request | On submit | The agreement (sign document request) is created and the customer lands on it. It's raised with its placeholders filled from the submission and other records, ready to sign. | Odoo Sign · Forms integration |
| Signed agreement | Odoo Sign | The executed document filed against the contact and the registered item; the form submission stays as the record of what was asked and answered. | Odoo Sign |
Which other branches the same pack shape fits is better answered by a shape than by a list of industries, because a shape can be held against a branch already in the portfolio. It fits when four things are true at once: capture is regulated and must be evidenced; it recurs against a physical asset or site; the exact questions vary by region, by which subsidy or certification rules apply, and by which version of those rules is current; and the result has to end up as a record, not a PDF in a folder.
Every blueprint above matches it. So do these, starting with the branches closest to those blueprints:
Site qualification, grid-capacity survey, installation and commissioning, periodic safety inspection.
The same crews, the same customers and the same certificate-driven paperwork as solar, so most of the pack shape carries over unchanged.
Pre-installation survey, noise and placement declaration, subsidy dossier, commissioning record.
A national subsidy scheme is a form with mandatory evidence attached, and it is rewritten every year or two — churn the form layer absorbs without a deployment.
Safety dossiers, commissioning protocols, grid-operator submissions, periodic checks.
Young enough that the paperwork is still changing shape, which favours a configurable capture layer over a fixed data model.
Periodic legal inspections (electrical safety, fire systems, lifting equipment, refrigerant handling) ending in an issued certificate.
Their entire product is a completed form and the document it produces. Portal, reminder rules and PDF generation cover the process almost end to end.
Recurring non-financial data collection from sites, subsidiaries and suppliers.
Multilingual, portal-based, chased on an interval, and landing as records instead of returned spreadsheets. The reporting standards change annually: the same argument as subsidies, at group scale.
Condition surveys and tenant intake; farm and food-safety audits; sampling and permit-compliance rounds.
Different words, identical mechanics: a recurring evidenced checklist against an asset, under a standard someone else revises.
Whether that reads as six vertical products or as one delivery capability (a template repository or reference database, a pack format, a mapping convention and a review discipline) pointed at one branch after another is a judgement each partner makes on its own portfolio. Either way, the machinery and the method carry across; the domain knowledge does not, and that is where the real cost of a vertical sits. The saving on a second branch is that the delivery layer does not have to be rebuilt; the forms still have to be written.
Scoping goes wrong when a capable tool is assumed to be an unlimited one. These are the boundaries to put in the estimate, before they turn up in the retrospective:
Two things are worth having ready for a customer's IT or compliance review, because they are unusual enough to be asked about. First, data location and portability: designs and submissions are stored as standard SurveyJS JSON in the customer's own Odoo database, with no external form service, no third-party processor in the submission path, and a documented exit to any SurveyJS-based stack. Second, the public-form posture: for example, the captcha is proof-of-work with no external calls, no cookies and WCAG 2.2 AA behaviour; uploaded images are validated by decoding them rather than by trusting a filename or declared type, with SVG refused outright; and rich text is stored as a validated document tree against an explicit allow-list rather than sanitised HTML.
Three decisions a first engagement makes, deliberately or by default. The order below is the one we see most often, not a method to follow.
A demo shows more than words. The introduction video and the screenshots on the Odoo Apps Store, both linked below, give a first impression; a walkthrough demonstrates the capabilities and answers the questions this document cannot.
I recommend working through every consideration and implementation point in this paper together. Take a simple process you have planned, are building or already deliver, and walk it through. It is worth the time.