Release waves i Business Central er ikke bare en kalenderbegivenhed. De er en teknisk ændringsstrøm, som rammer kode, sikkerhed, integrationer og daglig drift. Når en virksomhed kører med egne extensions, AppSource-apps og integrationer til bank, lager, EDI eller Power Platform, bliver hver wave i praksis en mini-upgrade.
Det gælder især, hvis løsningen har vokset sig stor over tid. Små afvigelser i permissions, ændrede symbolpakker, deprecated AL-metoder eller nye krav til afhængigheder kan skabe fejl, som først viser sig sent, hvis test ikke er planlagt ordentligt. Det er netop derfor release waves bør håndteres som en fast del af governance omkring Business Central.
Hvad release waves i Business Central faktisk betyder
Business Central kommer med to større release waves om året. Hver wave består af en offentlig releaseplan, en early access-periode og efterfølgende general availability. I releaseplanen for 2025 wave 1 fremgår det, at perioden dækker april til september 2025, med releaseplan offentliggjort 23. januar 2025, early access fra 3. februar 2025 og general availability fra 1. april 2025.
Det lyder administrativt, men for teknikere betyder det noget helt konkret. Early access er vinduet, hvor man bør validere egne apps og kritiske processer mod den kommende version, før ændringerne rammer produktionsmiljøet. General availability betyder ikke bare “nye funktioner”. Det kan betyde ændret runtime-adfærd, nye standardobjekter, justerede systemapps og ny opførsel i API’er eller brugergrænsefladen.
Fra 2024 til 2026 er mønstret blevet tydeligere. Release waves handler i stigende grad om:
- hurtigere platformsskift
- strammere sikkerhed og datatypekrav
- mere styring af afhængigheder
- højere forventning til automatiseret test
Et gennemgående råd i det tekniske community hos yzhums.com, hougaard.com, waldo.be og vjeko.com er, at man skal læse releaseplanen med udviklerbriller, ikke kun med procesbriller. Det er sjældent nok at spørge, om brugerne får en ny funktion. Man skal spørge, hvad der ændrer sig i app-modellen, objektlaget og deploy-flowet.
Tekniske ændringer i release waves, der typisk rammer hårdest
De mest følsomme ændringer ligger sjældent i den synlige funktionalitet. De ligger i fundamentet. Det gælder især extensions, system application, base application, permissions, event-signaturer og afhængigheder til tredjepartsapps.
Et konkret eksempel fra 2025 wave 1 er nye udviklermæssige muligheder omkring SecretText i control add-ins og JSON-objekter. Det er nyttigt, men det viser samtidig retningen: sikker håndtering af følsomme data bliver mere central. Når platformen bevæger sig den vej, påvirker det kode, integrationer og måden data sendes mellem lagene på.
Typiske tekniske ændringer i en wave er ofte disse:
- ændrede eller deprecated AL-metoder
- nye runtime-krav
- opdaterede symboler til standardapps
- ændringer i sidefelter, actions eller events
- nye eller ændrede permission sets
Problemet er ikke kun compile-fejl. Problemet er regressionsfejl. En extension kan godt kompilere og publiceres, men stadig opføre sig anderledes ved postering, batchkørsler, API-kald eller rollecenter-visninger. Det er den type fejl, der rammer forretningen hårdest, fordi de først opdages efter opgradering.
Sandbox-test af extensions før general availability
Et sandbox-miljø er den vigtigste forsvarslinje før en release wave. Sandbox-miljøer i Business Central er netop beregnet til test, træning og fejlfinding uden at forstyrre drift og produktionsdata. I praksis bør en sandbox ikke kun bruges til kliktest. Den skal bruges som et teknisk valideringsmiljø.
Når man tester en wave, bør sandbox-miljøet ligne produktion så meget som muligt. Det betyder samme apps, samme brugerroller, samme integrationsopsætning i det omfang det er forsvarligt, og realistiske data. Hvis miljøet kun indeholder standardfunktionalitet, får man et falsk billede af risikoen.
En brugbar testsekvens ser ofte sådan ud:
- Tag udgangspunkt i en frisk kopi af produktion til sandbox.
- Opdater eller installer alle egne extensions og AppSource-apps i de versioner, der forventes brugt ved wave-skiftet.
- Kør automatiserede tests, hvis de findes, og supplér med manuelle forretningsscenarier.
- Verificér permissions, job queues, API-kald, rapporter og posteringer.
- Registrér fejl som enten compile-fejl, runtime-fejl eller regressionsfejl.
Der er særlig høj risiko i processer, der går på tværs af moduler. Et salg, der posterer fint, er ikke nødvendigvis et godt tegn, hvis dokumentudsendelse, lagerreservation, bankafstemning eller dimensioner fejler bagefter. Regressionsrisiko ligger tit i overgangene mellem funktioner, ikke i den enkelte handling.
AppSource-afhængigheder og symboler i build-processen
Afhængigheder til AppSource-apps har længe været en praktisk udfordring. Mange teams har brugt tid på at skaffe symboler eller runtime-pakker manuelt fra app-udgivere. Den del er blevet lettere, fordi platformen nu understøtter download af symboler til AppSource-applikationer via et public NuGet feed, som beskrevet i releaseindholdet for 2024 wave 2.
Det er en teknisk forbedring med stor effekt. Når build-pipelinen automatisk kan hente symboler for eksterne afhængigheder, bliver det langt lettere at validere, om en extension stadig bygger korrekt mod den kommende wave. For teams med CI/CD og AL-Go for GitHub er det særligt nyttigt, fordi builds og test i online sandboxes kan automatiseres mere stabilt.
Det ændrer dog ikke ved, at afhængigheder stadig skal styres aktivt. En AppSource-app kan ændre version, introducere nye permission sets eller justere offentlige events. Hvis din egen app er tæt koblet til den, kan en mindre ændring udløse store følgefejl.
Her er de vigtigste kontrolpunkter i afhængighedsstyringen:
- Versionsstyring: Fastlæg hvilke app-versioner der er godkendt i hvert miljø.
- Symbolkontrol: Verificér at build bruger korrekte symboler for både standardapps og AppSource-apps.
- API-overflade: Gennemgå events, interfaces og public procedures, som egne apps kalder.
- Deploy-rækkefølge: Test installation, opgradering og afinstallation i samme rækkefølge som ved faktisk release.
- Fallback-plan: Aftal hvad der gøres, hvis en tredjepartsapp ikke er klar til wave-versionen i tide.
Det er ofte her, forsinkelserne opstår. Ikke fordi Business Central som standard fejler, men fordi økosystemet omkring løsningen skal være klar samtidigt.
Permissions og sikkerhed i release waves
Permissions bliver ofte undervurderet ved waves. Mange ser kun på, om brugeren kan åbne en side. Det er for snævert. Rettigheder påvirker bagvedliggende læsning, indsættelse, ændring, sletning og kørsel af objekter, og små ændringer kan få batchjob, integrationer eller posteringer til at fejle.
I nyere versioner er det værd at holde øje med permission set extensions. Ifølge dokumentationen om permission set extension kan denne objekttype kun tilføje rettigheder til et eksisterende permission set. Den kan ikke fjerne rettigheder. Når extensionen installeres, lægges de ekstra rettigheder til automatisk, og de forsvinder igen ved afinstallation.
Det lyder enkelt, men det skaber et vigtigt designprincip: Hvis man har bygget sikkerhed op med en blanding af standardroller, egne permission sets og AppSource-tilføjelser, skal man teste summen af rettighederne efter hver wave, ikke kun den enkelte app.
Gå især efter disse områder:
- Brugerroller: Kan nøglebrugere stadig udføre de samme end-to-end processer?
- Batchjob: Har job queue-brugere stadig adgang til nødvendige objekter og data?
- Integrationer: Har servicebrugere de krævede permissions til API’er, tabeller og codeunits?
- Afinstallation: Hvad sker der med adgangsmodellen, hvis en app fjernes eller erstattes?
- Segregation of duties: Giver nye permission set extensions utilsigtet bredere adgang end planlagt?
Yzhums og hougaard peger ofte på, at permissions bør testes konkret med realistiske brugere i sandbox. Det råd holder stadig. Et admin-login skjuler fejl, som først viser sig for økonomi, lager eller support efter release.
Breaking changes ved upgrades fra ældre NAV og Business Central-versioner
Virksomheder på ældre NAV- eller Business Central-løsninger mærker release waves ekstra tydeligt, fordi forskellen mellem nuværende løsning og målversion kan være stor. Her taler man ikke kun om løbende waves, men om tekniske upgrades, hvor flere versionstrin skal passeres sikkert.
Compile-fejl under teknisk upgrade opstår typisk, når ny platform eller nye apps indeholder breaking changes i features, som den eksisterende kode stadig bruger. Dokumentationen om teknisk upgrade og compile-fejl beskriver netop, at kildekoden som regel skal ændres, hvorefter extensionen publiceres og opgraderes som led i forløbet. I den sammenhæng dukker værktøjer som Repair-NAVApp op i selve compile- og upgradeflowet.
Det er ikke kun syntaks, der er i spil. Schemaændringer kan være destruktive. Felter kan være flyttet, datatyper kan være ændret, og tabeller kan have fået ny struktur. Her er Test-NAVApplicationTable et relevant værktøj i on-prem-sammenhænge til at identificere og validere, om tabelændringer er sikre.
Vjeko og waldo har gennem årene haft et klart budskab i deres tekniske artikler: breaking changes skal findes så tidligt som muligt i build og test, ikke i selve cutover-vinduet. Det betyder, at man bør skelne mellem tre typer fejl:
- compile-fejl i AL-koden
- destructive changes i datamodellen
- funktionelle regressionsfejl efter deployment
Når de tre typer blandes sammen i ét testspor, bliver prioritering og fejlsøgning unødigt tung.
Regressionsrisici i extensions og integrationer
Regressionsrisiko opstår, når noget, der virkede før, ikke længere virker efter wave-opdateringen, selv om ændringen ikke ser dramatisk ud. Det gælder især i extensions med mange event subscribers, custom pages, report extensions og integrationer til eksterne systemer.
Et klassisk eksempel er ændringer i standardobjekter, hvor en side eller kodeunit får ny rækkefølge i validering eller postering. Egen kode kan stadig kompilere, men forretningslogikken ændrer sig. Samme mønster ses ved ændringer i permission sets, hvor brugerflowet bryder først ved den tredje handling i processen.
En god regressionspakke bør dække mere end happy path. Den bør ramme de steder, hvor løsningen er mest følsom:
- postering med dimensioner og godkendelser
- dokumentafsendelse og rapportlayout
- lagerprocesser med reservation og sporing
- bankintegrationer og afstemning
- webservices, API’er og filudveksling
Hvis der ikke findes automatiserede tests, bør man starte med de 10 til 15 mest kritiske scenarier. Det giver langt mere værdi end at lave bred, overfladisk kliktest.
En praktisk model for release governance i Business Central
Den tekniske forberedelse virker bedst, når den er koblet til en enkel styringsmodel. Release waves bør have en fast ejer, en testkalender og et klart beslutningspunkt for, hvornår produktion må opdateres eller accepteres.
I mange organisationer fungerer en lille model bedst. Ikke tung styring, men tydelige roller. En forretningsansvarlig validerer processer, en teknisk ansvarlig styrer apps, afhængigheder og sandbox-test, og superbrugere kører konkrete scenarier i et aftalt tidsrum.
En enkel governance-model kan bygges op sådan:
- Gennemgå releaseplan og kendte ændringer straks ved offentliggørelse.
- Klargør sandbox og opdater afhængigheder i early access-perioden.
- Kør teknisk validering af extensions, permissions og integrationer.
- Kør forretningstest på prioriterede scenarier.
- Godkend release til produktion ud fra dokumenteret risiko og fundne afvigelser.
Det lyder simpelt. Det er netop pointen. Når release waves håndteres som en tilbagevendende disciplin, bliver opdateringer mindre dramatiske, og løsningen holder sig mere opgraderbar over tid.
Det næste sprint før næste wave
Den mest værdifulde aktivitet før næste wave er sjældent ny udvikling. Det er oprydning. Få styr på app-afhængigheder, fjern forældede tilretninger, dokumentér permission-modellen og etabler en sandbox-test, der kan gentages.
Hvis miljøet har mange specialtilpasninger, er det en god idé at starte med en teknisk kortlægning: hvilke apps afhænger af hvilke symboler, hvilke integrationer er kritiske, hvilke brugere kører med specialroller, og hvor findes de største regressionsrisici. Når det billede er på plads, bliver release waves noget, organisationen kan styre, i stedet for noget der bare sker.