Välj rätt objekt

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 5 av 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kursen Data Architect. Varje modul står på egna ben. Föregående: Var bor de här data? · Nästa: Fält är också arkitektur

Frågan den här modulen besvarar: Vilken sorts objekt i Salesforce ska det här affärsbegreppet bli, och vad tillåter licenserna?

Något av det enklaste man kan göra i Salesforce är att skapa ett anpassat objekt. Det är just därför jag tror att vi skapar för många.

Du sitter i en kravworkshop och någon säger: ”Vi behöver hålla koll på våra distributörer.” Nytt anpassat objekt: Distributor. Klart. Fast jag vill att arkitekten först ställer en annan fråga: vad är en distributör? Det är ett företag. Salesforce har redan ett ganska bra sätt att representera ett företag. Det heter konto (Account). Det betyder inte att svaret alltid är konto. Men om jag ska förklara varför ett företag inte är ett konto vill jag ha en bättre anledning än ”verksamheten kallar dem distributörer”.

Det är här den logiska modellen från kapitel 2 möter plattformen, och min utgångspunkt är enkel: om affärsbegreppet passar rent med det avsedda syftet för ett standardobjekt, börja där.

Börja med betydelsen

Även när något förtjänar att bli ett objekt förtjänar det inte automatiskt att bli ett anpassat objekt. Fråga vad saken faktiskt representerar. Ett företag eller en organisation i någon form? Börja med konto. En person som jobbar med den organisationen? Kontakt. Något som en kund äger eller har köpt? Tillgång (Asset). Något du försöker sälja? Då hör affärsmöjlighet (Opportunity) hemma i samtalet.

Det är därför vi tittade på moderskeppet först, i modul 2. De modellerna passar inte varje verksamhet, men vi ska inte ignorera dem bara för att det känns renare att bygga eget. Innan du klickar på New Custom Object, fråga hur Salesforce modellerar det här begreppet, vad som har byggts runt den modellen och vad du skulle ge upp genom att ersätta den.

Testet för ren passform

Mitt test är en enda fråga: passar det här affärsbegreppet rent med standardobjektets avsedda syfte? Om det gör det lutar jag åt standardobjektet.

En distributör är ett företag vi har en relation med, så konto passar rent. Jag har inget emot att användarna kallar ett företag distributör, ett annat leverantör, ett annat detaljhandelspartner och ett annat kund. Det är affärsroller, och de behöver inte fyra fysiska objekt. Olika affärsnamn betyder inte automatiskt olika datastrukturer. En typ, en posttyp eller en relation kan bära skillnaden.

Testet fungerar åt andra hållet också. I kapitel 1 lämnade jag dig med en fråga: en kunds verksamhet har många leveransadresser. Ska varje adress vara ett konto, eller ett anpassat objekt?

Ett konto ger dig mycket. Du får adressfälten, och allt som redan förväntar sig en kontoadress: rapporter, kartor, integrationer. Men du får också omkostnaderna: massor av fält, delning, hierarki, ägarskap, allt som hänger på ett konto, och det mesta är inte relevant för en separat adress. Du skulle bära på en massa tunga saker som du inte använder, bara för en alternativ adress.

Ett anpassat objekt, ett barn till kontot, kan vara lättviktigt: bara adressfälten, ett ställe vi levererar till, med en egen livscykel som jag kan styra oberoende.

Så det är en avvägning: vikten du tar på dig mot värdet du får. Om allt jag behöver är en adress med en egen livscykel är det där jag väljer anpassat.

Samma sak med delproblem på ett ärende. Om varje delproblem verkligen är ett ärende, som en handläggare jobbar med, med egen status och egen servicenivå, nästla dem med Parent Case från modul 2. Men om det bara är en punkt på en checklista som ingen hanterar som ett ärende bär ett fullständigt ärende på mycket som aldrig används, och ett enkelt anpassat barnobjekt kan väga mindre. Inte för att anpassat är renare. Utan för att betydelsen är en annan, eller vikten är fel.

Standardobjekt kommer med bagage

När du väljer ett standardobjekt väljer du mer än dess fält. Du väljer något som Salesforce produkter redan förstår: rapportering, automatisering, inbyggda relationer, produktfunktioner, AppExchange-paket och vad Salesforce än bygger härnäst. Det kan vara enormt värdefullt.

Standardobjekt kommer också med åsikter: befintligt beteende, relationer, säkerhetsaspekter, ibland licenskrav, och funktioner du inte behöver. Så ”använd alltid standardobjekt” är inte min regel. Jag har ingen ”alltid”-regel. Jag har en lutning: använd standardobjektet när betydelsen passar rent och plattformens beteende runt det hjälper designen i stället för att motarbeta den. Om jag ägnar fem år åt att få affärsmöjlighet att bete sig som något som inte är en säljmöjlighet har jag inte vunnit något på att hålla mig till standard. Jag har bara gjort fel kompromiss åt andra hållet.

Tillgång är ett bra exempel

Tillgång (Asset) är ett av standardobjekten som folk förbiser. Enklast uttryckt: det är något som kunden har. Kanske köpte de det av oss, kanske inte. Jag bryr mig ändå om en konkurrents produkt som står hos min kund, eftersom jag servar den, eller försöker ersätta den, eller behöver förstå deras installerade bas. Om jag skapar Customer_Product__c utan att först titta på tillgång har jag hoppat över en arkitekturfråga. Tillgång vinner inte automatiskt, men den förtjänar att utvärderas.

Personkonton: när är personen kontot?

I modul 2 mötte vi personkonton: ett konto och en kontakt i en post, för kunder som är privatpersoner. Nu kommer beslutet.

Min hållning: för B2C är det svårt att klara sig utan dem. Så mycket följer med från start för konton och kontakter att kostnaden och omkostnaderna är värda det. Och det finns en kostnad: ungefär dubbla lagringen jämfört med ett företagskonto, en inställning som inte går att stänga av, och vissa externa licenser kan inte använda dem. Partner Community kan inte användas med personkonton (Experience Cloud User Licenses (opens in a new tab)). Så frågan är inte ”har vi personer i vår databas?”. Varje org har personer. Den är ”är personen faktiskt kontot i den här verksamheten?” Att en kontakt är en person gör den inte till ett personkonto. Det är affärsrelationen som gör det.

Click to enlarge

Nu ska jag krångla till allt: licenser

Hittills: hitta begreppet, leta efter den renaste standardpassformen, välj anpassat när betydelsen inte passar. Nu arkitektens följdfråga: vem behöver använda det? Du kan designa en vacker modell och sedan upptäcka att hälften av dem som behöver data inte har licens för de objekt du valde. Licenser är en del av datamodellen.

Tre interna licenser

Börja med ditt eget folk. Inom företaget finns det tre licenstyper som jag vill att varje arkitekt kan utantill, eftersom de styr vad varje användare kan se och göra, och därmed vad din datamodell kan räkna med.

Sales Cloud (numera Agentforce Sales). De här användarna har den fullständiga användarlicensen Salesforce: CRM-standardobjekten och alla standard- eller anpassade appar. Det är leads, affärsmöjligheter och prognoser utöver konton och kontakter, och till och med ärenden: en säljare kan se en kunds öppna ärenden före ett samtal. Att skapa och köra kampanjer kräver en bit till, funktionslicensen Marketing User.

Service Cloud (numera Agentforce Service). Samma Salesforce-användarlicens, uppsatt för service. Ärenden står i centrum och hanteras i Service Console: det är funktionslicensen Service Cloud User som öppnar Salesforce Console for Service. Det är här servicenivåavtal (SLA) bor, via entitlement management och milstolpar, och det är här Knowledge kommer in, som de flesta utgåvor köper som tillägg.

Platform (Salesforce Platform). För folk som behöver dina anpassade appar, inte CRM. De får konton, kontakter, rapporter, instrumentpaneler, dokument och varje anpassad app i orgen. Det de inte får: prognoser, leads, kampanjer och affärsmöjligheter. Den kostar mindre, vilket är just därför så många stora anpassade appar körs på den, och just därför den kan sätta krokben för din datamodell.

	Sales Cloud	Service Cloud	Platform
Användarlicens	Salesforce	Salesforce	Salesforce Platform
Byggd för	Försäljning	Kundsupport	Anpassade appar
Konton, kontakter	Ja	Ja	Ja
Leads, affärsmöjligheter, prognoser	Ja	Ja	Nej
Ärenden	Ja, för att se en kunds ärenden	I centrum, i Service Console	Nej
Servicenivåavtal	Nej	Ja, berättiganden och milstolpar	Nej
Anpassade objekt och appar	Ja	Ja	Ja

Läs tabellen som en arkitekt gör. Om en stor grupp användare har Platform är varje design som lägger deras arbete på en affärsmöjlighet trasig innan den ens har börjat. Om ledningen behöver SLA-siffror avgör deras licens om de kan se dem. De här tre typerna styr beteendet.

Click to enlarge

När licensen bestämmer objektet

Affärsmöjlighet är det offer jag har stött på oftast. Du såg det i tabellen: Platform-användare får inte tillgång till den (Standard User Licenses (opens in a new tab)), och Customer Community-användare kan inte heller jobba med den. Så kravet ser ut som en affärsmöjlighet, någon säger ”vi använder affärsmöjlighet”, och sedan frågar jag vem som behöver åtkomst. Om en stor grupp har Platform- eller Customer Community-licenser är licensen inte längre en inköpsdetalj. Den är en arkitektonisk begränsning, och den brukar driva designen mot ett anpassat objekt.

Det fungerar uppåt också. I klassrummet frågar jag: vd:n vill ha snygga instrumentpaneler; Sales-licens eller Service? En Sales-användare kan se säljobjekten och till och med ärenden, så för säljpaneler och antal öppna ärenden räcker Sales. Men i samma ögonblick som ledningen vill ha SLA-nyckeltal (hur lång tid tills ett ärende bryter mot sin servicenivå) ligger de data i berättiganden och milstolpar, och entitlement management kräver Agentforce Service, tidigare Service Cloud (Supported Editions for Service Features (opens in a new tab)). Nu uppgraderar du ledningens licenser. Lyssna på affärskravet, och vet vilken licens som ligger under de data det behöver.

Arenan

Jag tänker på licenser som platser på en arena. Alla tittar på samma match. Köper jag de dyra platserna i mitten ser jag båda lagen på nära håll. Sitter jag uppe i hörnet på läktaren är sätena inte stoppade och jag tittar genom kikare.

Det är de externa licenserna, för folk utanför företaget: kunder och partner som loggar in på en Experience Cloud-webbplats. Det finns tre jag vill att du känner till.

Customer Community: läktaren. Byggd för stora mängder externa användare som behöver ärenden och kunskapsartiklar: en kund som kollar läget på sitt supportärende. Platserna kostar ungefär hälften så mycket och kan gå till enorma mängder användare. Vad förlorar du där uppe? Rapporter, instrumentpaneler och delningstabellen: den rollbaserade delning som de högre nivåerna får. Den fungerar med personkonton.

Customer Community Plus: ungefär halvvägs ned. Salesforce beskriver den som licensen för externa användare som behöver rapporter, instrumentpaneler och standarddelning: en kund som hanterar andras åtkomst, eller behöver se sina siffror.

Partner Community: ännu närmare, för business-to-business, med åtkomst till säljdata. Partner jobbar med leads och affärsmöjligheter: de registrerar affärer, och de kör kampanjer tillsammans med dig. Det är den externa platsen som når säljobjekten. En hake: den kan inte användas med personkonton (Experience Cloud User Licenses (opens in a new tab)).

Click to enlarge

Misstaget är att designa som om alla har den dyra biljetten och sedan vid implementeringen upptäcka att de flesta av dina användare inte kommer in i sektionen där du lade deras data. Då har du tre val: köpa andra platser, flytta upplevelsen eller designa om modellen. Alla tre är arkitektur.

Hur de betalar ändrar designen

Det finns en annan fråga folk glömmer: hur kommer de här användarna att logga in? Externa licenser finns i två former. Medlemsbaserade (member-based): du betalar per användare, vilket passar 500 partner som loggar in varje dag. Inloggningsbaserade (login-based): du köper ett antal inloggningar per månad, vilket passar fem miljoner kunder som loggar in några gånger om året. Att logga in mer än en gång samma dag räknas fortfarande som en inloggning (Experience Cloud User Licenses (opens in a new tab)).

Så när någon säger ”vi bygger en kundportal” är min nästa fråga inte vilken mall. Den är: vilka är kunderna, hur många är de, hur ofta kommer de, vilka data behöver de, och vad får de göra med dem?

När licensen formar modellen

Ibland väljer licensen inte bara objektet; den böjer hela modellen. Vissa plattformslicenser begränsar användarna till en anpassad app med upp till tio anpassade objekt (till exempel Lightning Platform – One App; Standard User Licenses (opens in a new tab)).

I ett tidigt projekt, för ett stort företag inom konsulttjänster och byggnation, skulle vi bygga något som liknade LinkedIn för hela personalstyrkan: allas jobb, kompetenser, certifieringar, språk och projekt, så att de kunde hitta brobyggaren som var certifierad i ett visst land. Utan någon gräns hade jag byggt ett objekt för användarjobb, användarkompetens, användarcertifiering, användarspråk och användarprojekt, plus referenslistor över certifieringar och projekt. Med en licens på tio objekt, och med beskedet att inte bränna alla, gick inte det. Så det blev ”gissa låten”: med hur få objekt kan jag bygga det här? Svaret blev två. Ett referensobjekt, med en posttyp för varje sorts lista (jobb, kompetens, certifiering, språk, projekt), och ett objekt för användarattribut, med matchande posttyper, som pekar på det.

Det var inte den optimala modellen. Det var plågsamt att rapportera på, och jag hade föredragit något renare. Men det var vad licensen tillät. Jag kallar de här för schweiziska armékniv-objekt: ha mönstret i bakfickan, och när gränserna inte lämnar något utrymme, krossa glaset och gå på separation med posttyper. Var bara medveten om vad du byter bort. Olika behörigheter per posttyp kan tvinga dig att dela upp objektet ändå.

Människor är inte de enda användarna längre

En licensfråga till har blivit viktig: hur gör vi med det som inte är människor? Integrationer har identiteter. Agenter har identiteter. Salesforce har numera licensen Salesforce Integration för integrationer mellan system: bara API, inte för människor, med fem inkluderade i varje org med Enterprise, Unlimited och Performance Edition (Standard User Licenses (opens in a new tab)). Så fråga inte bara vilka användare som behöver åtkomst. Fråga vilka identiteter som behöver åtkomst: en person, en kund, en partner, en integration, en agent. Och sedan vad var och en behöver se och göra.

Bortom provet: vad AI förändrar. När agenter blir ännu en konsument och skapare av data handlar objektval och licenser inte bara om skärmar för människor. Vet vilken identitet agenten körs som, vad den identiteten kan nå, och om modellen lägger de data agenten behöver bakom ett objekt eller en behörighet som den inte kan använda.

Steve Trucking: ett lätt fall och ett svårt

Steve Trucking jobbar med detaljhandelspartner (Retail Partners). Vad är en detaljhandelspartner? Ett företag. Lätt: konto. Jag skapar inte Retail_Partner__c bara för att någon använde ordet ”partner”.

Nu mottagaren (Recipient), personen som tar emot kylskåpet. Kontakt? Personkonto? Något annat? En miljon nya mottagare om året, som är detaljhandelspartnernas kunder, inte våra. Det är precis den sortens fråga där jag inte vill hoppa till ett objekt innan jag förstår relationen, åtkomsten och skalan. Vi avgör det vid kontrollpunkten i del 1.

Vad en arkitekt bestämmer här

• Om ett affärsbegrepp passar rent med det avsedda syftet för ett standardobjekt, eller om dess betydelse eller vikt är en annan.
• Om olika affärsetiketter är olika entiteter eller bara olika roller för samma entitet.
• Om varje person, extern användare, integration och agent som behöver data kan nå det valda objektet med de planerade licenserna.
• Hur populationen och inloggningsmönstret (medlemsbaserat eller inloggningsbaserat) formar licensen och modellen.
• När en licensgräns motiverar en mindre än optimal modell, och vad det bytet kostar i rapportering och behörigheter.

Poängen är inte att standardobjekt är bra och anpassade objekt dåliga. Den är att valet får konsekvenser, och att det ibland inte avgörs av substantivet alls, utan av de människor, och de maskiner, som behöver använda det.

Utforska vidare

• Salesforce Help, Standard User Licenses (opens in a new tab) (på engelska, kontrollerad 2026-10-02, kontrollerad igen 2026-10-12): Platform-användare har inte rätt till prognoser, leads, kampanjer och affärsmöjligheter; en anpassad app med upp till 10 anpassade objekt; fem Salesforce Integration-licenser i varje org med Enterprise Edition.
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab) (på engelska, kontrollerad 2026-10-02, kontrollerad igen 2026-10-12): Partner Community kan inte användas med personkonton; Customer Community Plus för rapporter, instrumentpaneler och standarddelning; flera inloggningar samma dag räknas som en.
• Salesforce Help, Supported Editions for Service Features (opens in a new tab) (på engelska, kontrollerad 2026-10-02, kontrollerad igen 2026-10-12): servicenivåavtal (entitlement management) med Agentforce Service; Knowledge kostar extra i de flesta utgåvor.
• Salesforce Help, Available Feature Licenses (opens in a new tab) (på engelska, kontrollerad 2026-10-12): Service Cloud User, åtkomst till Salesforce Console for Service; Marketing User för att skapa och hantera kampanjer.