Anpassade 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)

In a truck body shop, a custom white box body hangs on chains above a standard truck chassis, already fitted with its doors, lights and mud flaps. — Bilden är skapad med AI

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

Frågan den här modulen besvarar: När Salesforce inte har det, vad får du egentligen när du bygger ett eget objekt?

I förra modulen tittade vi på vad Salesforce redan har byggt. Ibland har det inte det du behöver. Steve Trucking kör lastbilar, och det finns inget standardobjekt för lastbil (Truck). Så du bygger ett: ett anpassat objekt (custom object).

Det här vill jag att du ser i den här modulen. Ett anpassat objekt skapas i metadata, precis som allt annat i modul 1, och i samma ögonblick som det finns kommer det med en uppsättning standardfunktioner. Det är ingen tom tabell. Och skärmen du fyller i för att skapa det ställer arkitekturfrågor till dig, vare sig du märker det eller inte.

Skärmen New Custom Object

Gå till Setup → Object Manager → Create → Custom Object så får du ett långt formulär. De flesta fyller i de två första rutorna och klickar på Save. Låt oss sakta ned och läsa det.

Label och Plural Label (etikett och etikett i plural). ”Truck” och ”Trucks”. Det är dem användarna ser, i flikar, sidlayouter och rapporter. Du kan ändra dem senare utan större smärta.

Object Name (objektnamn). Det här är annorlunda: det är API-namnet, namnet som kod, integrationer, rapporter och numera agenter använder. Skriv ”Truck” så gör Salesforce det till Truck__c. Att ändra det senare innebär att hitta allt som refererar till det, vilket är reversibilitetstestet från kapitel 1 igen. Gör rätt med det här från början.

Description (beskrivning). Fyll i den. Varje gång. I modul 1 sa jag att metadata inte är dekoration längre: nästa admin läser det här, och det gör varje AI-verktyg som försöker förstå din org också. Ett anpassat objekt med en tom beskrivning är en låda utan etikett.

Record Name (postnamn). Varje anpassat objekt har ett Name-fält, och här bestämmer du vad det är. Ett Text-namn, som ”Truck 117”, eller ett Auto Number, som T-000184, som Salesforce fyller i åt dig. Läs varningen på den skärmen: om du planerar att infoga stora mängder poster via API:et säger Salesforce att du ska använda Text. Där talar plattformen om något för dig om skala innan du ens har skapat en enda post.

Avsnittet Record Name på skärmen New Custom Object: rutan Record Name, datatypen Text och varningen att använda datatypen Text om du planerar att infoga stora mängder poster via API

Salesforce Setup, New Custom Object: avsnittet Record Name med sin varning (skärmdump, 2026-10-12). Full storlek

Optional Features (valfria funktioner). Allow Reports, Allow Activities, Track Field History, Allow in Chatter Groups. Avstängda som standard. Var och en är en funktion du slår på för det här objektet; bestäm med avsikt.

Object Classification (objektklassificering). Allow Sharing, Allow Bulk API Access, Allow Streaming API Access, alla påslagna som standard. Skärmen säger det rakt ut: med dem påslagna är objektet ett Enterprise Application-objekt; med dem avstängda är det ett Light Application-objekt. De namnen motsvarar Salesforces licenser för appabonnemang: en Lightning Platform Light App har ingen delning på postnivå och kan inte använda Bulk API eller Streaming API, och en Enterprise App kan det. Mitt råd: låt dem vara påslagna om du inte vet exakt varför de inte ska vara det. Stäng av Bulk API-åtkomst på ett objekt som du senare laddar i stora volymer, så får du veta varför det spelade roll.

Deployment Status och Search (driftsättningsstatus och sökning). ”In Development” döljer objektet för användarna medan du bygger det; ”Deployed” gör det skarpt. Och Allow Search är avstängt som standard, så användarna hittar inte de här posterna i den globala sökningen förrän du slår på det. Den fångar folk varje gång.

Standardvärdena: de tre API-inställningarna påslagna, Deployed, och Allow Search avstängt (skärmdump, 2026-10-12). Full storlek

Klicka på Save så visar Object Manager objektet: API-namnet Truck__c, en bock i Custom, etiketterna, driftsättningsstatusen. Titta längs vänsterkanten, däremot: Fields & Relationships, Page Layouts, Lightning Record Pages, Record Types, Validation Rules, Triggers, Flow Triggers, Object Access, Field Access. Den listan är modul 1 synliggjord. Ett objekt är inte bara lagring; det är stället där allt det beteendet hänger.

Object Manager som visar objektet Truck: API-namnet Truck__c, Custom ikryssat, etiketter i singular och plural och listan till vänster från Fields & Relationships till Validation Rules

Object Manager, Truck: API-namnet Truck__c, Custom och allt som hänger på ett objekt (skärmdump, 2026-10-12). Full storlek

Fälten du inte skapade

Öppna Fields & Relationships på ett helt nytt anpassat objekt, och det har redan fält. Varje anpassat objekt får en standarduppsättning:

Name, postnamnet du just valde, som används i sidlayouter, relaterade listor, lookups och sökresultat.
Owner, användaren eller kön som äger posten.
Created By och Last Modified By, användarna som skapade och senast ändrade den.
Currency, om flera valutor är påslaget, och Division, om din org använder divisioner.

Och under ytan post-ID:t från modul 1, samt datum för när posten skapades och ändrades. Exportera några poster med Data Loader så ser du dem allihop.

Ett av dem kan försvinna. Gör ditt anpassade objekt till detaljsidan i en master-detail-relation, så försvinner Owner-fältet: ägarskapet kommer från masterposten i stället. Det är en större sak än det låter, och vi återkommer till det i modul 7 och 8.

Prefix och suffix: vad du tittar på

I förra modulen sa jag att standardobjekt inte har något prefix och inget suffix. Allt annat har det, och när du väl kan läsa dem talar en fältlista om exakt vad du tittar på.

Hur det ser ut	Vad det är
`Account`, `Case`	Ett standardobjekt eller standardfält: inget prefix, inget suffix
`Truck__c`	Ett anpassat objekt, eller ett anpassat fält, som `Unit_Number__c`
`abc__Inspection__c`	Ett anpassat objekt från ett hanterat paket (managed package): `abc` är leverantörens namnrymd
`Delivery_History__b`	Ett big object (modul 4)
`Shipment__x`	Ett externt objekt: data bor i ett annat system (modul 4)
`Allergies__pc`	Ett anpassat kontaktfält på ett personkonto (modul 2)
`Truck__r`	Relationen bakom en anpassad lookup, när du följer den i en fråga

Några saker att lägga märke till.

Hittills är det en lista. Så här undervisar jag om det: som lager. Det finns tre sorters objekt, standard, anpassade och från hanterade paket, och vart och ett av dem kan ha samma sorters fält: standardfälten det kom med, och de anpassade fält som någon har lagt till.

Standardobjekt. Account har inget prefix och inget suffix, och det har inte dess standardfält heller: Name, Industry, OwnerId. Du kan lägga till anpassade fält på de flesta standardobjekt, och varje fält du lägger till slutar på __c: Region__c (Custom Fields (opens in a new tab)). Det suffixet är det som skyddar dig. Salesforce lägger till nya standardfält på Account i sina releaser, och eftersom dina alltid slutar på __c och deras aldrig gör det, kan ett framtida standardfält aldrig krocka med ett fält du redan har.

Anpassade objekt. Ditt eget objekt slutar på __c, Truck__c (Custom Objects (opens in a new tab)), och det gör de anpassade fälten du lägger på det också: Unit_Number__c. Men fälten det föddes med, de från förra avsnittet, är standardfält: Name, OwnerId, CreatedDate, inget suffix. Så även på ditt eget objekt talar suffixet om vem som skapade varje fält.

Objekt från hanterade paket. När du installerar ett hanterat paket från AppExchange kommer dess objekt och fält med leverantörens namnrymdsprefix (namespace prefix): abc__Inspection__c, och fält som abc__Result__c. Prefixet är unikt för leverantören, och det ändras inte (Namespace Prefix (opens in a new tab)). Med Salesforces egna ord läggs prefixet till på varje komponent för att göra den unik: name__c blir prefix__name__c (AppExchange Object Prefixes and the API (opens in a new tab)). Så två leverantörer kan båda leverera ett objekt som heter Invoice__c utan att någonsin krocka med varandra, eller med dig. Paketets objekt har fortfarande sina standardfält, Name och OwnerId, utan prefix. Ett paket kan också lägga till egna fält med prefix på standardobjekt, som abc__Score__c på Account. Och du kan lägga till egna anpassade fält på ett pakets objekt: Depot__c på abc__Inspection__c får ditt suffix __c, men aldrig leverantörens prefix, eftersom det är du som skapade det, inte de (Known Issue: unmanaged custom field on a managed package object (opens in a new tab)).

Click to enlarge

Läs vilket API-namn som helst så vet du vem som skapade det. Inget suffix: Salesforce. __c utan prefix: din org. abc__ framför: leverantören. Det spelar roll varje gång du planerar en ändring. Det som är ditt kan du ändra. Det som är Salesforces konfigurerar och bygger du ut. Det som är leverantörens är mestadels låst: några saker, som sidlayouter och hjälptext, får du redigera, men det mesta av paketet, och varje API-namn, tillhör leverantören, och deras uppgraderingar för med sig deras ändringar (Editable Properties After Package Promotion or Installation (opens in a new tab)).

Ohanterade paket gör det inte. Installera ett ohanterat paket (unmanaged package), så landar dess objekt i din org som om du hade byggt dem själv, utan prefix. Om det har med sig ett Truck__c och du redan har ett, har du en namnkrock. Kontrollera innan du installerar.

Bygg bara det som Salesforce inte har

Att skapa ett anpassat objekt är enkelt; det är just därför jag tror att vi skapar för många. Skärmen New Custom Object gör gärna ett Customer__c åt dig i en org som redan har Account. Så innan du klickar, ställ frågan från förra modulen: har moderskeppet redan det här? Om det har det, använd det. Om inte, bygg det, och fyll i hela skärmen som en arkitekt.

Nästa modul ställer en ännu tidigare fråga: ska de här data finnas i Salesforce över huvud taget?

Vad en arkitekt bestämmer här

Om Salesforce redan har ett standardobjekt för det här, innan du bygger ett anpassat.
API-namnet, valt en gång, och en beskrivning skriven för både människor och maskiner.
Postnamnet: Text eller Auto Number, med den förväntade volymen i åtanke.
Vilka valfria funktioner, vilken API-åtkomst och vilken sökning som ska slås på, med avsikt.
Vad suffixen i en org berättar: anpassat, hanterat, big object, externt, personkonto.
Om ett paket du är på väg att installera kan krocka med det du har byggt.

Utforska vidare

Custom Objects (opens in a new tab) och Custom Fields (opens in a new tab), Object Reference (på engelska, kontrollerad 2026-10-13): namnen på anpassade objekt har ett suffix med två understreck följda av ett litet ”c”; samma sak för anpassade fält; och tabellen över standardobjekt som stöder anpassade fält.
AppExchange Object Prefixes and the API (opens in a new tab), Object Reference (på engelska, kontrollerad 2026-10-13): ett namnrymdsprefix gör varje paketerad komponent unik; ”name__c blir prefix__name__c”.
Namespace Prefix (opens in a new tab), Apex Developer Guide (på engelska, kontrollerad 2026-10-13): namnrymdsprefix håller isär hanterade pakets objekt- och fältnamn från andra orgars.
Editable Properties After Package Promotion or Installation (opens in a new tab), Second-Generation Managed Packaging Developer Guide (på engelska, kontrollerad 2026-10-13): vilka egenskaper hos ett pakets komponenter som utvecklaren, prenumeranten, båda eller ingen av dem kan redigera.
Custom Object Standard Fields (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-12): standardfälten som varje anpassat objekt får (Name, Owner, Created By, Last Modified By, Currency, Division), och varför Owner tas bort på detaljsidan i en master-detail-relation.
Standard User Licenses (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-12): en Lightning Platform Light App kan inte använda Bulk API eller Streaming API; en Enterprise App stöder delning på postnivå och kan använda Bulk API och Streaming API.