Du ændrer et formularfelt fra påkrævet til valgfrit. Indsendelserne falder med 20 %. Du fortryder ændringen. Men formularværktøjet gemte ingen historik. Du kan ikke gå tilbage. Dit team bygger formularen op igen fra hukommelsen og mister data på vejen.
Formularer ændrer sig over tid. Der kommer felter til. Labels får nye ord. Regler for validering bliver strengere. Uden versionsstyring kan du ikke fortryde fejl eller se, hvad der er ændret. Her gennemgår vi versioner af formularer, overblik over ændringer og hvordan du går tilbage.
Derfor er versionsstyring af formularer vigtig
Formularer samler data. Når du ændrer en formular, ændrer du, hvilke data der bliver samlet. Er ændringen dårlig, vil du hurtigt kunne gå tilbage.
Uden historik har du ingen vej tilbage. Med historik kan du fortryde fejl på få sekunder.
Versionsstyring hjælper også med at overholde regler. Myndigheder spørger: hvad spurgte formularen om på den dato? Så skal du kunne vise den præcise version, der var i luften.
Hvad du skal følge i versionerne
Følg hver ændring af formularen, blandt andet nye felter, fjernede felter, ændrede labels, ændret hjælpetekst, nye eller ændrede regler for validering, ændret krav om udfyldelse, ændrede valgmuligheder i rullemenuer og felter, der har skiftet plads. Følg også metadata som hvem der har lavet ændringen, hvornår, hvorfor (hvis de skrev en note), og om ændringen er i luften eller en kladde.
Automatiske øjebliksbilleder af versioner
Den bedste metode er automatisk versionsstyring. Hver gang nogen ændrer formularen, gemmer systemet et øjebliksbillede.
Når du tilføjer et felt, laver formularværktøjet version 2 (den forrige var version 1). Den gamle version bliver gemt. Den nye version er i luften.
Du kan se forskellen: "Feltet 'Telefon' er tilføjet. Hjælpeteksten er ændret til 'Skriv landekode med'."
Nogle formularværktøjer gemmer et øjebliksbillede, hver gang du klikker på gem. Andre gemmer hver time. Hyppige øjebliksbilleder er bedst. Så kan du gå tilbage til et hvilket som helst tidspunkt.
Sammenlign versioner af formularen
Et godt system til versionsstyring lader dig sammenligne versioner side om side.
Version 1: "E-mail" (påkrævet) mod version 2: "E-mailadresse" (valgfri)
Hvad er ændret? Labelen blev længere, og kravet om udfyldelse blev fjernet. Det betyder noget, fordi valgfrie felter bliver udfyldt sjældnere.
Sammenligningen viser dig, hvilke felter der er tilføjet eller fjernet, hvilke labels der er ændret, hvilke regler for validering der er ændret, og hvilke felter der er blevet valgfrie i stedet for påkrævede.
Gå tilbage og få data tilbage
Når du opdager, at en ændring var dårlig, så gå tilbage til den forrige version. Klik "Gå tilbage til version 5." Formularen bliver som i version 5.
Det skal gå med det samme. Lad ikke brugeren vente. Bagefter kan du undersøge, hvad der gik galt.
Nogle formularværktøjer lader dig gå tilbage til en hvilken som helst version. Andre kan kun gå ét skridt tilbage. At kunne gå tilbage til en hvilken som helst version er mere stærkt.
Grene og kladder
Før du laver store ændringer, så lav en gren. Lav ændringerne i kladden. Test den nye version. Når du er tilfreds, udgiver du den (flet den ind i den version, der er i luften).
Det forhindrer, at du kommer til at ændre den formular, der er i luften. Du ændrer kladden og ikke den version, der er i luften, indtil du er klar.
Grene hjælper også, når flere arbejder på formularer. Én på teamet arbejder på grenen "redesign", mens en anden arbejder på grenen "tilføj-telefonfelt". Hovedformularen forbliver uændret, indtil hver gren er klar.
Besked om ændringer i formularer
Når nogen ændrer en formular, så giv teamet besked. Så undgår du, at ændringer bliver overset.
"Anna har ændret kontaktformularen. Feltet 'Firma' er fjernet. Det er i luften nu."
Beskeder på e-mail er gode. Beskeder i en chatapp er bedre. Logs i administrationen er afgørende.
Til formularer med meget på spil (kasse, betaling, tilmelding) kan du kræve godkendelse, før ændringer går i luften. Den, der ændrer formularen, er ikke den, der godkender. Det forhindrer fejl.
Eksportér formularens opsætning
Eksportér formularens opsætning som JSON eller XML, og gem den i git, så du har versionsstyring uden for formularværktøjet. En typisk eksport ser sådan ud { "version": 1, "name": "Contact Form", "fields": [ { "type": "email", "name": "email", "label": "Email", "required": true }, { "type": "text", "name": "message", "label": "Message", "required": true } ] }. Læg den i git, så du har historik, forskelle og mulighed for at gå tilbage, og git viser, hvem der har ændret hvad og hvornår.
Samordn ændringer af formularer på tværs af systemer
Hvis formularen er forbundet til dit CRM, din database eller dit e-mailsystem, påvirker en ændring af formularen også dem.
Hvis du fjerner et felt fra formularen, men CRM'et stadig venter feltet, går integrationen i stykker. Det er vigtigt at samordne.
Før du laver store ændringer i formularen, så tjek, hvad der er koblet på. Opdatér integrationer, hvis det er nødvendigt. Test hele forløbet og ikke kun formularen.
Dokumentation og ændringslog
Før en ændringslog over, hvad der er ændret, og hvorfor. For eksempel version 2 (2026-04-05) fjernede feltet Firma, fordi de fleste brugere lod det stå tomt, og følgen var, at formularen til nye kunder nu tager 30 sekunder i stedet for 45. Version 3 (2026-04-10) gjorde feltet Telefon valgfrit, fordi for mange droppede ved det felt, og følgen var, at flere gjorde formularen færdig, 8 % flere. En ændringslog hjælper dig med at huske beslutninger, fortæller nye på teamet, hvad I har lært, og viser, hvordan formularen har udviklet sig.
Sådan klarer WEMASY versioner af formularer
Principperne her gælder, uanset hvilket værktøj du bruger. Skriv dine ændringer ned, test før du går i luften, og hold øje med, hvad der er koblet på formularen.
Se, hvilke formularfunktioner der er med i din WEMASY-plan.