Every school runs on forms. Admission enquiries, leave applications, field trip consent, bonafide certificate requests, staff leave. Most are collected on paper, or on a general purpose form tool that has never heard of a class list, and then typed back into the school's records by somebody who had four other things to finish today.
The typing is only half the cost. The other half is everything around the form. It has to open when the circular goes out and close when the deadline passes, and reach parents of one section and nobody else. And when responses arrive, "8A", "VIII A" and "8-A" all get reconciled by hand, because a text box labelled "Class" collects text, not classes.
The ScolaOS forms builder addresses that whole shape of the problem. There are two ways to start a form, a template or the AI designer, plus controls that apply once it exists.
Start from a template
The fastest path is not to author anything. The builder includes a small gallery of ready made forms:
- Student Admission Enquiry
- Student Leave Application
- Parent Consent - Field Trip
- Bonafide Certificate Request
- Employee Leave Request
These are seeded at the platform level rather than copied into each school's data, so every school sees the same gallery without a duplicate set in its own records. The seeding is idempotent, keyed on the template name and its platform scope, so a later improvement updates a template in place instead of adding near duplicates to everyone's gallery.
The set is intentionally small: a high value starter set rather than the full catalogue. It covers the forms almost every school runs, and is not a library you shop in.
A copy is a copy, never a link
Selecting a template does not attach your form to it. It deep copies it: section identifiers are regenerated, every field is repointed at the new sections, and the result is an ordinary form of your own. Your copy is never linked back to the template it came from, so editing the template, or a later update to the seeded version, cannot reach into forms already created from it. That is the difference between a template and a shared dependency, and a shared dependency is convenient until someone tidies up the master copy and three live consent forms change shape underneath the parents filling them in.
Templates that know your school
The genuinely smart part is what the fields are made of. The templates use school entity field types, so a field for a student is a student field and a field for a class is a class field, each binding to your records rather than accepting free text. A general purpose form tool's template gives you a text box labelled "Student". This one gives you the actual student. That difference decides whether a leave application matches a record automatically or has to be matched by name, with all the guesswork that implies in a school with three children called Aarav in the same grade.
Or start from the AI designer
Some forms have no template, and building a long one by hand is dull work. A transport consent form with twenty five fields, three conditional branches and two pages (illustrative) is a lot of clicking.
So "describe it and we will build it" lands well, right up until you think about a form that is already live, already collecting parent consent, already linked from a circular that went out on Monday. An assistant that can quietly rewrite or republish that form is a worse problem than the clicking ever was. The AI Form Designer was built around that second concern first.
Three gates, and you can stop at any of them
The designer is a wizard with three stages, and nothing carries forward without you moving it.
Requirements. Not a blank prompt box. A structured input: the form's name and description, its purpose, audience, category, the groups of information to collect, the features you want, a complexity setting and a notes field. The options come from the server rather than the browser, so what you are offered reflects what the builder can render.
Analysis. Before anything is generated, you get back a statement of what was understood and what is intended. If the interpretation is wrong, the cheapest place to find out is here, before a single field exists.
Generation. Only after you approve the analysis does the designer produce a form structure, handed to the normal builder as a draft for you to edit.
Each stage is a stopping point. You can read the analysis, decide it has misread "guardian" as "parent" in a way that matters for your school, change the requirements, and never spend anything on generation.
The guardrails on the AI
Three rules hold regardless of what any model returns.
The AI never writes a form
Nothing in the AI path writes a form or a form version. Generation returns a structure you review, and persisting it goes through the same save draft path any manually built form uses, triggered by you.
The consequence matters to anyone responsible for live forms: the AI can never publish, overwrite or delete a form. There is no code path by which it does so. A live form stays as it is unless a person with the right permission changes it in the builder.
Every model call goes down one path
All model calls run through a single execution function that owns provider routing, token accounting, credit deduction and the request log. No part of the feature talks to the configured provider directly, and the reason is written into the code: doing so would bypass credits and the audit log. When you later ask what AI usage happened on your account, the answer comes from a log that had no way of missing an entry.
Every model output is treated as untrusted
Whatever comes back passes through a sanitizer before it can reach the screen. Not "if it looks suspicious". Every output, every time, on the stated assumption that model output is untrusted input, which is the standard posture for anything arriving from outside your system.
The capability list is an honesty artifact
The wizard holds a list of form features, each marked supported or not. Unsupported entries render disabled with the reason shown, and they are stripped out of the prompt entirely, so the model is never even asked to produce something the builder cannot render. That second part is the important one: a tool that lets you ask for anything and then quietly returns something plausible but broken has moved the work rather than removing it.
What it can build includes required fields, multiple sections, conditional logic, showing and hiding entire sections, multi page forms with a progress bar, file uploads, image uploads, PDF uploads, digital signature, OTP verification, date restrictions, anonymous responses, validation rules, and the school data pickers described above.
Custom CSS is refused on purpose
One entry on that list is not a gap waiting to be filled. The designer will not produce custom CSS, and the stated reason is that injecting AI authored CSS is a cross site scripting vector. It stays closed by decision, not by backlog.
What the sanitizer actually enforces
Treating output as untrusted only means something if the check has teeth. This one has hard caps: at most 30 sections, 200 fields, 100 options on a field, 20 pages and 20 conditions, with short text capped at 500 characters and long text at 2000. Text passing through is stripped of script and style blocks, all remaining tags, javascript: and data:text/html references, inline on* event handlers, and control characters, and duplicate section identifiers are de-duplicated rather than allowed to collide.
Page numbers are forced to a 1-based range and capped, and the reason given is concrete: a model that emits page 9999 would otherwise render a progress bar with thousands of empty steps.
The detail that matters most: when the sanitizer drops something, it emits a warning that comes back to the interface. Silent truncation would leave you looking at a form that appears complete while three sections you asked for are not there, and you would find out from a parent.
You see the estimated cost before you spend it
AI use is metered, so the wizard fetches a pre-flight estimate and refreshes it as you change your requirements. You decide to run it after seeing the number. Because it is metered, AI use also sits behind its own permission, separate from viewing and editing forms, so somebody can be trusted to build forms all day without being able to spend the school's AI credits.
Editing an existing form is a reviewable diff
Generation is the easy case, because there is nothing to break. The harder case is a form that already exists. There, you give an instruction, the assistant proposes a changed structure, it is compared against the current one, and you are shown the differences as individual changes to accept or reject. There is no in place rewrite; the assistant does not "apply" anything. It can also suggest improvements and explain what a form does, both read only. On a live form it can look, suggest and explain freely, and every change still needs a person to accept a specific, visible difference.
After the form exists
A built form is only half the job. The rest is when it accepts responses and who may send them.
A response window with one rule
Forms have an open time, a close time and a manual close, resolved by the server in a fixed precedence: manual close first, then status, then not yet open, then closed.
A form parked in scheduled goes live the moment its open time passes, because acceptance is evaluated at request time rather than waiting for a background job to relabel it. The cron only tidies status values so listings read correctly. Opening is therefore as clock accurate as closing, which is what you want when a circular has told parents the form opens at nine.
The admin schedule panel mirrors that precedence exactly, so what an administrator reads there is what a respondent will actually hit.
Worth stating plainly, because the two facts are easy to confuse: the forms builder supports scheduling and a response window, and the AI designer will not author them. The wizard's capability list still gates scheduling and expiry, so those options appear disabled there with their reason. You set the window yourself in the schedule panel, whether the AI drafted the form or you built it.
Who can respond
Access is set by a visibility mode. Public forms are open. Link forms are reachable by anyone holding the URL. Password forms require a password, stored hashed rather than in the clear. A form can also be targeted at an audience by user type, so a staff leave form is offered to staff and a parent consent form to parents.
The design decision underneath is worth reading twice. Enforcement is centralised: the public surface, the authenticated respondent surface and the "forms for me" listing all decide access through the same code. Gating only the fetch and not the submit is the classic hole, so both paths call through this module.
All of this governs responding to a form. Who may build one is a separate question, answered by the forms permissions on your staff roles. Once responses arrive, the builder reports on them per question.
Honest limits
Several things are not built yet, and the wizard says so rather than generating something that would not work, each with its stated reason:
- Approval workflow. The approvals module exists, but it is not yet bridged to form responses.
- Notifications on submission. Not yet wired to form submissions.
- Draft saving by the respondent. Responses submit in one shot; there is no partial save endpoint.
- CAPTCHA. Anticipated in the settings structure, not implemented.
- Calculated fields. There is no expression engine in the renderer, so a field that computes from other fields has nothing to compute with.
Also unsupported and marked as such: payment collection, response limits, auto numbering, QR codes, barcode and QR scanning, geolocation capture, translation, and the custom CSS covered above.
Read that list as a roadmap if you like, but read it first as a design choice. Being told up front that submission notifications are not wired is a minor inconvenience. Discovering it a week into admissions is not.
Frequently asked questions
Can the AI publish a form to parents by itself?
No. Nothing in the AI path writes a form or a form version. It returns a structure for you to review, and saving goes through the ordinary draft path any manually built form uses. Publishing remains a human action.
If I start from a template, does editing the template change my form?
No. Selecting a template deep copies it into a new form of your own, with fresh section identifiers and fields repointed to them. The copy is never linked back, so changes to the template cannot affect forms already created from it.
Can a form open and close on schedule?
Yes. A form has an open time, a close time and a manual close, resolved in that precedence by the server, and a scheduled form goes live the moment its open time passes. The AI designer will not author those settings for you; you set them in the schedule panel.
How do we restrict who can respond?
Choose a visibility mode of public, link or password, and optionally target an audience by user type. The same access code governs the public page, the signed in page and the listing of forms available to a person, so fetch and submit are gated identically.
Which AI provider does it use?
The service routes to the provider configured for your school, behind a single execution path that also handles token accounting, credit deduction and logging.
Why is a feature I want greyed out in the wizard?
Because the builder cannot render it yet, or because the AI is not permitted to author it. Each unsupported entry shows its reason, and is removed from the prompt entirely so the model is never asked for it.
Conclusion
Most form builders are judged on how quickly they produce a form. This one is easier to judge on what happens around it: templates that copy rather than link, fields that bind to real students and classes, a response window with one stated precedence that the admin panel mirrors, and access enforced on one code path for reading and submitting.
The AI designer sits inside that, useful and firmly fenced. It cannot publish, overwrite or delete a form, reach a provider outside the metered and logged path, put unsanitized output on your screen, be asked for a feature the builder cannot render, or write custom CSS. Those limits make the generated draft worth having, and the honest capability list means you learn what is missing while you are still specifying.
ScolaOS is built by Terra System Labs Pvt Ltd, which is ISO 9001:2015 compliant, ISO 27001:2022 compliant, and Startup certified.
Want to talk through how your school builds its forms? Book a demo, or read about the wider platform, the apps catalogue, our security posture, pricing and the FAQ in your own time.
