Velg riktig objekt
Finnes også på 28 språk
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 · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 5 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Forrige: Hvor bor disse dataene? · Neste: Felt er også arkitektur
Spørsmålet denne modulen besvarer: Hva slags Salesforce-objekt skal dette forretningsbegrepet bli, og hva tillater lisensene?
Noe av det enkleste du kan gjøre i Salesforce, er å lage et egendefinert objekt. Det er nettopp derfor jeg mener vi lager for mange av dem.
Du sitter i et kravmøte, og noen sier: «Vi må holde oversikt over distributørene våre.» Nytt egendefinert objekt: Distributor. Ferdig. Bortsett fra at jeg vil at arkitekten skal stille et annet spørsmål først: hva er en distributør? Det er et firma. Salesforce har allerede en ganske god måte å representere et firma på. Det heter konto (Account). Det betyr ikke at svaret alltid er Account. Men må jeg forklare hvorfor et firma ikke er en konto, vil jeg ha en bedre grunn enn «forretningen kaller dem distributører».
Det er her den logiske modellen fra kapittel 2 møter plattformen, og utgangspunktet mitt er enkelt: passer forretningsbegrepet rent til det tiltenkte formålet med et standardobjekt, så begynn der.
Begynn med meningen
Section titled “Begynn med meningen ”Selv når noe fortjener å bli et objekt, fortjener det ikke automatisk å bli et egendefinert objekt. Spør hva tingen faktisk representerer. En virksomhet eller organisasjon av noe slag? Begynn med Account. En person som jobber med den organisasjonen? Contact. Noe en kunde eier eller har kjøpt? Asset. Noe du prøver å selge? Nå hører Opportunity hjemme i samtalen.
Det er derfor vi så til moderskipet først, i modul 2. De modellene passer ikke for alle virksomheter, men vi bør ikke overse dem fordi det føles ryddigere å bygge vårt eget. Før New Custom Object: spør hvordan Salesforce modellerer dette begrepet, hva som er bygd rundt den modellen, og hva du ville gitt opp ved å erstatte den.
Testen for ren passform
Section titled “Testen for ren passform ”Testen min er ett spørsmål: passer dette forretningsbegrepet rent til det tiltenkte formålet med standardobjektet? Gjør det det, heller jeg mot standardobjektet.
En distributør er et firma vi har en relasjon til, så Account passer rent. Jeg har ikke noe imot at brukerne kaller ett firma en distributør, et annet en leverandør, et tredje en detaljhandelspartner og et fjerde en kunde. Det er forretningsroller, og de trenger ikke fire fysiske objekter. Forskjellige forretningsnavn betyr ikke automatisk forskjellige datastrukturer. En type, en posttype eller en relasjon kan bære forskjellen.
Testen virker den andre veien også. I kapittel 1 etterlot jeg deg med et spørsmål: en kundes virksomhet har mange leveringsadresser. Skal hver adresse være en konto, eller et egendefinert objekt?
En konto gir deg mye. Du får adressefeltene, og alt som allerede forventer en kontoadresse: rapporter, kart, integrasjoner. Men du får også overheaden: mange felt, deling, hierarki, eierskap, alt som henger på en konto, og det meste er ikke relevant for en separat adresse. Du ville båret på mye tungt du ikke kommer til å bruke, bare for en alternativ adresse.
Et egendefinert objekt, et barn av kontoen, kan være lett: bare adressefeltene, et sted vi leverer til, med sin egen livssyklus som jeg kan styre uavhengig.
Så det er en balanse: vekten du tar på deg mot verdien du får. Trenger jeg bare en adresse med sin egen livssyklus, er det der jeg går for egendefinert.
Det samme med underproblemer på en sak. Er hvert underproblem virkelig en sak, jobbet med av en saksbehandler, med egen status og eget servicenivå, så legg dem under hverandre med Parent Case fra modul 2. Men er det bare et sjekklistepunkt ingen jobber med som en sak, bærer en full sak mye den aldri kommer til å bruke, og et enkelt egendefinert barn kan veie mindre. Ikke fordi egendefinert er ryddigere. Fordi meningen er en annen, eller vekten er feil.
Standardobjekter kommer med bagasje
Section titled “Standardobjekter kommer med bagasje ”Når du velger et standardobjekt, velger du mer enn feltene. Du velger noe Salesforces produkter allerede forstår: rapportering, automatisering, innebygde relasjoner, produktfunksjoner, AppExchange-pakker og det Salesforce bygger neste gang. Det kan være enormt verdifullt.
Standardobjekter kommer også med meninger: eksisterende oppførsel, relasjoner, sikkerhetshensyn, noen ganger lisenskrav, og funksjoner du ikke trenger. Så «bruk alltid standardobjekter» er ikke regelen min. Jeg har ingen «alltid»-regel. Jeg har en tilbøyelighet: bruk standardobjektet når meningen passer rent og plattformoppførselen rundt det hjelper designet i stedet for å kjempe imot. Bruker jeg fem år på å få Opportunity til å oppføre seg som noe som ikke er en salgsmulighet, har jeg ikke vunnet noe på å holde meg til standard. Jeg har bare inngått feil kompromiss i motsatt retning.
Aktivum er et godt eksempel
Section titled “Aktivum er et godt eksempel ”Aktivum (Asset) er et av standardobjektene folk overser. Enklest sagt: det er en ting kunden har. Kanskje de kjøpte den av oss, kanskje ikke. Jeg bryr meg likevel om en konkurrents produkt som står hos kunden min, fordi jeg gir service på det, eller prøver å erstatte det, eller trenger å forstå den installerte basen deres. Lager jeg Customer_Product__c uten å se på Asset først, har jeg hoppet over et arkitekturspørsmål. Asset vinner ikke automatisk, men det fortjener å bli vurdert.
Personkontoer: når er personen kontoen?
Section titled “Personkontoer: når er personen kontoen? ”I modul 2 møtte vi personkontoer: en konto og en kontakt i én post, for kunder som er enkeltpersoner. Nå kommer beslutningen.
Mitt standpunkt: for B2C er det vanskelig å klare seg uten dem. Så mye følger med konto og kontakt fra start at kostnaden og overheaden er verdt det. Og det finnes en kostnad: omtrent dobbelt så mye lagring som en bedriftskonto, en bryter du ikke kan slå av, og noen eksterne lisenser kan ikke bruke dem. Partner Community kan ikke brukes med personkontoer (Experience Cloud User Licenses (opens in a new tab)). Så spørsmålet er ikke «har vi personer i databasen vår?» Hver org har personer. Det er «er personen faktisk kontoen i denne virksomheten?» At en kontakt er en person, gjør den ikke til en personkonto. Det er forretningsrelasjonen som gjør det.
Nå skal jeg gjøre alt mer komplisert: lisenser
Section titled “Nå skal jeg gjøre alt mer komplisert: lisenser ”Så langt: finn begrepet, se etter den reneste passformen blant standardobjektene, gå for egendefinert når meningen ikke passer. Nå arkitektens oppfølgingsspørsmål: hvem trenger å bruke det? Du kan designe en vakker modell og så oppdage at halvparten av dem som trenger dataene, ikke har lisens til objektene du valgte. Lisenser er en del av datamodellen.
Tre interne lisenser
Section titled “Tre interne lisenser ”Begynn med dine egne folk. Internt i bedriften finnes det tre lisenstyper jeg vil at hver arkitekt skal kunne på rams, fordi de styrer hva hver bruker kan se og gjøre, og dermed hva datamodellen din kan regne med.
Sales Cloud (nå Agentforce Sales). Disse brukerne har den fulle Salesforce-brukerlisensen: standard CRM-objekter og enhver standard eller egendefinert app. Det er kundeemner, salgsmuligheter og prognoser i tillegg til kontoer og kontakter, og til og med saker: en selger kan se en kundes åpne saker før en samtale. Å opprette og kjøre kampanjer krever én brikke til, funksjonslisensen Marketing User.
Service Cloud (nå Agentforce Service). Den samme Salesforce-brukerlisensen, satt opp for service. Saker står i sentrum, og de jobbes med i Service Console: funksjonslisensen Service Cloud User er det som åpner Salesforce Console for Service. Det er her tjenestenivåavtaler (SLA-er) bor, gjennom rettighetsstyring (entitlement management) og milepæler, og her Knowledge kommer inn, som de fleste utgaver kjøper som et tillegg.
Platform (Salesforce Platform). For folk som trenger de egendefinerte appene dine, ikke CRM-et. De får kontoer, kontakter, rapporter, dashbord, dokumenter og hver egendefinert app i orgen. Det de ikke får: prognoser, kundeemner, kampanjer og salgsmuligheter. Den koster mindre, og det er nettopp derfor så mange store egendefinerte apper kjører på den, og nettopp derfor den kan ta datamodellen din på senga.
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| Brukerlisens | Salesforce | Salesforce | Salesforce Platform |
| Laget for | Salg | Kundestøtte | Egendefinerte apper |
| Kontoer, kontakter | Ja | Ja | Ja |
| Kundeemner, salgsmuligheter, prognoser | Ja | Ja | Nei |
| Saker | Ja, for å se en kundes saker | I sentrum, i Service Console | Nei |
| Tjenestenivåavtaler | Nei | Ja, rettigheter og milepæler | Nei |
| Egendefinerte objekter og apper | Ja | Ja | Ja |
Les tabellen slik en arkitekt gjør. Er en stor gruppe brukere på Platform, er ethvert design som legger arbeidet deres på en salgsmulighet, ødelagt før det starter. Trenger ledelsen SLA-tall, avgjør lisensen de har, om de kan se dem. Disse tre typene styrer oppførselen.
Når lisensen bestemmer objektet
Section titled “Når lisensen bestemmer objektet ”Salgsmulighet (Opportunity) er offeret jeg har støtt på oftest. Du så det i tabellen: Platform-brukere får den ikke (Standard User Licenses (opens in a new tab)), og Customer Community-brukere kan heller ikke jobbe med den. Så kravet ser ut som en salgsmulighet, noen sier «la oss bruke Opportunity», og så spør jeg hvem som trenger tilgang. Er en stor gruppe på Platform- eller Customer Community-lisenser, er ikke lisensen en innkjøpsdetalj lenger. Den er en arkitektonisk begrensning, og den skyver som regel designet mot et egendefinert objekt.
Det virker oppover også. På kurs spør jeg: konsernsjefen vil ha pene dashbord; Sales-lisens eller Service? En Sales-bruker kan se salgsobjektene og til og med saker, så for salgsdashbord og antall åpne saker holder Sales fint. Men i det øyeblikket lederen vil ha SLA-KPI-er (hvor lenge til en sak bryter servicenivået sitt), ligger de dataene i rettigheter og milepæler, og rettighetsstyring krever Agentforce Service, tidligere Service Cloud (Supported Editions for Service Features (opens in a new tab)). Nå oppgraderer du ledernes lisenser. Lytt til forretningskravet, og vit hvilken lisens som ligger under dataene det trenger.
Stadionet
Section titled “Stadionet ”Jeg tenker på lisenser som seter på et stadion. Alle ser den samme kampen. Kjøper jeg de dyre setene i midten, ser jeg begge lagene på nært hold. Sitter jeg oppe i hjørnet på ståtribunen, er setene uten pute, og jeg ser kampen gjennom kikkert.
Det er de eksterne lisensene, for folk utenfor bedriften: kunder og partnere som logger inn på et Experience Cloud-nettsted. Det er tre jeg vil at du skal kjenne.
Customer Community: ståtribunen. Laget for store mengder eksterne brukere som trenger saker og kunnskapsartikler: en kunde som sjekker supportsaken sin. Setene koster omtrent halvparten så mye og kan gå til enorme mengder brukere. Hva mister du der oppe? Rapporter, dashbord og delingstabellen: den rollebaserte delingen de høyere nivåene får. Den fungerer med personkontoer.
Customer Community Plus: omtrent halvveis ned. Salesforce beskriver den som lisensen for eksterne brukere som trenger rapporter, dashbord og standard deling: en kunde som styrer andres tilgang, eller trenger å se tallene sine.
Partner Community: enda nærmere, for bedrift-til-bedrift, med tilgang til salgsdata. Partnere jobber med kundeemner og salgsmuligheter: de registrerer avtaler, og de kjører kampanjer sammen med deg. Det er det eksterne setet som når salgsobjektene. Én hake: den kan ikke brukes med personkontoer (Experience Cloud User Licenses (opens in a new tab)).
Feilen er å designe som om alle har den dyre billetten, og så oppdage under implementeringen at de fleste brukerne dine ikke kommer inn i seksjonen der du la dataene deres. Da har du tre valg: kjøpe andre seter, flytte opplevelsen eller designe om modellen. Alle tre er arkitektur.
Hvordan de betaler, endrer designet
Section titled “Hvordan de betaler, endrer designet ”Det finnes et annet spørsmål folk glemmer: hvordan skal disse brukerne logge inn? Eksterne lisenser kommer i to former. Medlemsbasert (member-based): du betaler per bruker, noe som passer for 500 partnere som logger inn hver dag. Innloggingsbasert (login-based): du kjøper et antall innlogginger per måned, noe som passer for fem millioner kunder som logger inn noen få ganger i året. Å logge inn mer enn én gang samme dag teller fortsatt som én innlogging (Experience Cloud User Licenses (opens in a new tab)).
Så når noen sier «vi bygger en kundeportal», er ikke neste spørsmål mitt hvilken mal. Det er: hvem er kundene, hvor mange er de, hvor ofte kommer de, hvilke data trenger de, og hva har de lov til å gjøre med dem?
Når lisensen former modellen
Section titled “Når lisensen former modellen ”Noen ganger velger ikke lisensen bare objektet; den bøyer hele modellen. Noen plattformlisenser begrenser brukerne til én egendefinert app med opptil ti egendefinerte objekter (Lightning Platform – One App, for eksempel; Standard User Licenses (opens in a new tab)).
På et tidlig prosjekt, for et stort selskap innen rådgivning og bygg og anlegg, måtte vi bygge noe à la LinkedIn for hele arbeidsstyrken: alles stillinger, ferdigheter, sertifiseringer, språk og prosjekter, så de kunne finne brobyggeren med sertifisering i et gitt land. Uten en grense ville jeg ha bygd et objekt for bruker-stilling, bruker-ferdighet, bruker-sertifisering, bruker-språk og bruker-prosjekt, pluss referanselister over sertifiseringer og prosjekter. Under en lisens med ti objekter, og med beskjed om ikke å bruke opp alle, var det ikke mulig. Så det ble en slags «Kjenn melodien»: hvor få objekter kan jeg bygge dette med? Svaret var to. Ett referanseobjekt, med en posttype for hver type liste (stilling, ferdighet, sertifisering, språk, prosjekt), og ett brukerattributt-objekt, med tilsvarende posttyper, som pekte på det.
Det var ikke den optimale modellen. Det var et ork å rapportere på, og jeg skulle gjerne hatt den ryddigere. Men det var det lisensen tillot. Jeg kaller disse sveitserkniv-objekter: ha mønsteret i baklomma, og når grensene ikke gir noe rom, knus glasset og gå for separasjon med posttyper. Bare vit hva du bytter bort. Forskjellige tillatelser per posttype kan tvinge deg til å dele objektet likevel.
Mennesker er ikke de eneste brukerne lenger
Section titled “Mennesker er ikke de eneste brukerne lenger ”Ett lisensspørsmål til har blitt viktig: hva med det som ikke er mennesker? Integrasjoner har identiteter. Agenter har identiteter. Salesforce har nå en Salesforce Integration-lisens for integrasjoner system til system: bare API, ikke for mennesker, med fem inkludert i hver org med Enterprise, Unlimited og Performance Edition (Standard User Licenses (opens in a new tab)). Så ikke bare spør hvilke brukere som trenger tilgang. Spør hvilke identiteter som trenger tilgang: en person, en kunde, en partner, en integrasjon, en agent. Og så hva hver av dem trenger å se og gjøre.
Utover eksamen: hva KI endrer. Når agenter blir enda en forbruker og skaper av data, handler objektvalg og lisenser ikke bare om skjermer for mennesker. Vit hvilken identitet agenten kjører som, hva den identiteten kan nå, og om modellen legger dataene den trenger, bak et objekt eller en tillatelse den ikke kan bruke.
Steve Trucking: en enkel og en vanskelig
Section titled “Steve Trucking: en enkel og en vanskelig ”Steve Trucking jobber med detaljhandelspartnere (Retail Partners). Hva er en detaljhandelspartner? En virksomhet. Enkelt: Account. Jeg lager ikke Retail_Partner__c fordi noen brukte ordet «partner».
Så mottakeren (Recipient), personen som tar imot kjøleskapet. Kontakt? Personkonto? Noe annet? En million nye mottakere i året, som er detaljhandelspartnernes kunder, ikke våre. Det er akkurat den typen spørsmål der jeg ikke vil hoppe til et objekt før jeg forstår relasjonen, tilgangen og skalaen. Vi avgjør det ved kontrollpunktet for del 1.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Om et forretningsbegrep passer rent til det tiltenkte formålet med et standardobjekt, eller om meningen eller vekten er en annen.
- Om forskjellige forretningsbetegnelser er forskjellige entiteter eller bare forskjellige roller for den samme.
- Om hver person, ekstern bruker, integrasjon og agent som trenger dataene, kan nå det valgte objektet under de planlagte lisensene.
- Hvordan antallet brukere og innloggingsmønsteret (medlemsbasert eller innloggingsbasert) former lisensen og modellen.
- Når en lisensgrense rettferdiggjør en mindre enn optimal modell, og hva det bytte koster i rapportering og tillatelser.
Poenget er ikke at standardobjekter er gode og egendefinerte objekter dårlige. Det er at valget har konsekvenser, og at det noen ganger ikke avgjøres av substantivet i det hele tatt, men av menneskene, og maskinene, som trenger å bruke det.
Les mer
Section titled “Les mer ”- Salesforce Help, Standard User Licenses (opens in a new tab), på engelsk, kontrollert 2026-10-02, kontrollert på nytt 2026-10-12: Platform-brukere har ikke rett til prognoser, kundeemner, kampanjer og salgsmuligheter; én egendefinert app med opptil 10 egendefinerte objekter; fem Salesforce Integration-lisenser i hver org med Enterprise Edition.
- Salesforce Help, Experience Cloud User Licenses (opens in a new tab), på engelsk, kontrollert 2026-10-02, kontrollert på nytt 2026-10-12: Partner Community kan ikke brukes med personkontoer; Customer Community Plus for rapporter, dashbord og standard deling; flere innlogginger samme dag teller som én.
- Salesforce Help, Supported Editions for Service Features (opens in a new tab), på engelsk, kontrollert 2026-10-02, kontrollert på nytt 2026-10-12: tjenestenivåavtaler (rettighetsstyring) med Agentforce Service; Knowledge koster ekstra i de fleste utgaver.
- Salesforce Help, Available Feature Licenses (opens in a new tab), på engelsk, kontrollert 2026-10-12: Service Cloud User, «Access the Salesforce Console for Service»; Marketing User for å opprette og administrere kampanjer.