Wanneer bouw je maatwerk in Salesforce in plaats van te configureren?

Kort antwoord: configureer eerst, altijd. Bouw maatwerk als de logica een echt onderscheidend vermogen is, als hij buiten de levenscyclus van een enkel record moet draaien, of als je dezelfde workaround voor de derde keer nabouwt. De aanleiding om te bouwen is niet complexiteit maar herhaling en eigenaarschap: complexiteit die je een keer configureert is prima, complexiteit die je elk kwartaal opnieuw moet uitleggen niet.

Wat is het verschil tussen configureren, uitbreiden en bouwen?

• Configureren: standaardobjecten, page layouts, validatieregels, Flow. Geen deploybare code, en het gaat mee met het platform.
• Uitbreiden: eigen objecten en velden plus een beetje Apex of een Lightning Web Component rond een grotendeels standaardproces. Nog steeds Salesforce-vormig.
• Bouwen: een ontworpen applicatie. Eigen datamodel, services, tests en releasecyclus, of dat nu als Apex en LWC in je org landt of als een verpakt product.

De meeste discussies over "bouwen versus configureren" gaan eigenlijk over die middelste categorie, waar het eerlijke antwoord meestal is: breid uit, begin geen project.

Waarom is configureren nog steeds de juiste standaard?

Het advies van Salesforce zelf is al tien jaar consistent: beoordeel de native en declaratieve mogelijkheden voordat je code schrijft. Declaratief werk draagt geen testcode, geen repository en geen upgradelast, en het schuift automatisch mee met elke release. Ook de limieten gedragen zich anders. Declaratief werk loopt tegen ontwerplimieten aan, zoals hoeveel regels je op een object kwijt kunt, terwijl code tegen uitvoeringslimieten aanloopt zoals het aantal SOQL-queries, en die zijn veel lastiger te omzeilen (Salesforce Developers).

Bovendien stijgt de ondergrens. Workflow Rules en Process Builder worden na 31 december 2025 niet meer ondersteund, nieuwe kun je niet meer aanmaken, en Salesforce wijst teams naar de Migrate to Flow-tool (Salesforce Ben). Alles wat je vandaag bouwt concurreert met wat het platform morgen opslokt, en dat pleit voor minder bouwen, niet voor niets bouwen.

Waar houdt configureren op te lonen?

Dit zijn de vijf alarmbellen die wij gebruiken. Eén ervan is een gesprek. Twee of meer is een besluit.

1. De flow is een programma geworden. Als niemand de uitkomst kan voorspellen door hem te lezen en een wijziging een zorgvuldige middag kost, heb je al software. Alleen in een vorm zonder tests, zonder codereview en zonder leesbare diff.
2. De vraag is een datamodel, geen scherm. Rapportage die drie niet-gerelateerde objecten moet samenvoegen, of een hiërarchie die het standaardmodel niet uitdrukt, is een ontwerpprobleem. Configuratie levert dan een vorm op waar je voor altijd omheen werkt.
3. Het gedrag leeft buiten de levenscyclus van een record. Geplande verwerking, event-verkeer in volume, reconciliatie tussen systemen, retries en idempotentie. Declaratieve automatisering wordt door records aangeslingerd; dit niet.
4. De logica is je onderscheid en verandert vaak. Prijsregels, routeringsintelligentie, entitlement-logica. Alles waar 10% beter zijn dan de concurrent telt, verdient tests, versiebeheer en een eigenaar.
5. Je betaalt er drie keer voor. Dezelfde workaround opnieuw gebouwd in een tweede land, een tweede business unit, een derde klant-org. Dat is geen configuratie meer, dat is een onverpakt product.

Hoe vergelijk je de echte kosten eerlijk?

Niet bouwkosten tegen configuratiekosten, maar drie jaar eigenaarschap aan beide kanten.

• Configuratie draagt: adminuren per wijziging, regressierisico dat niemand meet, inwerkkosten voor elke nieuwe admin die de workaround moet leren, en een plafond op wat je ooit kunt automatiseren.
• Maatwerk draagt: initiële engineering, testdekking, codereview, een upgradepad over drie releases per jaar, en het risico dat het platform jouw functie volgend jaar gratis levert.

De vergelijking kantelt meestal op één getal dat niemand opschrijft: hoe vaak per jaar het proces verandert. Vaak veranderen pleit voor code met tests, want tests zijn hoe je iets veilig verandert. Zelden veranderen pleit voor configuratie, want dan hoeft niemand de spier te onderhouden.

Wat betekent "bouwen" tegenwoordig?

Zelden een applicatie vanaf nul. In de praktijk is het een van vier vormen: Apex en Lightning Web Components in de org; een verpakt component dat je in meerdere org's installeert; een managed package op de AppExchange; of een service buiten Salesforce die de org via een API of een MCP-server aanroept, met een agent action ervoor.

De verpakte varianten doen er meer toe dan teams verwachten. Bouwen als package dwingt de versionering, het upgradepad en de isolatie af die je anders overslaat, en maakt de tweede en derde uitrol vrijwel gratis. Dat is de discipline die wij uit productwerk naar implementaties meenemen: omdat Tekunda als PDO AppExchange-producten bouwt en uitlevert, erft ons implementatiewerk herbruikbare, geteste componenten in plaats van ze telkens opnieuw te bouwen.

Hoe voorkom je dat maatwerk de volgende puinhoop wordt?

1. Geef het op dag één een eigenaar en een uitfaseerplan. Code zonder eigenaar wordt configuratie die niemand kan lezen.
2. Zet configuratiewaarden in custom metadata, niet in de code. Het hele punt is dat de business ze zonder jou kan wijzigen.
3. Schrijf de tests als specificatie, niet als dekkingsbelasting.
4. Controleer elke release of het platform je heeft ingehaald. Je eigen code verwijderen is een legitiem resultaat.

Goed gedaan is de opbrengst geen elegante architectuur maar operationele winst. Voor ASSA ABLOY brachten we de wekelijkse cases terug van 3.000 naar 350, een reductie van 93% over 11.000 verbonden apparaten en tot 2,5 miljoen events per week, in drie markten en zonder extra supportmensen. Dat volume was nooit een Flow geworden. Weeg je dezelfde beslissing, praat dan met ons vóór de bouw, niet tijdens de redding.

FAQ

Is maatwerk altijd duurder dan configuratie?

Nee. Het is duurder om te starten en vaak goedkoper om te wijzigen. Vergelijk drie jaar eigenaarschap, inclusief de adminuren en het regressierisico die configuratie stilletjes opeet.

Wanneer is iets te complex voor Flow?

Gebruik een menselijke toets in plaats van een elemententelling: als een capabele admin niet kan voorspellen wat hij doet door hem te lezen, of hem niet binnen een uur veilig kan wijzigen, is het software geworden.

Zelf bouwen of kopen op de AppExchange?

Koop als de functionaliteit een commodity is en een bestaande app het grootste deel dekt. Bouw als de logica de reden is dat klanten voor je kiezen.

Sluit maatwerk ons af van platformupgrades?

Niet als het als package met een versie en een testsuite is gebouwd. Wat upgrades blokkeert is ongedocumenteerde code zonder eigenaar, en dat overkomt configuratie net zo goed.