Salesforce datamodel voor RevOps: velden, relaties en hygiëne
Je forecast klopt niet, je telt dezelfde klant dubbel en niemand weet welk veld de waarheid bevat. Dat ligt zelden aan je team en bijna altijd aan een datamodel dat ad hoc gegroeid is. Dit is hoe je een Salesforce datamodel bouwt waar sales, marketing, customer success en finance op dezelfde waarheid sturen.
Je forecast klopt niet, je telt dezelfde klant dubbel en niemand weet meer welk veld de waarheid bevat. Sales rapporteert andere getallen dan finance, marketing claimt leads die nooit pipeline werden, en bij elke board-meeting kost het uren om de cijfers te laten kloppen. Dat ligt zelden aan je team en bijna altijd aan een Salesforce datamodel dat ad hoc gegroeid is: extra velden hier, een losse picklist daar, drie velden voor dezelfde businessvraag zonder dat iemand eigenaar is.
In het begin werkt dat prima. Maar zodra volume, teamgrootte en deal-complexiteit toenemen, wordt die wildgroei een rem op groei. Records lopen dubbel, conversie-attributie verdwijnt, en de forecast wordt een gok in plaats van een stuurmiddel. Een goed datamodel begint daarom niet bij extra velden, maar bij één betrouwbare structuur: welke records bestaan, hoe objecten verbonden zijn, welke data verplicht is en hoe teams die data schoon houden. Pas dan kun je sturen op dezelfde waarheid — van eerste lead tot revenue recognition, expansion en renewals.
Waarom dit nu belangrijk is
Een rommelig datamodel raakt niet alleen efficiency. Het raakt je forecast, je klantbeleving en je managementinformatie tegelijk. Wanneer opportunity stages, deal types, valuta’s, close dates of renewal-indicatoren inconsistent worden gebruikt, wordt de forecast direct minder betrouwbaar. Wanneer “qualified lead”, “new business”, “expansion” of “renewal” niet overal hetzelfde betekent, kunnen sales en marketing nooit op dezelfde funnel sturen.
Het probleem ontstaat geleidelijk. Een organisatie begint met simpele standaardobjecten en voegt daarna ad hoc velden, picklistwaarden en layouts toe. Voor je het weet bestaan er meerdere velden voor dezelfde businessvraag — “Lead Source”, “Original Source” en “Campaign Source” — zonder duidelijke ownership. Duplicate Accounts tellen klanten dubbel, duplicate Contacts verstoren outreach, duplicate Leads maken attributie onbetrouwbaar. Slechte data quality raakt forecasting, ownership, routing, customer success, billing én finance in één keer.
Een sterk RevOps-datamodel voorkomt die frictie door vooraf te bepalen welke data nodig is, waar die data hoort en welke regels de kwaliteit bewaken. Het ondersteunt de volledige buyer-to-cash journey: van lead capture en qualification tot opportunity management, quotes, contracts, orders, billing, customer success en revenue recognition. Het doel is niet records opslaan, maar een structuur waarin teams dezelfde definities, statussen en metrics gebruiken. Dit is geen RevOps-fundament op zich — wil je het bredere plaatje, lees dan Wat is RevOps? als vertrekpunt.
Het framework: zes stappen naar een schaalbaar datamodel
1. Zet de kernobjecten en hun relaties vast
De kern van Salesforce voor RevOps bestaat uit Lead, Account, Contact en Opportunity. Een Lead vertegenwoordigt een inbound- of outbound-prospect voordat er een formele relatie bestaat; dit object ondersteunt lead scoring, qualification criteria, source attribution en marketing automation-handoffs. Een Account vertegenwoordigt de (potentiële) klantorganisatie. Een Contact vertegenwoordigt de mensen binnen die organisatie: beslissers, champions, gebruikers, economic buyers en blockers. Samen vormen Account en Contact de basis voor customer lifecycle management, segmentation, customer success, expansion insights en renewals. Een Opportunity legt een concreet verkooptraject vast: pipeline visibility, deal velocity, forecasting, revenue amount, close date, billing frequency, discount, competitive situation en win/loss-analyse.
Deze objecten ondersteunen RevOps-doelen omdat ze de commerciële keten opdelen in meetbare stappen. Leads tonen conversion tracking, Accounts tonen markt- en klantstructuur, Contacts tonen stakeholder-influence en Opportunities tonen de revenue die verwacht, gewonnen of verloren wordt.
Objectrelaties bepalen hoe data door het revenue lifecycle stroomt. Een Lead wordt geconverteerd naar een Account, Contact en Opportunity. Als custom Lead fields niet goed gemapt zijn, gaan attribution, qualification-context en campaign insights verloren. De belangrijkste relationship types zijn lookup, Master-Detail en junction objects. Een lookup geeft flexibiliteit; Master-Detail creëert striktere ownership, roll-up summaries en afhankelijkheden. Bij die keuze denk je niet alleen aan technische modeling, maar ook aan rapportage, security, lifecycle en wat er gebeurt wanneer een record wordt verwijderd of samengevoegd. Voor many-to-many situaties, zoals contactrollen op deals, gebruik je een junction-benadering zoals Opportunity Contact Roles.
2. Definieer must-have custom velden per object
Must-have velden zijn geen willekeurige extra invoervakken; ze beantwoorden specifieke RevOps-vragen: is deze lead sales-ready, wie beslist, wat is het revenue potential, wanneer wordt revenue erkend, waarom winnen of verliezen we? Koppel elk veld aan een proces, dashboard of besluit. Als niemand weet wat een veld beïnvloedt, wordt het genegeerd.
Lead qualification-velden. BANT-achtige velden zijn vaak de basis: Budget__c, Authority__c, Need__c en Timeline__c. Daarnaast zijn source- en campaign tracking-velden essentieel voor attributie: LeadSource, OriginalLeadSource__c, CampaignSource__c en eventueel een campaign ID uit marketing automation. Voor conversion analysis voeg je QualificationStatus__c (met waarden als “Unqualified”, “Contacted”, “Qualified – BANT”, “Qualified – MEDDPICC”, “Disqualified”) en QualificationReason__c toe. Let op de Lead conversion mapping: velden die belangrijk blijven na conversie moeten compatibele datatypes hebben op Contact, Account of Opportunity. Global picklists helpen, omdat dezelfde waarden over objecten beschikbaar blijven.
Account- en Contact-enrichment. Must-have Account fields zijn CompanySize__c, IndustryClassification__c en RevenuePotential__c. Voor Contacts zijn decision maker identification en influence mapping belangrijk: een veld als DecisionMakerContact__c op Account, of contact-level velden voor persona, role, buying influence, champion status en economic buyer. Engagement tracking maakt het model operationeel: EngagementScore__c, CommunicationPreference__c, TouchCount, LastActivityDate en opt-out-indicatoren. De valkuil is oververzameling — gebruik alleen velden die reporting, routing, segmentation of revenue decisions ondersteunen, en documenteer wie eigenaar is van updates.
Opportunity revenue tracking. Must-have velden zijn DealType__c (New Business, Renewal, Expansion, Upsell, Cross-sell), SalesMethodologyStage__c of QualificationMethod__c, en CompetitiveSituation__c. Voor revenue recognition en billing zijn RevenueRecognitionDate__c en BillingFrequency__c belangrijk — zeker bij subscriptions, annual contracts, usage-based pricing of multi-year orders. Zonder deze velden ontstaat spanning tussen forecasted, booked en recognized revenue. Voor win/loss-analyse gebruik je WinLossReason__c; voor deal velocity een formula field, bijvoorbeeld het aantal dagen tussen eerste kwalificatie en Closed Won. Koppel Opportunity-data altijd aan rapportagebehoeften: vraagt leadership naar pipeline by territory, forecast by currency of renewal risk by segment, dan moeten de velden dat ondersteunen vóór je rapporteert.
3. Richt multi-currency, Units of Measure en picklists bewust in
Complexere RevOps-scenario’s vragen om meer dan standaardvelden. Dit zijn configuraties die je vroeg moet inrichten, omdat latere correcties duur en risicovol zijn. Houd het model simpel waar mogelijk, maar niet simplistisch.
Multi-currency is zinvol wanneer teams in meerdere valuta’s verkopen of rapporteren. Salesforce ondersteunt dit, maar de beslissing is zwaarwegend: na inschakeling kun je het niet zomaar terugdraaien, en bestaande records krijgen een currency code (meestal de corporate currency). Exchange rate management wordt een RevOps- en finance-verantwoordelijkheid; voor historische rapportage kan Advanced Currency Management relevant zijn. De grootste conversion challenges ontstaan wanneer sales territories, finance reports en billing systems verschillende aannames gebruiken. Best practices: definieer één corporate currency voor executive reporting; bepaal welke teams lokale valuta mogen gebruiken; documenteer hoe currency conversion werkt in forecasting; test rapportfilters met gebruikers met verschillende persoonlijke valuta; voorkom losse custom currency-workarounds.
Units of Measure zijn nodig wanneer je niet alleen “een dealbedrag” verkoopt, maar ook seats, licenses, usage, modules, uren of bundels. De line-level data gaat dan via Opportunity Products, Quote Lines, Subscription Line Items of CPQ objects. Typische velden zijn Quantity__c, UnitPrice, TotalPrice en UoM__c (waarden als “licenses”, “users”, “GB”, “hours”, “transactions”). In Salesforce CPQ bepalen quantities, units, discount, bundles en price rules wat op quotes en contracts verschijnt; als UoM niet consistent is, ontstaan fouten in pricing, billing en revenue recognition. Praktische regel: leg de commerciële samenvatting vast op Opportunity, maar het detail op line item-niveau.
Record types vs. picklists. Record types zijn nuttig wanneer processen echt andere stages, layouts, verplichtingen of gebruikersgroepen vereisen — denk aan New Business vs. Renewal of Enterprise Sales vs. Self-Serve. Gebruik ze niet alleen omdat een picklist lang wordt. Global picklists zijn beter wanneer waarden breed gedeeld worden: Industry, Region, Lead Status, Deal Type, Billing Frequency, Win/Loss Reason.
| Criterium | Record types | Global picklists |
|---|---|---|
| Beste gebruik | Verschillende processen, layouts of sales motions | Gedeelde waarden over objecten en teams |
| Voorbeeld | New Business Opportunity vs. Renewal Opportunity | DealType, Industry, BillingFrequency |
| Voordeel | Proces-specifieke UX en validation rules | Consistente data, minder mapping-fouten |
| Risico | Meer onderhoud, meer layouts, complexere permissions | Te generiek als processen echt verschillen |
| Governance | Strakke ownership en change control nodig | Centraal beheer van waarden en definities |
Naming conventions zijn de basis voor schaalbaar picklist management. Gebruik beschrijvende API names, consistente labels en duidelijke DeveloperNames. Een veld als DealType__c is beter dan ctc_status__c zonder context.
4. Bewaak data quality met dedupe en validatie
Data hygiene bepaalt of je metrics betrouwbaar zijn. Een praktische dedupe-strategie combineert prevention, detection, review en cleanup. Alleen blokkeren is te hard, alleen rapporteren te zwak — je wilt rommel buiten houden, maar ruimte laten voor legitieme uitzonderingen zoals holdings, subsidiaries en regionale vestigingen.
Duplicate rules. Salesforce Duplicate Management werkt met matching rules (welke velden worden vergeleken: Name, Email, Website, Phone, Domain) en duplicate rules (waarschuwen, blokkeren of toestaan met alert). Voor Leads en Contacts is email vaak sterk maar niet altijd voldoende; voor Accounts tellen Website, Account Name, billing address en parent-child relationships; voor Opportunities is dedupe afhankelijk van Account, close period, product line en deal type. Automated prevention is vooral belangrijk bij web-to-lead, API imports en enrichment tools; manual review-workflows zijn beter voor grote imports en twijfelgevallen. Custom matching logic is nodig voor unieke scenario’s: een holding en subsidiary kunnen dezelfde website delen maar commercieel aparte customers zijn.
Validation en required fields. Validation rules zorgen dat data compleet is op het moment dat het proces erom vraagt — bijvoorbeeld DealType, Amount, CloseDate en Primary Contact verplicht bij Proposal, en WinLossReason verplicht bij Closed Lost. Gebruik progressive required fields: blokkeer reps niet in vroege stages met twintig verplichte velden, maar maak requirements strenger naarmate de deal vordert. Error handling is net zo belangrijk als de regel zelf: “Vul Billing Frequency in voordat de Opportunity naar Contracting gaat; finance gebruikt dit voor billing planning” is bruikbaarder dan “Veld ontbreekt”. Velden die pricing, routing, revenue recognition, compliance of forecast accuracy beïnvloeden zijn essentieel; “misschien interessant” hoort niet als harde validatie.
Doorlopend onderhoud. Data quality degradeert vanzelf zonder ritme. Regular audits kijken naar duplicate count, nulwaarden in key fields, ongebruikte picklistwaarden, records zonder owner. Cleanup-workflows bouw je met Flow, scheduled jobs of externe tools. User training is onderdeel van data management — zonder uitleg omzeilen mensen regels onder sales pressure. Monitoring maakt hygiëne zichtbaar via data quality-dashboards (duplicate rate, mapping errors, Opportunities zonder primary contact, missing revenue recognition dates). RevOps beheert het systeem, maar sales, marketing, customer success en finance zijn medeeigenaar van de data. Dit raakt direct aan bredere data governance voor RevOps: ownership, definities en kwaliteitsafspraken die het hele model dragen.
5. Visualiseer en documenteer het model
Visuele documentatie en governance voorkomen dat het datamodel een black box wordt. Schema Builder toont objecten, velden en relationships visueel. Gebruik het om de volledige RevOps-flow te mappen: Lead naar Account, Contact en Opportunity; Opportunity naar Quote, Contract, Order, Subscription en billing records. Zo wordt duidelijk waar een data point ontstaat en waar het later wordt gebruikt — wat discussies over “waar hoort dit veld?” ná de implementatie voorkomt. Gebruik Schema Builder niet pas achteraf: whiteboard eerst, modelleer dan in sandbox, configureer daarna.
Consistente naming conventions maken het model schaalbaar. Gebruik duidelijke field labels, voorspelbare API names en consistente taal; meng niet willekeurig Nederlands en Engels in technische namen. Documenteer elk custom field met minimaal: doel, object, datatype, eigenaar, verplichtingslogica, gebruikte record types, picklist source, integration impact, rapportagedoel en mapping bij Lead conversion. Leg ook business logic vast: wat gebeurt met CampaignSource__c bij Lead conversion? Wordt RevenueRecognitionDate__c overschreven door CPQ? Komt BillingFrequency__c uit Salesforce, billing of een contract management-systeem?
6. Borg wijzigingen met version control
Version control en change management zijn noodzakelijk voor serieuze RevOps-teams. Werk met sandbox testing, metadata deployments, release notes en approval voor wijzigingen aan record types, picklists, required fields en integrations. Zo voorkom je dat één kleine picklist-update downstream reports, syncs of quotes breekt. Verwerk je in je model ook persoonsgegevens — wat bij Leads en Contacts vrijwel altijd zo is — borg dan tegelijk de privacy-kant; zie GDPR/AVG voor RevOps voor retentie, grondslag en data subject requests.
Praktijkvoorbeeld: een mid-market SaaS-scale-up van 45 FTE
Neem een B2B SaaS-bedrijf van 45 FTE dat internationaal verkoopt (EUR en USD), met zowel new business als renewals in Salesforce. De forecast klopte structureel niet en finance kreeg de geboekte omzet maar niet aangesloten op de pipeline.
De diagnose legde drie dingen bloot. Ten eerste bestonden er drie velden voor lead source zonder eigenaar, waardoor attributie onbruikbaar was. Ten tweede gebruikten new business en renewals dezelfde Opportunity-stages, terwijl het feitelijk twee verschillende processen zijn — een renewal heeft geen “discovery”, maar wel een renewal date en churn risk. Ten derde stond multi-currency aan, maar gebruikten sales en finance verschillende exchange-rate-aannames, waardoor dezelfde deal in twee rapporten anders uitkwam.
De aanpak volgde het framework. De drie source-velden werden geconsolideerd tot één OriginalLeadSource__c op een global picklist, met heldere ownership bij marketing. Voor renewals kwam een apart record type met eigen stages, RenewalRisk__c en een verplichte RevenueRecognitionDate__c. Eén corporate currency (EUR) werd vastgelegd voor board reporting, met gedocumenteerde conversie-afspraken. Tot slot kwamen er progressive required fields per stage en een data quality-dashboard met duplicate rate en missing-field-counts.
Het resultaat is niet magisch maar wel concreet: één bron voor attributie, een forecast die finance kan reconciliëren, en een dashboard dat laat zien wáár data ontbreekt voordat het de rapportage besmet. Werk je in B2B SaaS en herken je dit patroon? Zie de aanpak voor B2B SaaS waar groei dit soort operationele druk creëert.
Checklist: is jouw Salesforce datamodel RevOps-klaar?
- [ ]
Lead,Account,ContactenOpportunityhebben heldere, gedeelde definities die sales, marketing, CS en finance erkennen. - [ ] Object relationships (lookup, Master-Detail, junction) zijn bewust gekozen op basis van rapportage en lifecycle, niet toeval.
- [ ] Elk custom field is gekoppeld aan een proces, dashboard of besluit — en heeft een eigenaar.
- [ ] Source- en attributievelden zijn geconsolideerd: één veld per businessvraag, geen dubbelen.
- [ ] Opportunity heeft velden voor DealType, revenue recognition, billing frequency en win/loss reason.
- [ ] Multi-currency is alleen aan als het echt nodig is, met één corporate currency voor reporting.
- [ ] Units of Measure staan op line item-niveau; de commerciële samenvatting op Opportunity.
- [ ] Record types zijn gereserveerd voor echt verschillende processen; gedeelde waarden staan in global picklists.
- [ ] Duplicate rules en matching rules zijn ingericht, met manual review voor twijfelgevallen.
- [ ] Validation rules zijn progressive per stage; foutmeldingen leggen uit waarom en hoe.
- [ ] Er is een data quality-dashboard met duplicate rate en missing-field-counts.
- [ ] Het model is gevisualiseerd in Schema Builder en gedocumenteerd per veld.
- [ ] Wijzigingen lopen via sandbox, release notes en approval.
Veelgestelde vragen
Hoeveel custom velden zijn te veel voor performance? Er is geen universeel magisch aantal, maar te veel custom velden maken Salesforce trager, moeilijker te beheren en lastiger te gebruiken. Let vooral op page layout-performance, rapportagecomplexiteit, automation dependencies en gebruikerservaring. Een goed criterium: elk custom field moet een duidelijk proces, rapport, integratie of besluit ondersteunen. Als niemand eigenaar is, niemand het gebruikt en geen dashboard erop stuurt, is het waarschijnlijk technische schuld.
Hoe vaak moeten duplicate rules worden geüpdatet? Controleer duplicate rules minimaal per kwartaal en altijd na grote wijzigingen in lead sources, marketing automation, enrichment tools, territories of account hierarchy. Bij snelle groei of veel imports is maandelijkse review verstandiger. Kijk niet alleen naar hoeveel duplicates worden gevonden, maar ook naar false positives en false negatives. Als goede records worden geblokkeerd of echte duplicaten niet worden herkend, moet de matching logic worden aangepast.
Wat zijn de kosten van multi-currency voor kleine RevOps-teams? De kosten zitten meestal minder in de knop zelf en meer in implementatie, testing, rapportage, training en finance alignment. Afhankelijk van de Salesforce-editie, setup en eventuele Advanced Currency Management kunnen er platform- of configuratie-implicaties zijn. Voor kleine RevOps-teams is multi-currency zinvol wanneer meerdere valuta’s echt nodig zijn voor sales, forecasting, quotes of billing. Als alle deals in één valuta worden gecontracteerd, houd het model dan liever simpel.
Welke validation rules zijn essentieel vs. nice-to-have? Essentiële validation rules beschermen forecasting, handoffs, compliance, pricing, billing en revenue recognition. Voorbeelden zijn een verplichte CloseDate en Amount in de actieve pipeline, WinLossReason bij Closed Lost, BillingFrequency bij contracting en Primary Contact bij late-stage Opportunities. Nice-to-have-regels gaan vaak over extra context die nuttig is, maar het proces niet mag blokkeren. Maak die liever zichtbaar via dashboards, prompts of completion scores in plaats van harde errors.
Hoe documenteer je datamodel-changes voor compliance? Documenteer per wijziging: datum, eigenaar, reden, betrokken objecten en velden, impact op integrations, impact op reporting, testresultaten en deployment-details. Voeg release notes toe voor gebruikers wanneer de wijziging hun workflow raakt. Voor compliance is vooral traceerbaarheid belangrijk. Gebruik sandbox, change sets of DevOps-tooling, bewaar metadata-updates en leg vast welke approval nodig was voordat wijzigingen naar productie gingen.
Wil je dit toepassen in jouw operatie? Bekijk Business Process Sprint of plan een kennismaking.