Digital Form Management — From Paper Trays to a Form Server

Almost every Swiss administration, hospital and mid-sized company has already digitised its forms. What it has not done is manage them. The estate typically consists of a few dozen PDFs on a website, a handful of forms built in whatever tool a department could expense, three variants of the same registration form maintained by three people who do not know about each other, and one crucial process that still ends with «print, sign, and bring it to the counter».

What «Form Management» Means Beyond a Form Builder

Start by Counting — the Inventory Nobody Has

Before choosing anything, list every form your organisation asks anyone to complete: on the website, in e-mail attachments, on paper at counters, embedded in intranet pages, and inside other systems. Nearly every organisation that does this finds four things:

• More forms than expected — usually two to three times the number anyone estimated, because departments each solved their own problem.
• Duplicates that have quietly diverged. Three registration forms, three different sets of fields, three different retention practices, one legal position.
• Forms with no owner. The person who made it left. Nobody is comfortable retiring it because nobody is sure who depends on it.
• Legal references that have aged. A form citing an ordinance that changed two revisions ago is a compliance finding sitting on your own website.

The inventory is also the only honest basis for a budget. «We need a form tool» is not a business case; «we have 180 forms, 40 of them collect sensitive data, 22 exist only in German and 11 still require a physical signature» is one.

Versioning: What Did This Person Actually See?

This is the single most under-appreciated requirement, and it is a legal one rather than a technical nicety. A completed form is a record of a specific text: these questions, this consent wording, this list of options, on this date. If someone edits the live form afterwards — adds a field, rewords a declaration, removes an option — the past submissions are still stored against a form that no longer exists in that shape.

Three consequences follow, and each one turns up in a real dispute:

1. Consent becomes unprovable. «I consented to X» versus «the form said Y» cannot be resolved if the form has been rewritten and no snapshot exists.
2. Statistics quietly lie. Answer rates computed against today's question set, applied to responses given to a different question set, produce numbers nobody should act on.
3. Edits become dangerous. If saving a draft can change a live form, nobody wants to touch anything — and the forms rot rather than improve.

Retention and Archiving — Two Duties Pulling in Opposite Directions

Data protection says delete when the purpose ends. Record-keeping law says keep for ten years. Both are right, and the resolution is that they apply to different forms — which is why a single organisation-wide retention rule is always wrong.

The electronic-archiving requirement deserves its own sentence, because it is where digitisation projects get caught. Records may be kept electronically provided they correspond to the underlying transactions and can be made readable at any time; the Business Records Ordinance expects unalterable carriers, and where the carrier is alterable, the integrity has to be technically demonstrable — hash values and qualified timestamps are the usual means. In practice that means «we exported it to a spreadsheet on a shared drive» is not archiving, and neither is a PDF that anyone can edit. Retention mechanics per data category are in form data retention.

Accessibility Is a Requirement, Not a Refinement

For Swiss public bodies and licensed companies the duty comes from the Disability Discrimination Act and its ordinance, and the technical standard is eCH-0059, whose version 3.0 is based on WCAG 2.1 at conformance level AA. Private companies are not bound by the same instrument in Switzerland — but if you place relevant products or services on the EU market, the European Accessibility Act has applied since 28 June 2025, so «we are private, it does not concern us» is worth checking rather than assuming.

For forms specifically, the requirements are unglamorous and almost always missed in the same six ways:

• Every field needs a real label, programmatically associated. Placeholder text is not a label; it disappears when typing starts.
• The whole form must work from the keyboard, in a sensible order, with a visible focus indicator.
• Error messages must say what is wrong and where, in text — not a red border alone, and not colour as the only signal.
• Required fields must be marked in text, not only with a coloured asterisk.
• Time limits and session expiry must be avoidable or extendable; someone using assistive technology takes longer, and a timeout that discards their answers is the worst possible failure.
• No visual-only CAPTCHA. It excludes people by design, and there are better anti-abuse mechanisms — see preventing spam, bots and duplicate submissions.

Publishing in German, French and Italian Is a Process, Not a Translation

In a Swiss organisation, one form is often three or four artefacts that must stay synchronised for years. Two failure patterns are near-universal: the language versions drift apart after the first update, and the legal terminology is translated rather than localised — «Auftragsverarbeitungsvertrag» rendered word for word, or an nFADP notice translated into GDPR vocabulary that does not match Swiss law.

What works: treat the language versions as one form with one field structure, so a new field appears in all languages as missing rather than silently absent; use each jurisdiction's own vocabulary rather than a literal translation; and give each language its own URL, because people share links in their own language and a language switcher that loses the form state is worse than no switcher.

The Procurement Questions That Separate a Tool From a System

1. Where do submissions live, and who can read them? The hosting region for response data and whether the provider's staff can see content. These are two different questions and vendors routinely answer only the first — see which form tools are hosted in Switzerland.
2. Is there a published processing agreement and sub-processor list? With the countries. Ask before the pilot, not before go-live.
3. How does publication work? Draft versus live, who can publish, and whether past submissions remain attached to the version that produced them.
4. What does the audit log record? Who opened, exported and deleted which submission, and how long that log is kept.
5. Which access model do you support? Single sign-on, group-based permissions, per-form access. Ask specifically; do not assume a small tool has enterprise identity integration, and do not accept a roadmap answer as a present capability.
6. What is the accessibility position? Ask for a statement against WCAG 2.1 AA and treat «our forms are accessible» without evidence as a no.
7. What does the export contain and what does deletion do? The exit test, before signature — the full version is in can you leave.

A Migration Plan That Actually Finishes

Nobody is ever asked to manage the forms. They are asked to publish one — two hundred times, over fifteen years, by people who have since left.

Bottom Line

Digitising a form is a design task that takes an afternoon. Managing a form estate is an ownership, versioning, retention, accessibility and language problem that runs for years — and it is the part nobody is assigned. The organisations that do it well start with an inventory, retire aggressively, classify by sensitivity, and insist that publication is an act with a record rather than a save button.

The technology question is genuinely secondary, with one exception: whatever you choose has to make the version question answerable and the exit question survivable. Everything else can be corrected later; those two get harder every year you postpone them.