Salesforce technical debt: hoe je het vindt en aflost

Kort antwoord: Salesforce technical debt is de opgestapelde prijs van elke eerdere kortere weg die nog in je org zit, net zo goed in clicks als in code. Je vindt het met een volledige metadata-inventarisatie gekoppeld aan gebruiksdata. Je lost het af in de volgorde die je roadmap vraagt, niet van boven naar beneden, want debt dat niets op de roadmap blokkeert kan wachten, soms onbeperkt.

Wat is Salesforce technical debt?

Technical debt is het extra werk dat een toekomstige wijziging kost door een beslissing van eerder. Op Salesforce stapelt het sneller op dan op de meeste stacks, om twee structurele redenen: een wijziging is een admin en vijf clicks ver, en niets in het platform vervalt zodra mensen het niet meer gebruiken.

Het komt in vier vormen:

• Automatiseringsdebt. Workflow Rules, Process Builder-processen en Flows die elkaar overlappen, in een volgorde die niemand op een whiteboard kan tekenen.
• Configuratiedebt. Velden die al twee jaar niemand invult, layouts voor rollen die niet meer bestaan, profielen met rechten die in permission sets thuishoren.
• Codedebt. Meer dan een trigger per object, tests geschreven om een coveragecijfer te halen in plaats van gedrag te controleren, hardcoded IDs.
• Integratiedebt. Aanroepers die vastzitten op API-versies die het platform niet meer bedient, en middleware waarvan de eigenaar het bedrijf verlaten heeft.

Alleen de vierde soort breekt hoorbaar. De andere drie belasten stilletjes elk project dat je draait.

Waar zit het nu verstopt?

Twee gedateerde punten verdienen deze week aandacht, omdat het platform bewoog en de meeste orgs niet.

• Workflow Rules en Process Builder zijn voorbij end of support. Salesforce zette die datum op 31 december 2025. Wat er nog op draait blijft werken, maar bugs erin worden niet meer opgelost en nieuwe kun je niet bouwen. De tool Migrate to Flow bestaat precies hiervoor.
• Oude API-versies zijn weg. Platform API-versies 21.0 tot en met 30.0 voor SOAP, REST en Bulk werden in Summer '22 deprecated en met Summer '25 uitgefaseerd. Aanroepers krijgen nu 410 GONE op REST, 500 UNSUPPORTED_API_VERSION op SOAP en 400 InvalidVersion op Bulk. Is een oude nachtelijke job stil gevallen, kijk dan hier eerst.

Hoe inventariseer je debt zonder de levering stil te leggen?

1. Draai Salesforce Optimizer en exporteer het. Het is gratis, het staat in Setup en het geeft je een beginlijst in plaats van een mening.
2. Haal de org-metadata op in source control. Zelfs als je er nooit vanaf deployt, heb je nu iets dat je kunt grepen, diffen en tellen.
3. Koppel de inventarisatie aan gebruik. Veldhistorie, abonnementen op rapporten en dashboards, paginaweergaven, Apex-logs. Een veld zonder lees- of schrijfacties in twaalf maanden is een kandidaat. Datzelfde veld op een object met nog 400 andere is een prioriteit.
4. Breng afhankelijkheden in kaart voordat je iets verwijdert. De vraag waar wordt dit gebruikt is het hele verschil tussen een opruiming en een storing.
5. Wijs per gebied een eigenaar aan. Debt zonder eigenaar wordt nooit afgelost.

Voor een middelgrote org is dit een oefening van twee weken die naast een normale sprint loopt. Wat het oplevert is een register, geen projectplan.

Hoe rangschik je wat je gevonden hebt?

Hier gaat het bij de meeste debt-programma's mis. Rangschikken op ernst geeft een lijst op volgorde van hoe erg iets eruitziet. Rangschikken op inspanning geeft een lijst op volgorde van hoe makkelijk iets is. Geen van beide is een lijst die je organisatie twee keer financiert.

Rangschik in plaats daarvan tegen de roadmap. Stel bij elk item in het register een vraag: welk toegezegd roadmap-item wordt hierdoor trager, risicovoller of onmogelijk? Die ene vraag sorteert het register in drie niveaus.

• Blokkerend. Het roadmap-item kan pas live als het debt is afgelost. Doe dat werk binnen dat project, betaald uit dat project en met de business case ervan.
• Belastend. Het roadmap-item gaat toch live, maar duurder of met risico dat er niet hoort te zijn. Doe het in de sprint ervoor, strak afgebakend.
• Slapend. Niets op de roadmap raakt het. Leg het vast, houd het in de gaten, financier het niet.

Twee categorieen overrulen de rangschikking: alles met een security- of compliancegevolg, en alles dat in productie stilletjes faalt. Die los je op ongeacht de roadmap, omdat hun prijs niet in levertijd wordt betaald.

Waarom mislukt een grootschalige opruiming?

Drie redenen, en we hebben ze alle drie zien gebeuren.

1. Geen zichtbaar resultaat. Een org-brede opruiming levert geen functie op en geen cijfer waar een sponsor naar kan wijzen, dus verliest hij zijn budget zodra prioriteiten opnieuw worden verdeeld.
2. Reputatieschade. Je verwijdert metadata waar niemand naar keek, er ontstaat een incident, het incident wordt toegeschreven aan de opruiming, en de volgende wordt nooit goedgekeurd.
3. Het convergeert nooit. Een org die het hele jaar heeft geleverd, heeft alweer nieuw debt tegen de tijd dat de schoonmaak klaar is. Aflossen dat aan roadmap-items hangt convergeert per definitie, want het eindigt als het roadmap-item live gaat.

Het doel is geen schone org. Het doel is een org waarin de roadmap van de komende twaalf maanden tegen voorspelbare kosten geleverd kan worden.

Welke cadans werkt echt?

• Elke sprint. Een vast deel van de capaciteit, vaak 10 tot 20%, voor belastend debt in de gebieden die de volgende stories raken.
• Elke Salesforce-release. Drie keer per jaar Optimizer opnieuw draaien, de retirement-berichten opnieuw lezen en de API-versies van je integraties opnieuw controleren.
• Elk jaar. De inventarisatie verversen en opnieuw rangschikken tegen de nieuwe roadmap. Items schuiven tussen niveaus als plannen veranderen, en slapend debt wordt soms van de ene op de andere dag blokkerend.

Een preventieve maatregel presteert beter dan alle drie: deploy vanuit source control, zodat de staat van de org reproduceerbaar is en elke wijziging binnenkomt met een auteur, een reden en een test. Debt dat je in een diff ziet wordt zelden debt dat je in een incident ontdekt.

Wij doen deze inventarisatie aan het begin van een traject in plaats van na de eerste verrassing, en dat is mede hoe we 16+ organisaties live in productie hebben gebracht op Salesforce. Wil je een tweede mening over je eigen org voordat je de roadmap van volgend jaar vastlegt, begin dan hier.

FAQ

Hoe weet ik of mijn org te veel technical debt heeft?

Meet het in levering, niet in aantallen. Als routinewijzigingen regressietests over losstaande gebieden vragen, of als niemand kan voorspellen wat een wijziging breekt, is het debt al duur.

Moeten we ongebruikte velden verwijderen?

Alleen na een afhankelijkheidscheck en alleen als iets op de roadmap er baat bij heeft. Ongebruikte velden zijn meestal slapend debt, en slapend debt is het goedkoopste in je org om met rust te laten.

Is Salesforce Optimizer genoeg?

Het is de juiste eerste stap, niet de laatste. Optimizer signaleert platformniveau-issues, maar kan je niet vertellen welke daarvan tussen jou en de roadmap van volgend kwartaal staat.

Moeten we nu meteen weg van Workflow Rules en Process Builder?

Ze draaien nog, maar de end of support was 31 december 2025, dus defecten erin blijven staan. Migreer eerst de automatiseringen die je roadmap raakt, niet alles tegelijk.