Een Salesforce-implementatie is zelden een eenmalig project. Het is het begin van een platform dat meegroeit met je organisatie, soms jarenlang. De keuzes die je in de eerste maanden maakt, bepalen hoe flexibel, beheerbaar en schaalbaar dat platform later is. Sommige van die keuzes zijn makkelijk terug te draaien. Anderen zitten er voor altijd in.
In dit artikel bespreken we zeven technische beslissingen waarvan we in de praktijk zien dat ze het verschil maken tussen een implementatie die blijft werken en een die na twee jaar al wordt herbouwd.
1. Eigenaarschap en governance: wie is de baas over het platform?
Technisch de minst glamoureuze keuze, maar in de praktijk de meest impactvolle. Zonder duidelijk eigenaarschap groeien Salesforce-omgevingen razendsnel uit tot een wildgroei van velden, flows en aangepaste objecten die niemand meer durft aan te raken.
Stel van tevoren vast wie:
- Nieuwe configuraties goedkeurt en documenteert
- Bepaalt welke processen in Salesforce thuishoren en welke niet
- De interne Salesforce-beheerder is, of welke externe partij die rol vervult
- Release-beslissingen neemt bij wijzigingen in productie
Een governance-model hoeft niet zwaar te zijn. Een eenvoudig change-log, een vaste beheerder en een korte beslislijn zijn vaak voldoende voor het MKB.
2. Datamodel: bouw je voor nu of voor later?
Het Salesforce-datamodel is de ruggengraat van je implementatie. Fouten hierin zijn duur: velden hernoemen klinkt simpel, maar als twintig flows, rapporten en integraties ervan afhangen, wordt het een project op zich.
Veelgemaakte fouten:
- Te veel custom velden op standaardobjecten zonder duidelijk doel
- Relaties die later moeilijk aanpasbaar blijken (bijvoorbeeld verkeerd gebruik van Master-Detail vs. Lookup)
- Geen naamgevingsconventie voor API-namen, waardoor het datamodel na een jaar onleesbaar is
Besteed in de ontwerpfase tijd aan het doordenken van je objectstructuur. Dat levert later veel meer op dan een snelle start.
3. Declaratief versus maatwerk: wanneer schrijf je Apex?
Salesforce biedt krachtige no-code en low-code mogelijkheden via Flow, validatieregels en formules. De vuistregel is: gebruik declaratief tenzij het niet anders kan. Apex-code vereist ontwikkelaars, testklassen en een deployment-pipeline. Flow niet.
Kies voor Apex wanneer:
- Complexe bulkverwerking nodig is die Flow-limieten raakt
- Asynchrone processen vereist zijn (Queueable, Batch)
- Externe API-calls in complexe patronen moeten worden afgehandeld
Vermijd de verleiding om alles in Apex te bouwen omdat een ontwikkelaar beschikbaar is. Een goed gebouwde Flow is makkelijker te beheren door een admin en goedkoper te onderhouden.
4. Integratiepatronen: realtime of asynchroon?
Bijna elke Salesforce-omgeving integreert met andere systemen: een ERP, een marketingplatform, een extern portaal. De keuze tussen realtime en asynchrone integratie heeft grote impact op betrouwbaarheid, complexiteit en kosten.
Realtime (via REST API of Platform Events) werkt goed wanneer directe terugkoppeling nodig is, maar vereist robuuste foutafhandeling. Asynchrone integratie via een middleware-laag (MuleSoft, Make, Azure Logic Apps) is flexibeler en veerkrachtiger bij storingen.
Leg integraties altijd vast in een integratiekaart: welk systeem is de master voor welke data, in welke richting stroomt data, en wat gebeurt er bij een storing?
5. Identiteit en autorisaties: least privilege van dag één
Een van de meest onderschatte onderdelen van een implementatie is de autorisatiestructuur. Organisaties beginnen vaak met brede profielen (“iedereen mag alles zien”) en proberen die later te beperken. Dat is omgekeerde wereld.
Bouw je permissiemodel van tevoren op basis van het principe van least privilege: gebruikers krijgen alleen toegang tot wat ze nodig hebben. Gebruik Permission Sets voor aanvullende rechten, en vermijd het aanpassen van standaardprofielen. Dat maakt toekomstige wijzigingen en audits een stuk eenvoudiger.
6. Testen en deployment: geen productie-sandbox
Te veel Salesforce-omgevingen worden direct in productie gebuild. Dat werkt tot het niet meer werkt: een fout in een flow, een verkeerde validatieregel of een mislukte update kan de hele afdeling platleggen.
Stel een eenvoudige deployment-pipeline in:
- Developer sandbox voor bouwen en testen
- Partial/Full copy sandbox voor UAT met echte data
- Change sets of SF CLI voor gecontroleerde deployments naar productie
Dit klinkt zwaarder dan het is. Zelfs een kleine organisatie profiteert van een eenvoudige sandbox-strategie.
7. Monitoring en beheer: weten wat er draait
Als een flow faalt in productie, wil je dat weten voordat een gebruiker het meldt. Stel vanuit het begin monitoring in via:
- Flow- en Apex-foutmeldingen via e-mailnotificaties of een gedevieerd beheerder-account
- Setup Audit Trail voor het bijhouden van configuratiewijzigingen
- Event Monitoring (bij Enterprise of Unlimited) voor diepgaandere gebruiks- en beveiligingslogging
Documenteer ook welke processen kritisch zijn, zodat bij een incident direct duidelijk is wat prioriteit heeft.
Conclusie
Een goede Salesforce-implementatie is meer dan een werkende configuratie op de opleverdatum. Het is een platform dat over drie jaar nog steeds beheersbaar, uitbreidbaar en begrijpelijk is. Dat vraagt om doordachte keuzes aan het begin, niet om perfectie, maar om richting.
Sta je aan het begin van een implementatie of loop je tegen de grenzen van je huidige omgeving aan? We kijken graag met je mee. Neem contact op voor een vrijblijvend gesprek.