MB-820-sertifisering dokumenterer evnen til å utvikle løsninger i Dynamics 365 Business Central for deg som kommer fra NAV- eller .NET-erfaring, uten at eksamen må behandles som enda en teoretisk Microsoft-test.
MB-820 er eksamenen for Microsoft Certified: Dynamics 365 Business Central Developer Associate, og den retter seg mot utviklere som bygger, utvider, tester og vedlikeholder løsninger i Business Central. Microsoft beskrev endringer i Business Applications-opplæringen i forbindelse med lanseringen, og den offisielle eksamenssiden for MB-820 er den riktige kilden for gjeldende ferdighetsområder, eksamensstatus og detaljer som kan endres over tid.
For norske utviklere og konsulenter er sertifiseringen interessant av en praktisk grunn: Business Central-prosjekter er ofte små nok til at utvikleren må forstå forretningsprosessen, men komplekse nok til at dårlig kode raskt skaper problemer ved oppgraderinger, integrasjoner og rapportering. Derfor måler MB-820 mer enn kjennskap til AL-syntaks. Den peker mot en arbeidsform der utvidelser, hendelser, tester og sikkerhet er en del av leveransen.
Hva rollen faktisk innebærer
En Business Central-utvikler designer og bygger tekniske løsninger på toppen av standardfunksjonaliteten i Dynamics 365 Business Central. Arbeidet kan omfatte sideutvidelser, tabellutvidelser, rapporter, API-er, integrasjoner, testkodeenheter, feilsøking og ytelsesforbedringer. I praksis skjer dette ofte i tett samarbeid med funksjonelle konsulenter, økonomiavdelinger, lageransvarlige eller eksterne systemeiere.
Det er viktig å skille utviklerrollen fra den funksjonelle rollen. MB-820 hører til Business Central Developer-sporet, mens MB-800 er knyttet til Business Central Functional Consultant-rollen. Den funksjonelle konsulenten arbeider mer med prosessforståelse, oppsett og forretningsflyt, mens utvikleren må kunne gjøre tekniske utvidelser på en måte som tåler oppgraderinger og drift. Mange i partner- og sluttkundemiljøer trenger innsikt i begge sider, men sertifiseringene måler ulike ferdigheter.
Dette skillet blir tydelig i ansettelsesprosesser. En arbeidsgiver vil sjelden være fornøyd med at en kandidat bare kjenner menyer og konfigurasjon dersom stillingen er en utviklerrolle. Det forventes gjerne kodeeksempler, forståelse for publisher- og subscriber-hendelser, erfaring med API Pages eller OData, og evne til å vise hvordan løsningen er testet. Sertifikatet kan støtte profilen, men det erstatter ikke dokumentert teknisk praksis.
Fra C/AL-tilpasninger til AL-utvidelser
Den største overgangen for erfarne NAV-utviklere er ikke bare nytt språk eller nytt verktøy. Den ligger i utviklingsmodellen. Klassiske NAV-tilpasninger var ofte basert på direkte endringer i standardobjekter, mens moderne Business Central-utvikling bygger på AL, Extension v2 og hendelsesdrevet design. Dette endrer hvordan utvikleren tenker om vedlikehold, oppgraderinger og ansvar mellom standardløsning og kundetilpasning.
I en eldre C/AL-verden kunne en endring i standardkode være den raskeste veien til ønsket funksjonalitet. I Business Central er det vanligvis feil mental modell. Utvikleren bør lete etter eksisterende hendelser, abonnere på dem, legge egen logikk i separate objekter og bruke utvidelser som kan publiseres, testes og oppgraderes uten å låse kunden til en tung tilpasningspakke. Dette er sentralt for MB-820 fordi eksamenen i stor grad reflekterer hvordan Business Central faktisk bør bygges i sky- og hybridmiljøer.
Et praktisk eksempel er validering av en kundespesifikk regel ved bokføring eller ved endring av en tabellverdi. I stedet for å endre standardprosedyren direkte, bør utvikleren undersøke om Microsoft eller appen allerede publiserer en relevant hendelse. Deretter kan en subscriber-codeunit plassere logikken utenfor standardobjektet. Det gjør løsningen lettere å lese, lettere å teste og mindre sårbar ved neste oppdatering.
Eksempel — subscriber for en forretningsregel i AL
codeunit 50120 CustomerPostingRules
{
[EventSubscriber(ObjectType::Table, Database::Customer, 'OnAfterValidateEvent', 'Credit Limit (LCY)', false, false)]
local procedure CheckCreditLimitAfterValidate(var Rec: Record Customer; var xRec: Record Customer; CurrFieldNo: Integer)
begin
if Rec."Credit Limit (LCY)" < 0 then
Error('Credit limit cannot be negative.');
end;
}
Poenget med eksempelet er ikke selve regelen, men plasseringen av regelen. Koden ligger i en separat codeunit og abonnerer på en hendelse i stedet for å endre standardobjektet direkte. En kandidat som forbereder seg til MB-820 bør kunne forklare hvorfor dette mønsteret gir bedre oppgraderbarhet, og hvordan det bør kombineres med tester, rettigheter og tydelige feilmeldinger.
Verktøykjeden som gjør læringen konkret
MB-820-forberedelser blir ofte for abstrakte når kandidaten bare leser dokumentasjon. Business Central-utvikling læres bedre ved å bygge små utvidelser, publisere dem til et kontrollert miljø, feilsøke dem og skrive tester. Et moderne utviklingsoppsett består vanligvis av Visual Studio Code med AL-utvidelsen, Git, et Business Central-miljø å publisere mot, og en måte å kjøre automatiserte tester på.
For lokal utvikling bruker mange BcContainerHelper til å opprette Business Central-containere. Det gir et isolert miljø der utvikleren kan hente symboler, publisere apper, teste avhengigheter og reprodusere feil uten å forstyrre en delt sandbox. I teammiljøer bør dette kobles til en Git-flyt der endringer går via pull requests, og der en enkel CI-pipeline bygger appen og kjører relevante AL-tester før endringen slippes videre.
Den praktiske gevinsten er at eksamensmålene blir knyttet til arbeidsvaner. Når en kandidat selv har opplevd symbolfeil, avhengighetsproblemer, manglende rettigheter eller en test som feiler etter en sideutvidelse, blir teorien lettere å forstå. Det gir også bedre samtaler i jobbintervjuer, fordi kandidaten kan beskrive hvordan en app bygges og kvalitetssikres, ikke bare hvilke emner som står i pensum.
Hva MB-820-forberedelser bør dekke
En realistisk læringssti bør begynne med forskjellen mellom funksjonell bruk av Business Central og teknisk utvidelse av plattformen. Deretter bør kandidaten arbeide med AL-objekter, hendelser, side- og tabellutvidelser, rapporter, permission sets, feilsøking, integrasjoner og testautomatisering. Det er bedre å bygge flere små, korrekte utvidelser enn én stor øvingsapp som hopper over sikkerhet og tester.
Bygg en enkel extension med tabellutvidelse, sideutvidelse og valideringslogikk.
Legg til en subscriber-codeunit som bruker en relevant Business Central-hendelse.
Skriv minst én testcodeunit som bekrefter ønsket oppførsel.
Definer permission set for appen og test med en bruker som ikke har brede administratorrettigheter.
Eksponer data via API Page eller vurder OData der det passer bedre med eksisterende objekter.
API Pages og OData bør ikke behandles som samme valg med ulik innpakning. API Pages passer ofte når integrasjonen skal ha et tydelig kontraktsformat, stabil struktur og kontrollerte felter mot eksterne systemer eller Power Platform. OData kan være nyttig for enklere tilgang til eksisterende sider eller spørringer, men utvikleren må vurdere ytelse, datamodell og sikkerhet. I MB-820-sammenheng handler dette om å forstå konsekvensene av designvalget, ikke bare å få en endpoint til å svare.
Readynez tilbyr et instruktørledet MB-820-kurs for lesere som ønsker strukturert eksamensforberedelse rundt disse temaene. Verdien av instruktørledet trening ligger særlig i å få hullene synlige: mange kandidater overvurderer generell NAV- eller Business Central-erfaring, men undervurderer permission sets, AL Test Tool, rapport- og sideutvidelser og hendelsesdrevet design. Slike svakheter oppdages raskere i labarbeid enn i passiv lesing.
Vanlige feil som svekker både eksamen og prosjektarbeid
En vanlig feil er å forberede seg som om MB-820 først og fremst tester historisk NAV-erfaring. Erfaring med C/AL, objektdesign og forretningslogikk er verdifull, men den må oversettes til moderne AL-praksis. Kandidater som fortsetter å tenke i direkte modifikasjoner, får ofte problemer med hendelser, avhengigheter og oppgraderingssikre mønstre.
En annen feil er å behandle sikkerhet som noe som kan legges på til slutt. Permission sets påvirker om appen faktisk kan brukes av riktige roller i produksjon, og mangelfull testing med realistiske rettigheter skjuler feil som først oppdages etter utrulling. Det samme gjelder testautomatisering. Uten AL-tester blir det vanskeligere å se om en endring i en extension bryter eksisterende forretningslogikk.
Rapporter og sider blir også ofte undervurdert. Mange øver mest på codeunits og tabeller fordi det føles mest som klassisk utvikling, men Business Central-brukere møter løsningen gjennom sider, handlinger, rapporter og arbeidsflyt. En utvikler som forstår brukeropplevelsen, lager bedre tekniske løsninger og feilsøker raskere når en tilpasning ikke oppfører seg som forventet.
Hvordan bygge en portefølje som støtter sertifiseringen
En god forberedelsesplan bør munne ut i noe som kan vises frem. Det trenger ikke være en stor app eller et kommersielt produkt. En liten portefølje med ryddig AL-kode, en README-fil, testcodeunits og en kort forklaring av designvalg kan være nok til å vise at kandidaten forstår moderne Business Central-utvikling. Dette er særlig nyttig for juniorutviklere med .NET- eller Power Platform-bakgrunn som vil inn i Business Central-markedet.
Porteføljen bør vise oppgraderingssikre mønstre. Det kan være en extension som legger til felt på Customer, validerer en regel via hendelser, eksponerer et avgrenset API og inneholder tester for den viktigste logikken. Hvis prosjektet også viser enkel Git-historikk og en build som kan kjøres i CI, får arbeidsgiveren et bedre bilde av hvordan kandidaten vil fungere i et team.
Dette er også nyttig for erfarne NAV-utviklere. En portefølje kan vise at gammel kompetanse er modernisert: C/AL-muskulaturen er oversatt til AL, direkte objektendringer er erstattet med extension-mønstre, og dataoppgraderingskode er håndtert bevisst. Den typen dokumentasjon kan være mer overbevisende enn en CV-linje som bare sier «Business Central-erfaring».
En praktisk vei mot MB-820
En kandidat som allerede arbeider i et Business Central-prosjekt, bør bruke prosjektet som læringsarena, men ikke la prosjektets behov definere hele eksamensforberedelsen. Prosjekter dekker ofte et smalt område. MB-820 krever bredere eksponering mot utviklingsoppgaver, test, feilsøking, integrasjon og distribusjon.
- Start med den offisielle eksamenssiden og noter ferdighetsområdene som må dekkes.
- Sett opp et utviklingsmiljø med VS Code, AL og et egnet Business Central-miljø.
- Bygg små extensions som øver på tabeller, sider, rapporter, hendelser og rettigheter.
- Legg inn tester og kjør dem som en fast del av utviklingsarbeidet.
- Bruk prosjektarbeid til å knytte eksamensemnene til reelle feil, integrasjoner og brukerbehov.
Microsofts kunngjøring om Business Applications-opplæring, publisert på Microsoft Learn Blog, viser hvorfor denne sertifiseringen bør forstås som del av et bredere rollebasert opplæringsløp. Det betyr likevel ikke at kandidaten bør vente på perfekte læremidler. Den beste forberedelsen er å koble offisielle mål til praktisk bygging, testing og feilsøking.
Der sertifiseringen passer inn i utviklerrollen
MB-820 er mest verdifull når den bekrefter ferdigheter kandidaten faktisk bruker. En utvikler som kan forklare forskjellen mellom API Pages og OData, vise en testet extension, diskutere permission sets og begrunne bruk av hendelser, står sterkere enn en kandidat som bare har pugget begreper. Sertifiseringen bør derfor behandles som en ramme for ferdighetsbygging, ikke som et isolert mål.
Den mest praktiske neste fasen er å velge et lite Business Central-problem og løse det på en måte som tåler drift: bygg extensionen, skriv testen, dokumenter rettighetene og vis hvordan integrasjonen bør brukes. Dersom strukturert live-opplæring passer bedre enn selvstudium alene, kan Readynez Microsoft Unlimited være en aktuell vei for kontinuerlig Microsoft-trening over tid.
