Vælg det rigtige objekt

🌐 Findes også på 28 sprog

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 5 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Hvor bor disse data? · Næste: Felter er også arkitektur

Spørgsmålet, dette modul besvarer: Hvilken slags Salesforce-objekt skal dette forretningsbegreb blive til, og hvad tillader licenserne?

Noget af det nemmeste i Salesforce er at oprette et brugerdefineret objekt. Det er præcis derfor, jeg mener, vi opretter for mange af dem.

Du sidder i et kravmøde, og nogen siger: »Vi skal kunne holde styr på vores distributører.« Nyt brugerdefineret objekt: Distributor. Færdig. Bortset fra at jeg gerne vil have, at arkitekten først stiller et andet spørgsmål: Hvad er en distributør? Det er en virksomhed. Salesforce har allerede en ret god måde at repræsentere en virksomhed på. Den hedder konto (Account). Det betyder ikke, at svaret altid er konto. Men hvis jeg skal forklare, hvorfor en virksomhed ikke er en konto, vil jeg have en bedre grund end »forretningen kalder dem distributører«.

Det er her, den logiske model fra kapitel 2 møder platformen, og mit udgangspunkt er enkelt: Hvis forretningsbegrebet passer rent til det tilsigtede formål med et standardobjekt, så start der.

Start med betydningen

Selv når noget fortjener at blive et objekt, fortjener det ikke automatisk at blive et brugerdefineret objekt. Spørg, hvad tingen egentlig repræsenterer. En virksomhed eller organisation af enhver art? Start med konto. En person, der arbejder sammen med den organisation? Kontakt. Noget, en kunde ejer eller har købt? Aktiv (Asset). Noget, du prøver at sælge? Så hører salgsmulighed (Opportunity) med i samtalen.

Derfor kiggede vi på moderskibet først, i modul 2. De modeller passer ikke til enhver forretning, men vi skal ikke ignorere dem, fordi det føles renere at bygge vores eget. Før New Custom Object, så spørg, hvordan Salesforce modellerer dette begreb, hvad der er bygget omkring den model, og hvad du ville opgive ved at erstatte den.

Testen for rent match

Min test er ét spørgsmål: Passer dette forretningsbegreb rent til standardobjektets tilsigtede formål? Hvis det gør, hælder jeg mod standardobjektet.

En distributør er en virksomhed, vi har en relation til, så konto passer rent. Jeg har ikke noget imod, at brugerne kalder én virksomhed en distributør, en anden en leverandør, en tredje en detailpartner og en fjerde en kunde. Det er forretningsroller, og de behøver ikke fire fysiske objekter. Forskellige forretningsnavne betyder ikke automatisk forskellige datastrukturer. En type, en posttype eller en relation kan bære forskellen.

Testen virker også den anden vej. I kapitel 1 efterlod jeg dig med et spørgsmål: En kundes virksomhed har mange leveringsadresser. Skal hver adresse være en konto eller et brugerdefineret objekt?

En konto giver dig meget. Du får adressefelterne og alt det, der allerede forventer en kontoadresse: rapporter, kort, integrationer. Men du får også overhead: en masse felter, deling, hierarki, ejerskab, alt det, der hænger på en konto, og det meste af det er ikke relevant for en separat adresse. Du ville slæbe rundt på en masse tunge ting, du ikke bruger, bare for en alternativ adresse.

Et brugerdefineret objekt, et barn af kontoen, kan være let: bare adressefelterne, et sted vi leverer til, med sin egen livscyklus, som jeg kan styre uafhængigt.

Så det er en balance: den vægt, du påtager dig, over for den værdi, du får. Hvis alt, hvad jeg har brug for, er en adresse med sin egen livscyklus, så er det dér, jeg går brugerdefineret.

Det samme med underproblemer på en sag. Hvis hvert underproblem virkelig er en sag, som en medarbejder arbejder på, med egen status og eget serviceniveau, så indlejr dem med Parent Case fra modul 2. Men hvis det bare er et punkt på en tjekliste, som ingen arbejder på som en sag, slæber en fuld sag rundt på meget, den aldrig bruger, og et simpelt brugerdefineret barn kan veje mindre. Ikke fordi brugerdefineret er renere. Men fordi betydningen er en anden, eller vægten er forkert.

Standardobjekter kommer med bagage

Når du vælger et standardobjekt, vælger du mere end dets felter. Du vælger noget, Salesforces produkter allerede forstår: rapportering, automatisering, indbyggede relationer, produktfunktioner, AppExchange-pakker og hvad end Salesforce bygger næste gang. Det kan være enormt værdifuldt.

Standardobjekter kommer også med holdninger: eksisterende adfærd, relationer, sikkerhedshensyn, nogle gange licenskrav og funktioner, du ikke har brug for. Så »brug altid standardobjekter« er ikke min regel. Jeg har ingen »altid«-regel. Jeg har en tilbøjelighed: Brug standardobjektet, når betydningen passer rent, og platformsadfærden omkring det hjælper designet i stedet for at kæmpe imod det. Hvis jeg bruger fem år på at få salgsmulighed til at opføre sig som noget, der ikke er en salgsmulighed, har jeg ikke vundet noget ved at holde mig til standarden. Jeg har bare indgået det forkerte kompromis i den anden retning.

Aktiv er et godt eksempel

Aktiv (Asset) er et af de standardobjekter, folk overser. Den enkleste måde, jeg kan sige det på: Det er en ting, kunden har. Måske har de købt den af os, måske ikke. Jeg interesserer mig stadig for en konkurrents produkt, der står hos min kunde, fordi jeg servicerer det eller prøver at erstatte det, eller fordi jeg skal forstå deres installerede base. Hvis jeg opretter Customer_Product__c uden først at se på aktiv, har jeg sprunget et arkitektonisk spørgsmål over. Aktiv vinder ikke automatisk, men det fortjener at blive vurderet.

Personkonti: hvornår er personen kontoen?

I modul 2 mødte vi personkonti: en konto og en kontakt i én post, til kunder, der er enkeltpersoner. Nu kommer beslutningen.

Min holdning: Til B2C er det svært at undvære dem. Der følger så meget med konti og kontakter, at omkostningen og overheaden er det værd. Og der er en omkostning: cirka dobbelt så meget lagerplads som en erhvervskonto, en kontakt, du ikke kan slå fra, og nogle eksterne licenser kan ikke bruge dem. Partner Community kan ikke bruges med personkonti (Experience Cloud User Licenses (opens in a new tab)). Så spørgsmålet er ikke »har vi personer i vores database?« Alle org’er har personer. Det er »er personen faktisk kontoen i denne forretning?« At en kontakt er en person, gør den ikke til en personkonto. Det gør forretningsrelationen.

Click to enlarge

Lad mig så gøre det hele mere kompliceret: licenser

Indtil videre: Find begrebet, se efter det reneste standardmatch, og gå brugerdefineret, når betydningen ikke passer. Nu kommer arkitektens opfølgende spørgsmål: Hvem skal bruge det? Du kan designe en smuk model og så opdage, at halvdelen af de mennesker, der har brug for dataene, ikke har licens til de objekter, du valgte. Licenser er en del af datamodellen.

Tre interne licenser

Start med dine egne folk. Inde i virksomheden er der tre licenstyper, jeg vil have, at enhver arkitekt kender på rygmarven, fordi de styrer, hvad hver bruger kan se og gøre, og dermed hvad din datamodel kan regne med.

Sales Cloud (nu Agentforce Sales). Disse brugere har den fulde Salesforce-brugerlicens: CRM-standardobjekterne og enhver standard- eller brugerdefineret app. Det er kundeemner, salgsmuligheder og prognoser oven i konti og kontakter, og endda sager: En sælger kan se en kundes åbne sager før et opkald. At oprette og køre kampagner kræver én ting mere, feature-licensen Marketing User.

Service Cloud (nu Agentforce Service). Den samme Salesforce-brugerlicens, sat op til service. Sager står i centrum og håndteres i Service Console: Det er feature-licensen Service Cloud User, der åbner Salesforce Console for Service. Det er her, serviceniveauaftaler (SLA’er) bor, gennem entitlement management og milepæle, og det er her, Knowledge kommer ind, som de fleste udgaver køber som tilkøb.

Platform (Salesforce Platform). Til folk, der har brug for dine brugerdefinerede apps, ikke CRM. De får konti, kontakter, rapporter, dashboards, dokumenter og alle brugerdefinerede apps i org’en. Hvad de ikke får: prognoser, kundeemner, kampagner og salgsmuligheder. Den koster mindre, og det er præcis derfor, så mange store brugerdefinerede apps kører på den, og præcis derfor den kan spænde ben for din datamodel.

	Sales Cloud	Service Cloud	Platform
Brugerlicens	Salesforce	Salesforce	Salesforce Platform
Bygget til	Salg	Kundesupport	Brugerdefinerede apps
Konti, kontakter	Ja	Ja	Ja
Kundeemner, salgsmuligheder, prognoser	Ja	Ja	Nej
Sager	Ja, for at se en kundes sager	I centrum, i Service Console	Nej
Serviceniveauaftaler	Nej	Ja, berettigelser og milepæle	Nej
Brugerdefinerede objekter og apps	Ja	Ja	Ja

Læs tabellen, som en arkitekt gør. Hvis en stor gruppe brugere er på Platform, er ethvert design, der lægger deres arbejde på en salgsmulighed, i stykker, før det er begyndt. Hvis direktionen har brug for SLA-tal, afgør den licens, de er på, om de kan se dem. Disse tre typer styrer adfærden.

Click to enlarge

Når licensen bestemmer objektet

Salgsmulighed er det offer, jeg oftest er stødt på. Du så det i tabellen: Platform-brugere får den ikke (Standard User Licenses (opens in a new tab)), og Customer Community-brugere kan heller ikke arbejde med den. Så kravet ligner en salgsmulighed, nogen siger »lad os bruge salgsmulighed«, og så spørger jeg, hvem der skal have adgang. Hvis en stor gruppe er på Platform- eller Customer Community-licenser, er licensen ikke længere en indkøbsdetalje. Den er en arkitektonisk begrænsning, og den skubber som regel designet mod et brugerdefineret objekt.

Det virker også opad. I klassen spørger jeg: Direktøren vil have flotte dashboards; Sales-licens eller Service? En Sales-bruger kan se salgsobjekterne og endda sager, så til salgsdashboards og antal åbne sager er Sales fint. Men i det øjeblik direktøren vil have SLA-KPI’er (hvor længe der går, før en sag bryder sit serviceniveau), ligger de data i berettigelser og milepæle, og entitlement management kræver Agentforce Service, tidligere Service Cloud (Supported Editions for Service Features (opens in a new tab)). Nu skal du opgradere direktionens licenser. Lyt til forretningskravet, og vid, hvilken licens der ligger under de data, det har brug for.

Stadionet

Jeg tænker på licenser som pladser på et stadion. Alle ser den samme kamp. Køber jeg de dyre pladser i midten, kan jeg se begge hold helt tæt på. Sidder jeg oppe i hjørnet på de billige rækker, er sæderne ikke polstrede, og jeg ser kampen gennem en kikkert.

Det er de eksterne licenser, til folk uden for virksomheden: kunder og partnere, der logger ind på et Experience Cloud-site. Der er tre, jeg vil have, at du kender.

Customer Community: de billige rækker. Bygget til store mængder eksterne brugere, der har brug for sager og vidensartikler: en kunde, der tjekker sin supportsag. Pladserne koster cirka det halve og kan gå til enorme mængder brugere. Hvad mister du deroppe? Rapporter, dashboards og delingstabellen: den rollebaserede deling, som de højere niveauer får. Den fungerer med personkonti.

Customer Community Plus: cirka halvvejs nede. Salesforce beskriver den som licensen til eksterne brugere, der har brug for rapporter og dashboards og standarddeling: en kunde, der styrer andres adgang eller skal kunne se sine tal.

Partner Community: endnu tættere på, til business-to-business, med adgang til salgsdata. Partnere arbejder med kundeemner og salgsmuligheder: De registrerer handler, og de kører kampagner sammen med dig. Det er den eksterne plads, der når salgsobjekterne. Én hage: Den kan ikke bruges med personkonti (Experience Cloud User Licenses (opens in a new tab)).

Click to enlarge

Fejlen er at designe, som om alle har den dyre billet, og så opdage ved implementeringen, at de fleste af dine brugere ikke kan komme ind i den sektion, hvor du har lagt deres data. Så har du tre valg: købe andre pladser, flytte oplevelsen eller designe modellen om. Alle tre er arkitektur.

Hvordan de betaler, ændrer designet

Der er et andet spørgsmål, folk glemmer: Hvordan skal disse brugere logge ind? Eksterne licenser findes i to former. Medlemsbaseret (member-based): Du betaler pr. bruger, hvilket passer til 500 partnere, der logger ind hver dag. Login-baseret (login-based): Du køber et antal logins pr. måned, hvilket passer til fem millioner kunder, der logger ind et par gange om året. Flere logins på samme dag tæller stadig som ét login (Experience Cloud User Licenses (opens in a new tab)).

Så når nogen siger »vi bygger en kundeportal«, er mit næste spørgsmål ikke, hvilken skabelon. Det er: Hvem er kunderne, hvor mange er der, hvor tit kommer de, hvilke data har de brug for, og hvad må de gøre med dem?

Når licensen former modellen

Nogle gange vælger licensen ikke bare objektet; den bøjer hele modellen. Nogle platformslicenser begrænser brugerne til én brugerdefineret app med op til ti brugerdefinerede objekter (for eksempel Lightning Platform – One App; Standard User Licenses (opens in a new tab)).

På et tidligt projekt for en stor rådgivnings- og entreprenørvirksomhed skulle vi bygge noget i stil med LinkedIn for hele arbejdsstyrken: alles jobs, kompetencer, certificeringer, sprog og projekter, så de kunne finde brobyggeren med certificering i et bestemt land. Uden en grænse ville jeg have bygget et objekt for bruger-job, bruger-kompetence, bruger-certificering, bruger-sprog og bruger-projekt plus referencelister over certificeringer og projekter. Med en licens på ti objekter, og med besked om ikke at bruge dem alle, var det ikke muligt. Så det blev til »gæt en melodi«: Hvor få objekter kan jeg bygge det her med? Svaret var to. Ét referenceobjekt med en posttype for hver slags liste (job, kompetence, certificering, sprog, projekt) og ét objekt til brugerattributter med tilsvarende posttyper, der pegede på det.

Det var ikke den optimale model. Det var besværligt at rapportere på, og jeg ville have foretrukket den renere. Men det var det, licensen tillod. Jeg kalder dem schweizerkniv-objekter: Hav mønsteret i baglommen, og når grænserne ikke giver plads, så slå glasset i stykker og gå til adskillelse med posttyper. Bare vid, hvad du bytter væk. Forskellige tilladelser pr. posttype kan alligevel tvinge dig til at dele objektet.

Mennesker er ikke længere de eneste brugere

Et licensspørgsmål mere er blevet vigtigt: Hvad med de ting, der ikke er mennesker? Integrationer har identiteter. Agenter har identiteter. Salesforce har nu en Salesforce Integration-licens til integrationer mellem systemer: kun API, ikke til mennesker, med fem inkluderet i hver org med Enterprise, Unlimited og Performance Edition (Standard User Licenses (opens in a new tab)). Så spørg ikke bare, hvilke brugere der skal have adgang. Spørg, hvilke identiteter der skal have adgang: en person, en kunde, en partner, en integration, en agent. Og derefter hvad hver af dem skal kunne se og gøre.

Ud over eksamen: hvad AI ændrer. Efterhånden som agenter bliver endnu en forbruger og skaber af data, handler objektvalg og licenser ikke kun om skærme til mennesker. Vid, hvilken identitet agenten kører som, hvad den identitet kan nå, og om modellen lægger de data, den har brug for, bag et objekt eller en tilladelse, den ikke kan bruge.

Steve Trucking: en nem og en svær

Steve Trucking arbejder sammen med detailpartnere (Retail Partners). Hvad er en detailpartner? En virksomhed. Nemt: konto. Jeg opretter ikke Retail_Partner__c, fordi nogen brugte ordet »partner«.

Så er der modtageren (Recipient), personen, der modtager køleskabet. Kontakt? Personkonto? Noget helt tredje? En million nye modtagere om året, som er detailpartnernes kunder, ikke vores. Det er præcis den slags spørgsmål, hvor jeg ikke vil springe til et objekt, før jeg forstår relationen, adgangen og skalaen. Vi beslutter det ved kontrolpunktet for del 1.

Hvad en arkitekt beslutter her

• Om et forretningsbegreb passer rent til det tilsigtede formål med et standardobjekt, eller om dets betydning eller vægt er en anden.
• Om forskellige forretningsbetegnelser er forskellige enheder eller bare forskellige roller for den samme.
• Om hver person, ekstern bruger, integration og agent, der har brug for dataene, kan nå det valgte objekt med de planlagte licenser.
• Hvordan antallet af brugere og deres loginmønster (medlemsbaseret eller login-baseret) former licensen og modellen.
• Hvornår en licensgrænse retfærdiggør en mindre end optimal model, og hvad den afvejning koster i rapportering og tilladelser.

Pointen er ikke, at standardobjekter er gode og brugerdefinerede objekter dårlige. Det er, at valget har konsekvenser, og at det nogle gange slet ikke afgøres af navneordet, men af de mennesker, og de maskiner, der skal bruge det.

Læs mere

• Salesforce Help, Standard User Licenses (opens in a new tab), på engelsk, kontrolleret 2026-10-02, genkontrolleret 2026-10-12: Platform-brugere har ikke ret til prognoser, kundeemner, kampagner og salgsmuligheder; én brugerdefineret app med op til 10 brugerdefinerede objekter; fem Salesforce Integration-licenser i hver org med Enterprise Edition.
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab), på engelsk, kontrolleret 2026-10-02, genkontrolleret 2026-10-12: Partner Community kan ikke bruges med personkonti; Customer Community Plus til rapporter, dashboards og standarddeling; flere logins på én dag tæller som ét.
• Salesforce Help, Supported Editions for Service Features (opens in a new tab), på engelsk, kontrolleret 2026-10-02, genkontrolleret 2026-10-12: serviceniveauaftaler (entitlement management) med Agentforce Service; Knowledge koster ekstra i de fleste udgaver.
• Salesforce Help, Available Feature Licenses (opens in a new tab), på engelsk, kontrolleret 2026-10-12: Service Cloud User, adgang til Salesforce Console for Service (»Access the Salesforce Console for Service«); Marketing User til at oprette og administrere kampagner.