Kies het juiste object
Ook beschikbaar in 28 talen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 5 van 10 in het hoofdstuk Salesforce-data-architectuur, hoofdstuk 3 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Waar staan deze gegevens? · Volgende: Velden zijn ook architectuur
De vraag die deze module beantwoordt: Wat voor Salesforce-object moet dit bedrijfsconcept worden, en wat staan licenties toe?
Een van de makkelijkste dingen in Salesforce is een aangepast object maken. Precies daarom denk ik dat we er te veel maken.
Je zit in een eisensessie en iemand zegt: “We moeten onze distributeurs bijhouden.” Nieuw aangepast object: Distributeur. Klaar. Alleen wil ik dat de architect eerst een andere vraag stelt: wat is een distributeur? Het is een bedrijf. Salesforce heeft al een vrij goede manier om een bedrijf weer te geven. Dat heet een account. Dat betekent niet dat het antwoord altijd account is. Maar als ik moet uitleggen waarom een bedrijf geen account is, wil ik een betere reden dan “de business noemt ze distributeurs”.
Hier ontmoet het logische model uit hoofdstuk 2 het platform, en mijn uitgangspunt is simpel: als het bedrijfsconcept een schone fit is met het bedoelde doel van een standaardobject, begin dan daar.
Begin bij de betekenis
Section titled “Begin bij de betekenis ”Zelfs als iets een object verdient, verdient het niet automatisch een aangepast object. Vraag wat het ding eigenlijk vertegenwoordigt. Een bedrijf of organisatie in welke vorm dan ook? Begin bij account. Een persoon die met die organisatie werkt? Contactpersoon. Iets wat een klant bezit of gekocht heeft? Asset. Iets wat je probeert te verkopen? Nu hoort verkoopkans in het gesprek.
Daarom keken we eerst naar het moederschip, in module 2. Die modellen passen niet bij elk bedrijf, maar we moeten ze niet negeren omdat zelf bouwen schoner voelt. Vraag vóór New Custom Object hoe Salesforce dit concept modelleert, wat er rond dat model gebouwd is, en wat je inlevert als je het vervangt.
De test van de schone fit
Section titled “De test van de schone fit ”Mijn test is één vraag: past dit bedrijfsconcept netjes bij het bedoelde doel van het standaardobject? Zo ja, dan neig ik naar het standaardobject.
Een distributeur is een bedrijf waarmee we een relatie hebben, dus account is een schone fit. Het maakt me niet uit dat gebruikers het ene bedrijf distributeur noemen, het andere leverancier, weer een ander retailpartner en nog een ander klant. Dat zijn bedrijfsrollen, en die hebben geen vier fysieke objecten nodig. Verschillende bedrijfsnamen betekenen niet automatisch verschillende datastructuren. Een type, een recordtype of een relatie kan het verschil dragen.
De test werkt ook de andere kant op. In hoofdstuk 1 liet ik je achter met een vraag: het bedrijf van een klant heeft veel afleverlocaties. Moet elke locatie een account zijn, of een aangepast object?
Een account geeft je veel. Je krijgt de adresvelden, en alles wat al een accountadres verwacht: rapporten, kaarten, integraties. Maar je krijgt ook de ballast: veel velden, sharing, hiërarchie, eigenaarschap, alles wat aan een account hangt, en het meeste daarvan is niet relevant voor een apart adres. Je sleept veel zware dingen mee die je niet gebruikt, alleen voor een alternatief adres.
Een aangepast object, een child van de account, kan licht zijn: alleen de adresvelden, een plek waar we afleveren, met een eigen levenscyclus die ik onafhankelijk kan beheren.
Het is dus een balans: het gewicht dat je op je neemt tegenover de waarde die je krijgt. Als ik alleen een adres met een eigen levenscyclus nodig heb, kies ik daar voor aangepast.
Hetzelfde geldt voor deelproblemen bij een case. Als elk deelprobleem echt een case is, opgepakt door een medewerker, met een eigen status en serviceniveau, nest ze dan met de Parent Case uit module 2. Maar als het gewoon een checklistitem is dat niemand als case oppakt, draagt een volledige case veel mee wat hij nooit zal gebruiken, en weegt een eenvoudig aangepast child misschien minder. Niet omdat aangepast schoner is. Omdat de betekenis anders is, of het gewicht niet klopt.
Standaardobjecten hebben bagage
Section titled “Standaardobjecten hebben bagage ”Als je een standaardobject kiest, kies je meer dan zijn velden. Je kiest iets wat de producten van Salesforce al begrijpen: rapportage, automatisering, ingebouwde relaties, productfuncties, AppExchange-pakketten, en wat Salesforce hierna bouwt. Dat kan enorm waardevol zijn.
Standaardobjecten hebben ook opvattingen: bestaand gedrag, relaties, beveiligingsoverwegingen, soms licentie-eisen, en functies die je niet nodig hebt. Dus “gebruik altijd standaardobjecten” is niet mijn regel. Ik heb geen “altijd”-regel. Ik heb een voorkeur: gebruik het standaardobject als de betekenis een schone fit is en het platformgedrag eromheen het ontwerp helpt in plaats van tegenwerkt. Als ik vijf jaar besteed om een verkoopkans zich te laten gedragen als iets wat geen verkoopkans is, heb ik niets gewonnen door standaard te blijven. Dan heb ik gewoon het verkeerde compromis de andere kant op gemaakt.
Asset is een goed voorbeeld
Section titled “Asset is een goed voorbeeld ”Asset is een van de standaardobjecten die mensen over het hoofd zien. De simpelste manier waarop ik het kan zeggen: het is iets wat de klant heeft. Misschien kochten ze het bij ons, misschien niet. Een product van een concurrent bij mijn klant interesseert me nog steeds, omdat ik het onderhoud, of probeer te vervangen, of hun geïnstalleerde basis moet begrijpen. Als ik Customer_Product__c maak zonder eerst naar Asset te kijken, heb ik een architectuurvraag overgeslagen. Asset wint niet automatisch, maar verdient het om beoordeeld te worden.
Persoonsaccounts: wanneer is de persoon het account?
Section titled “Persoonsaccounts: wanneer is de persoon het account? ”In module 2 maakten we kennis met persoonsaccounts: een account en een contactpersoon in één record, voor klanten die individuen zijn. Nu de beslissing.
Mijn standpunt: voor B2C kun je moeilijk zonder. Er komt zoveel standaard mee met accounts en contactpersonen dat de kosten en overhead het waard zijn. En er zijn kosten: ongeveer twee keer de opslag van een zakelijk account, een schakelaar die je niet meer uit kunt zetten, en sommige externe licenties kunnen er niet mee werken. Partner Community kan niet worden gebruikt met persoonsaccounts (Experience Cloud User Licenses (opens in a new tab), Engels). De vraag is dus niet “hebben we mensen in onze database?” Elke org heeft mensen. Het is “is de persoon in deze business echt het account?” Dat een contactpersoon een persoon is, maakt het nog geen persoonsaccount. De bedrijfsrelatie doet dat.
Laat me nu alles ingewikkelder maken: licenties
Section titled “Laat me nu alles ingewikkelder maken: licenties ”Tot nu toe: vind het concept, zoek de schoonste standaardfit, kies aangepast als de betekenis niet past. Nu de vervolgvraag van de architect: wie moet het gebruiken? Je kunt een prachtig model ontwerpen en dan ontdekken dat de helft van de mensen die de data nodig hebben geen licentie heeft voor de objecten die je koos. Licenties zijn deel van het datamodel.
Drie interne licenties
Section titled “Drie interne licenties ”Begin bij je eigen mensen. Binnen het bedrijf zijn er drie licentietypes die ik elke architect uit het hoofd wil laten kennen, omdat ze bepalen wat elke gebruiker kan zien en doen, en dus waar je datamodel op kan rekenen.
Sales Cloud (nu Agentforce Sales). Deze gebruikers hebben de volledige gebruikerslicentie Salesforce: standaard-CRM-objecten, en elke standaard- of aangepaste app. Dat zijn leads, verkoopkansen en prognoses bovenop accounts en contactpersonen, en zelfs cases: een verkoper kan de openstaande cases van een klant zien voor een gesprek. Campagnes aanmaken en uitvoeren vraagt nog één onderdeel, de functielicentie Marketing User.
Service Cloud (nu Agentforce Service). Dezelfde gebruikerslicentie Salesforce, ingericht voor service. Cases staan centraal, opgepakt in de Service Console: de functielicentie Service Cloud User is wat de Salesforce Console for Service opent. Hier leven de service level agreements, via entitlementbeheer en mijlpalen, en hier komt Knowledge binnen, dat de meeste edities als add-on kopen.
Platform (Salesforce Platform). Voor mensen die je aangepaste apps nodig hebben, niet het CRM. Ze krijgen accounts, contactpersonen, rapporten, dashboards, documenten en elke aangepaste app in de org. Wat ze niet krijgen: prognoses, leads, campagnes en verkoopkansen. Het kost minder, en precies daarom draaien zoveel grote aangepaste apps erop, en precies daarom kan het je datamodel onderuit halen.
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| Gebruikerslicentie | Salesforce | Salesforce | Salesforce Platform |
| Gebouwd voor | Verkopen | Klanten ondersteunen | Aangepaste apps |
| Accounts, contactpersonen | Ja | Ja | Ja |
| Leads, verkoopkansen, prognoses | Ja | Ja | Nee |
| Cases | Ja, om de cases van een klant te zien | Centraal, in de Service Console | Nee |
| Service level agreements | Nee | Ja, entitlements en mijlpalen | Nee |
| Aangepaste objecten en apps | Ja | Ja | Ja |
Lees de tabel zoals een architect dat doet. Als een grote groep gebruikers op Platform zit, is elk ontwerp dat hun werk op een verkoopkans zet al kapot voordat het begint. Als leidinggevenden SLA-cijfers nodig hebben, bepaalt hun licentie of ze die kunnen zien. Deze drie types sturen gedrag.
Als de licentie het object kiest
Section titled “Als de licentie het object kiest ”De verkoopkans is het slachtoffer dat ik het vaakst ben tegengekomen. Je zag het in de tabel: Platform-gebruikers krijgen hem niet (Standard User Licenses (opens in a new tab), Engels), en Customer Community-gebruikers kunnen er ook niet mee werken. Dus de eis lijkt op een verkoopkans, iemand zegt “laten we Opportunity gebruiken”, en dan vraag ik wie er toegang toe nodig heeft. Als een grote groep op Platform- of Customer Community-licenties zit, is de licentie geen inkoopdetail meer. Het is een architecturale beperking, en die duwt het ontwerp meestal richting een aangepast object.
Het werkt ook naar boven. In de klas vraag ik: de CEO wil mooie dashboards; Sales-licentie of Service? Een Sales-gebruiker kan de salesobjecten zien en zelfs cases, dus voor salesdashboards en het aantal open cases is Sales prima. Maar zodra de bestuurder SLA-KPI’s wil (hoe lang tot een case zijn serviceniveau overschrijdt), zit die data in entitlements en milestones, en entitlementbeheer vraagt Agentforce Service, voorheen Service Cloud (Supported Editions for Service Features (opens in a new tab), Engels). Nu ben je de licenties van de bestuurders aan het upgraden. Luister naar de bedrijfseis, en weet welke licentie onder de data zit die ze nodig heeft.
Het stadion
Section titled “Het stadion ”Ik zie licenties als stoelen in een stadion. Iedereen kijkt naar dezelfde wedstrijd. Als ik de dure stoelen in het midden koop, zie ik beide teams van dichtbij. Als ik boven in de hoek op de tribune zit, zijn de stoelen niet gestoffeerd en kijk ik door een verrekijker.
Dat zijn de externe licenties, voor mensen buiten het bedrijf: klanten en partners die inloggen op een Experience Cloud-site. Er zijn er drie die ik je wil laten kennen.
Customer Community: de tribune. Gebouwd voor grote aantallen externe gebruikers die cases en knowledge nodig hebben: een klant die zijn supportcase bekijkt. De stoelen kosten ongeveer de helft en kunnen naar enorme aantallen gebruikers. Wat mis je daarboven? Rapporten, dashboards en de share-tabel: het delen op basis van rollen dat de hogere niveaus krijgen. Het werkt wel met persoonsaccounts.
Customer Community Plus: ongeveer halverwege naar beneden. Salesforce beschrijft het als de licentie voor externe gebruikers die rapporten, dashboards en standaard delen nodig hebben: een klant die de toegang van andere mensen beheert, of zijn cijfers moet zien.
Partner Community: nog dichterbij, voor business-to-business, met toegang tot salesdata. Partners werken met leads en verkoopkansen: ze registreren deals, en ze voeren samen met jou campagnes uit. Dat is de externe stoel die de salesobjecten bereikt. Eén addertje: het kan niet worden gebruikt met persoonsaccounts (Experience Cloud User Licenses (opens in a new tab), Engels).
De fout is ontwerpen alsof iedereen het dure kaartje heeft, en dan bij de implementatie ontdekken dat de meeste gebruikers niet in het vak kunnen komen waar je hun data neerzette. Dan heb je drie keuzes: andere stoelen kopen, de ervaring verplaatsen of het model herontwerpen. Alle drie zijn architectuur.
Hoe ze betalen verandert het ontwerp
Section titled “Hoe ze betalen verandert het ontwerp ”Er is nog een vraag die mensen vergeten: hoe gaan deze gebruikers inloggen? Externe licenties zijn er in twee vormen. Member-based: je betaalt per gebruiker, wat past bij 500 partners die elke dag inloggen. Login-based: je koopt een aantal logins per maand, wat past bij vijf miljoen klanten die een paar keer per jaar inloggen. Meer dan eens op dezelfde dag inloggen telt nog steeds als één login (Experience Cloud User Licenses (opens in a new tab), Engels).
Dus als iemand zegt “we bouwen een klantportaal”, is mijn volgende vraag niet welk template. Het is: wie zijn de klanten, hoeveel zijn het er, hoe vaak komen ze, welke data hebben ze nodig, en wat mogen ze ermee doen?
Als de licentie het model vormt
Section titled “Als de licentie het model vormt ”Soms kiest de licentie niet alleen het object; ze buigt het hele model. Sommige platformlicenties beperken gebruikers tot één aangepaste app van maximaal tien aangepaste objecten (bijvoorbeeld Lightning Platform – One App; Standard User Licenses (opens in a new tab), Engels).
Op een vroeg project, voor een groot bedrijf in professionele dienstverlening en bouw, moesten we zoiets als LinkedIn bouwen voor het hele personeel: ieders functies, vaardigheden, certificeringen, talen en projecten, zodat ze de bruggenbouwer konden vinden die in een bepaald land gecertificeerd was. Zonder limiet had ik een object gebruiker-functie, gebruiker-vaardigheid, gebruiker-certificering, gebruiker-taal en gebruiker-project gebouwd, plus referentielijsten met certificeringen en projecten. Onder een licentie van tien objecten, en met de opdracht ze niet allemaal op te maken, kon dat niet. Dus werd het “met hoeveel noten raad je het liedje”: met hoe weinig objecten kan ik dit bouwen? Het antwoord was twee. Eén referentieobject, met een recordtype voor elk soort lijst (functie, vaardigheid, certificering, taal, project), en één object gebruikersattribuut, met bijpassende recordtypen, dat ernaar verwijst.
Het was niet het optimale model. Het was lastig om over te rapporteren, en ik had het liever schoner gehad. Maar dat was wat de licentie toestond. Ik noem deze Zwitsersezakmesobjecten: houd het patroon achter de hand, en als de limieten geen ruimte laten, sla het glas in en kies scheiding via recordtypen. Weet alleen wat je inlevert. Verschillende rechten per recordtype kunnen je dwingen het object alsnog te splitsen.
Mensen zijn niet meer de enige gebruikers
Section titled “Mensen zijn niet meer de enige gebruikers ”Er is nog een licentievraag belangrijk geworden: hoe zit het met de dingen die geen mensen zijn? Integraties hebben identiteiten. Agents hebben identiteiten. Salesforce heeft nu een licentie Salesforce Integration voor integraties van systeem tot systeem: alleen API, niet voor mensen, waarvan er vijf inbegrepen zijn in elke org met Enterprise, Unlimited of Performance Edition (Standard User Licenses (opens in a new tab), Engels). Vraag dus niet alleen welke gebruikers toegang nodig hebben. Vraag welke identiteiten toegang nodig hebben: een persoon, een klant, een partner, een integratie, een agent. En dan wat elk ervan moet zien en doen.
Voorbij het examen: wat AI verandert. Nu agents een nieuwe gebruiker en maker van data worden, gaan objectkeuze en licenties niet alleen meer over schermen voor mensen. Weet onder welke identiteit de agent draait, wat die identiteit kan bereiken, en of het model de data die de agent nodig heeft achter een object of recht zet dat de agent niet kan gebruiken.
Steve Trucking: een makkelijke en een moeilijke
Section titled “Steve Trucking: een makkelijke en een moeilijke ”Steve Trucking werkt met retailpartners. Wat is een retailpartner? Een bedrijf. Makkelijk: account. Ik maak geen Retail_Partner__c omdat iemand het woord “partner” gebruikte.
Nu de ontvanger, de persoon die de koelkast ontvangt. Contactpersoon? Persoonsaccount? Iets anders? Een miljoen nieuwe ontvangers per jaar, die klanten van de retailpartners zijn, niet van ons. Dat is precies het soort vraag waarbij ik niet naar een object wil springen voordat ik de relatie, de toegang en de schaal begrijp. We beslissen het bij het checkpoint van deel 1.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Of een bedrijfsconcept netjes past bij het bedoelde doel van een standaardobject, of dat zijn betekenis of gewicht anders is.
- Of verschillende bedrijfslabels verschillende entiteiten zijn, of gewoon verschillende rollen van dezelfde.
- Of elke persoon, externe gebruiker, integratie en agent die de data nodig heeft het gekozen object kan bereiken onder de geplande licenties.
- Hoe de groep en het inlogpatroon (member-based of login-based) de licentie en het model vormen.
- Wanneer een licentielimiet een minder dan optimaal model rechtvaardigt, en wat die afweging kost aan rapportage en rechten.
Het punt is niet dat standaardobjecten goed zijn en aangepaste objecten slecht. Het is dat de keuze gevolgen heeft, en soms helemaal niet door het zelfstandig naamwoord wordt bepaald, maar door de mensen, en de machines, die het moeten gebruiken.
Verder lezen
Section titled “Verder lezen ”- Salesforce Help, Standard User Licenses (opens in a new tab) (Engels), gecontroleerd op 2026-10-02, opnieuw gecontroleerd op 2026-10-12: Platform-gebruikers hebben geen recht op prognoses, leads, campagnes en verkoopkansen; één aangepaste app met maximaal 10 aangepaste objecten; vijf Salesforce Integration-licenties in elke org met Enterprise Edition.
- Salesforce Help, Experience Cloud User Licenses (opens in a new tab) (Engels), gecontroleerd op 2026-10-02, opnieuw gecontroleerd op 2026-10-12: Partner Community kan niet worden gebruikt met persoonsaccounts; Customer Community Plus voor rapporten, dashboards en standaard delen; meerdere logins op één dag tellen als één.
- Salesforce Help, Supported Editions for Service Features (opens in a new tab) (Engels), gecontroleerd op 2026-10-02, opnieuw gecontroleerd op 2026-10-12: service level agreements (entitlementbeheer) met Agentforce Service; Knowledge tegen meerprijs in de meeste edities.
- Salesforce Help, Available Feature Licenses (opens in a new tab) (Engels), gecontroleerd op 2026-10-12: Service Cloud User, “Access the Salesforce Console for Service”; Marketing User voor het aanmaken en beheren van campagnes.