Egendefinerte objekter
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 3 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Forrige: Se til moderskipet: standarddatamodellene · Neste: Hvor bor disse dataene?
Spørsmålet denne modulen besvarer: Når Salesforce ikke har det, hva får du egentlig når du bygger ditt eget objekt?
I forrige modul så vi på hva Salesforce allerede har bygd. Noen ganger har den ikke det du trenger. Steve Trucking kjører lastebiler, og det finnes ikke noe standardobjekt for lastebil (Truck). Så du bygger et: et egendefinert objekt.
Her er det jeg vil at du skal se i denne modulen. Et egendefinert objekt lages i metadata, som alt annet i modul 1, og i det øyeblikket det finnes, kommer det med et sett standardfunksjonalitet. Det er ikke en tom tabell. Og skjermen du fyller ut for å lage det, stiller deg arkitekturspørsmål, enten du legger merke til det eller ikke.
Skjermen New Custom Object
Section titled “Skjermen New Custom Object ”Gå til Setup → Object Manager → Create → Custom Object, og du får ett langt skjema. De fleste fyller ut de to første boksene og klikker Save. La oss ta det med ro og lese det.
Label og Plural Label (etikett og flertallsetikett). «Truck» og «Trucks». Dette er det brukerne ser, i faner, sideoppsett og rapporter. Du kan endre dem senere uten særlig smerte.
Object Name. Denne er annerledes: det er API-navnet, navnet som kode, integrasjoner, rapporter og nå agenter bruker. Skriv «Truck», og Salesforce gjør det til Truck__c. Å endre det senere betyr å finne alt som viser til det, og det er reversibilitetstesten fra kapittel 1 igjen. Få denne riktig første gang.
Description (beskrivelse). Fyll den ut. Hver gang. I modul 1 sa jeg at metadata ikke er pynt lenger: neste admin leser dette, og det gjør hvert KI-verktøy som prøver å forstå orgen din. Et egendefinert objekt med tom beskrivelse er en eske uten etikett.
Record Name (postnavn). Hvert egendefinert objekt har et Name-felt, og det er her du bestemmer hva det er. Et Text-navn, som «Truck 117», eller et Auto Number, som T-000184, som Salesforce fyller inn for deg. Les advarselen på den skjermen: planlegger du å sette inn store mengder poster gjennom API-et, ber Salesforce deg bruke Text. Det er plattformen som forteller deg noe om skala før du har laget en eneste post.
Salesforce Setup, New Custom Object: Record Name-delen, med advarselen (skjermbilde, 2026-10-12). Full størrelse
Optional Features (valgfrie funksjoner). Allow Reports, Allow Activities, Track Field History, Allow in Chatter Groups. Av som standard. Hver av dem er en funksjon du slår på for dette objektet; bestem deg med vilje.
Object Classification (objektklassifisering). Allow Sharing, Allow Bulk API Access, Allow Streaming API Access, alle på som standard. Skjermen sier det rett ut: med disse på er objektet et Enterprise Application-objekt; med dem av er det et Light Application-objekt. De navnene samsvarer med Salesforces lisenser for app-abonnement: en Lightning Platform Light App har ingen deling på postnivå og kan ikke bruke Bulk API eller Streaming API, og en Enterprise App kan. Mitt råd: la dem være på med mindre du vet nøyaktig hvorfor ikke. Slå av Bulk API-tilgang på et objekt du senere skal laste store mengder inn i, så finner du ut hvorfor det betydde noe.
Deployment Status og Search (utrullingsstatus og søk). «In Development» skjuler objektet for brukerne mens du bygger det; «Deployed» gjør det live. Og Allow Search er av som standard, så brukerne finner ikke disse postene i det globale søket før du slår det på. Den tar folk hver eneste gang.
Standardvalgene: de tre API-innstillingene på, Deployed, og Allow Search av (skjermbilde, 2026-10-12). Full størrelse
Klikk Save, og Object Manager viser deg objektet: API-navnet Truck__c, en hake i Custom, etikettene, utrullingsstatusen. Se nedover venstre side, derimot: Fields & Relationships, Page Layouts, Lightning Record Pages, Record Types, Validation Rules, Triggers, Flow Triggers, Object Access, Field Access. Den listen er modul 1 gjort synlig. Et objekt er ikke bare lagring; det er stedet all den oppførselen henger fra.
Object Manager, Truck: API-navnet Truck__c, Custom og alt som henger på et objekt (skjermbilde, 2026-10-12). Full størrelse
Feltene du ikke laget
Section titled “Feltene du ikke laget ”Åpne Fields & Relationships på et splitter nytt egendefinert objekt, og det har allerede felt. Hvert egendefinert objekt får et standardsett:
- Name, postnavnet du nettopp valgte, brukt i sideoppsett, relaterte lister, lookup-felt og søkeresultater.
- Owner, brukeren eller køen som eier posten.
- Created By og Last Modified By, brukerne som opprettet og sist endret den.
- Currency, hvis flere valutaer er slått på, og Division, hvis orgen din bruker divisjoner.
Og under der post-ID-en fra modul 1, og datoene for opprettelse og endring. Eksporter noen poster med Data Loader, så ser du alle sammen.
Ett av dem kan forsvinne. Gjør det egendefinerte objektet ditt til detaljsiden i en master-detail-relasjon, og Owner-feltet forsvinner: eierskapet kommer fra masterposten i stedet. Det er en større sak enn det høres ut som, og vi kommer tilbake til det i modul 7 og 8.
Prefikser og suffikser: hva du ser på
Section titled “Prefikser og suffikser: hva du ser på ”I forrige modul sa jeg at standardobjekter ikke har prefiks eller suffiks. Alt annet har det, og når du kan lese dem, forteller en feltliste deg nøyaktig hva du ser på.
| Slik ser det ut | Hva det er |
|---|---|
Account, Case | Et standardobjekt eller standardfelt: ingen prefiks, ingen suffiks |
Truck__c | Et egendefinert objekt, eller et egendefinert felt, som Unit_Number__c |
abc__Inspection__c | Et egendefinert objekt fra en administrert pakke (managed package): abc er leverandørens navnerom |
Delivery_History__b | Et big object (modul 4) |
Shipment__x | Et eksternt objekt: dataene bor i et annet system (modul 4) |
Allergies__pc | Et egendefinert kontaktfelt på en personkonto (modul 2) |
Truck__r | Relasjonen bak et egendefinert lookup-felt, når du følger den i en spørring |
Noen ting å legge merke til.
Så langt er det en liste. Slik underviser jeg det: som lag. Det finnes tre typer objekter, standard, egendefinert og administrert pakke, og hver av dem kan ha de samme typene felt: standardfeltene de kom med, og de egendefinerte feltene noen la til.
Standardobjekter. Account har ingen prefiks og ingen suffiks, og det har ikke standardfeltene heller: Name, Industry, OwnerId. Du kan legge egendefinerte felt til de fleste standardobjekter, og hvert eneste du legger til, slutter på __c: Region__c (Custom Fields (opens in a new tab)). Det suffikset er det som holder deg trygg. Salesforce legger til nye standardfelt på Account i sine releaser, og fordi dine alltid slutter på __c og deres aldri gjør det, kan et fremtidig standardfelt aldri kollidere med et felt du allerede har.
Egendefinerte objekter. Ditt eget objekt slutter på __c, Truck__c (Custom Objects (opens in a new tab)), og det gjør også de egendefinerte feltene du legger på det: Unit_Number__c. Men feltene det ble født med, de fra forrige avsnitt, er standardfelt: Name, OwnerId, CreatedDate, uten suffiks. Så selv på ditt eget objekt forteller suffikset deg hvem som laget hvert felt.
Objekter i administrerte pakker. Når du installerer en administrert pakke fra AppExchange, kommer objektene og feltene med leverandørens navneromsprefiks (namespace prefix): abc__Inspection__c, og felt som abc__Result__c. Det prefikset er unikt for leverandøren, og det endrer seg ikke (Namespace Prefix (opens in a new tab)). Med Salesforces egne ord legges prefikset til hver komponent for å gjøre den unik: name__c blir prefix__name__c (AppExchange Object Prefixes and the API (opens in a new tab)). Så to leverandører kan begge levere et objekt kalt Invoice__c og aldri kollidere med hverandre, eller med deg. Pakkens objekter har fortsatt standardfeltene sine, Name og OwnerId, uten prefiks. En pakke kan også legge til egne felt med prefiks på standardobjekter, som abc__Score__c på Account. Og du kan legge til dine egne egendefinerte felt på en pakkes objekter: Depot__c på abc__Inspection__c får ditt __c-suffiks, men aldri leverandørens prefiks, fordi du laget det, ikke de (Known Issue: unmanaged custom field on a managed package object (opens in a new tab)).
Les et hvilket som helst API-navn, og du vet hvem som laget det. Ingen suffiks: Salesforce. __c uten prefiks: orgen din. abc__ foran: leverandøren. Det betyr noe hver gang du planlegger en endring. Det som er ditt, kan du endre. Det som er Salesforces, konfigurerer og utvider du. Det som er leverandørens, er stort sett låst: noen få ting, som sideoppsett og hjelpetekst, kan du redigere selv, men det meste av pakken, og hvert API-navn, tilhører leverandøren, og oppgraderingene deres tar med seg endringene deres (Editable Properties After Package Promotion or Installation (opens in a new tab)).
Uadministrerte pakker har det ikke. Installer en uadministrert pakke (unmanaged package), og objektene lander i orgen din som om du hadde bygd dem selv, uten prefiks. Har den med seg en Truck__c og du allerede har en, har du en navnekollisjon. Sjekk før du installerer.
Bygg bare det Salesforce ikke har
Section titled “Bygg bare det Salesforce ikke har ”Det er lett å lage et egendefinert objekt; det er nettopp derfor jeg mener vi lager for mange av dem. Skjermen New Custom Object lager gjerne en Customer__c til deg i en org som allerede har Account. Så før du klikker, still spørsmålet fra forrige modul: har moderskipet dette allerede? Hvis ja, bruk det. Hvis nei, bygg det, og fyll ut hele skjermen som en arkitekt.
Neste modul stiller et enda tidligere spørsmål: skal disse dataene i det hele tatt være i Salesforce?
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Om Salesforce allerede har et standardobjekt for dette, før du bygger et egendefinert.
- API-navnet, valgt én gang, og en beskrivelse skrevet for mennesker og maskiner.
- Postnavnet: Text eller Auto Number, med volumet du venter i tankene.
- Hvilke valgfrie funksjoner, hvilken API-tilgang og hvilket søk som skal slås på, med vilje.
- Hva suffiksene i en org forteller deg: egendefinert, administrert, big object, eksternt, personkonto.
- Om en pakke du er i ferd med å installere, kan kollidere med det du har bygd.
Les mer
Section titled “Les mer ”- Custom Objects (opens in a new tab) og Custom Fields (opens in a new tab), Object Reference (på engelsk, kontrollert 2026-10-13): «the names of custom objects include a suffix of two underscores followed by a lowercase ‘c’»; det samme for egendefinerte felt; og tabellen over standardobjekter som støtter egendefinerte felt.
- AppExchange Object Prefixes and the API (opens in a new tab), Object Reference (på engelsk, kontrollert 2026-10-13): et navneromsprefiks gjør hver pakket komponent unik; «name__c becomes prefix__name__c».
- Namespace Prefix (opens in a new tab), Apex Developer Guide (på engelsk, kontrollert 2026-10-13): navneromsprefikser holder objekt- og feltnavnene i administrerte pakker adskilt fra andre orgers.
- Editable Properties After Package Promotion or Installation (opens in a new tab), Second-Generation Managed Packaging Developer Guide (på engelsk, kontrollert 2026-10-13): hvilke egenskaper ved en pakkes komponenter utvikleren, abonnenten, begge eller ingen av dem kan redigere.
- Custom Object Standard Fields (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-12): standardfeltene hvert egendefinert objekt får (Name, Owner, Created By, Last Modified By, Currency, Division), og hvorfor Owner fjernes på detaljsiden av en master-detail-relasjon.
- Standard User Licenses (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-12): en Lightning Platform Light App «can’t use the Bulk API or Streaming API»; en Enterprise App «supports record-level sharing, can use the Bulk API and Streaming API.»