Brugerdefinerede objekter
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)
Modul 3 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Kig på moderskibet: standarddatamodellerne · Næste: Hvor bor disse data?
Spørgsmålet, dette modul besvarer: Når Salesforce ikke har det, hvad får du så egentlig, når du bygger dit eget objekt?
I sidste modul så vi på, hvad Salesforce allerede har bygget. Nogle gange har den ikke det, du har brug for. Steve Trucking kører lastbiler, og der findes intet standardobjekt for lastbiler. Så du bygger et: et brugerdefineret objekt (custom object).
Her er det, jeg vil have dig til at se i dette modul. Et brugerdefineret objekt oprettes i metadata ligesom alt andet i modul 1, og i det øjeblik det findes, følger der en række standardfunktioner med. Det er ikke en tom tabel. Og skærmen, du udfylder for at oprette det, stiller dig arkitekturspørgsmål, uanset om du lægger mærke til det eller ej.
Skærmen New Custom Object
Sektion kaldt “Skærmen New Custom Object ”Gå til Setup → Object Manager → Create → Custom Object, og du får én lang formular. De fleste udfylder de to første felter og klikker på Save. Lad os sætte farten ned og læse den.
Label og Plural Label (etiket i ental og flertal). »Truck« og »Trucks«. Det er dem, brugerne ser, i faner, sidelayouts og rapporter. Du kan ændre dem senere uden de store smerter.
Object Name. Det her er anderledes: Det er API-navnet, det navn, som kode, integrationer, rapporter og nu agenter bruger. Skriv »Truck«, og Salesforce gør det til Truck__c. At ændre det senere betyder, at du skal finde alt, der henviser til det, og det er reversibilitetstesten fra kapitel 1 igen. Få det her rigtigt første gang.
Description (beskrivelse). Udfyld den. Hver gang. I modul 1 sagde jeg, at metadata ikke længere er pynt: Den næste admin læser det her, og det gør ethvert AI-værktøj, der prøver at forstå din org, også. Et brugerdefineret objekt med en tom beskrivelse er en kasse uden etiket.
Record Name (postnavn). Hvert brugerdefineret objekt har et Name-felt, og det er her, du beslutter, hvad det er. Et Text-navn som »Truck 117« eller et Auto Number som T-000184, som Salesforce udfylder for dig. Læs advarslen på den skærm: Hvis du planlægger at indsætte store mængder poster via API’et, beder Salesforce dig bruge Text. Det er platformen, der fortæller dig noget om skala, før du har oprettet en eneste post.
Salesforce Setup, New Custom Object: afsnittet Record Name med sin advarsel (skærmbillede, 12. oktober 2026). Fuld størrelse
Optional Features (valgfrie funktioner). Allow Reports, Allow Activities, Track Field History, Allow in Chatter Groups. Slået fra som standard. Hver af dem er en funktion, du slår til for dette objekt; beslut det med vilje.
Object Classification (objektklassifikation). Allow Sharing, Allow Bulk API Access, Allow Streaming API Access, alle slået til som standard. Skærmen siger det ligeud: Med dem slået til er objektet et Enterprise Application-objekt; med dem slået fra er det et Light Application-objekt. De navne svarer til Salesforces licenser til app-abonnementer: En Lightning Platform Light App har ingen deling på postniveau og kan ikke bruge Bulk API eller Streaming API, og en Enterprise App kan. Mit råd: Lad dem være slået til, medmindre du ved præcis, hvorfor ikke. Slå Bulk API-adgang fra på et objekt, du senere skal indlæse store mængder i, og du finder ud af, hvorfor det betød noget.
Deployment Status og Search. »In Development« skjuler objektet for brugerne, mens du bygger det; »Deployed« gør det live. Og Allow Search er slået fra som standard, så brugerne finder ikke disse poster i den globale søgning, før du slår den til. Den fanger folk hver gang.
Standardindstillingerne: de tre API-indstillinger slået til, Deployed, og Allow Search slået fra (skærmbillede, 12. oktober 2026). Fuld størrelse
Klik på Save, og Object Manager viser dig objektet: API-navnet Truck__c, et flueben i Custom, etiketterne, deployment-statussen. Se dog ned ad venstre side: Fields & Relationships, Page Layouts, Lightning Record Pages, Record Types, Validation Rules, Triggers, Flow Triggers, Object Access, Field Access. Den liste er modul 1 gjort synligt. Et objekt er ikke bare lagerplads; det er stedet, hvor al den adfærd hænger fra.
Object Manager, Truck: API-navnet Truck__c, Custom og alt det, der hænger på et objekt (skærmbillede, 12. oktober 2026). Fuld størrelse
Felterne, du ikke selv oprettede
Sektion kaldt “Felterne, du ikke selv oprettede ”Åbn Fields & Relationships på et splinternyt brugerdefineret objekt, og det har allerede felter. Hvert brugerdefineret objekt får et standardsæt:
- Name, postnavnet, du lige har valgt, som bruges i sidelayouts, relaterede lister, lookups og søgeresultater.
- Owner, den bruger eller kø, der ejer posten.
- Created By og Last Modified By, de brugere, der oprettede den og sidst ændrede den.
- Currency, hvis flere valutaer er slået til, og Division, hvis din org bruger divisioner.
Og nedenunder post-id’et fra modul 1 samt oprettelses- og ændringsdatoerne. Eksportér et par poster med Data Loader, så ser du dem alle.
Et af dem kan forsvinde. Gør dit brugerdefinerede objekt til detaljesiden i en master-detail-relation, og Owner-feltet forsvinder: Ejerskabet kommer i stedet fra masterposten. Det er en større sag, end det lyder, og vi vender tilbage til det i modul 7 og 8.
Præfikser og suffikser: hvad du kigger på
Sektion kaldt “Præfikser og suffikser: hvad du kigger på ”I sidste modul sagde jeg, at standardobjekter hverken har præfiks eller suffiks. Det har alt andet, og når du først kan læse dem, fortæller en feltliste dig præcis, hvad du kigger på.
| Sådan ser det ud | Det er |
|---|---|
Account, Case | Et standardobjekt eller -felt: intet præfiks, intet suffiks |
Truck__c | Et brugerdefineret objekt eller et brugerdefineret felt som Unit_Number__c |
abc__Inspection__c | Et brugerdefineret objekt fra en managed package: abc er leverandørens namespace |
Delivery_History__b | Et big object (modul 4) |
Shipment__x | Et eksternt objekt: dataene bor i et andet system (modul 4) |
Allergies__pc | Et brugerdefineret kontaktfelt på en personkonto (modul 2) |
Truck__r | Relationen bag et brugerdefineret lookup, når du følger det i en forespørgsel |
Et par ting at lægge mærke til.
Indtil videre er det en liste. Sådan underviser jeg i det: som lag. Der er tre slags objekter, standard, brugerdefinerede og fra managed packages, og hver af dem kan have de samme slags felter: de standardfelter, objektet kom med, og de brugerdefinerede felter, nogen har tilføjet.
Standardobjekter. Account har hverken præfiks eller suffiks, og det har dens standardfelter heller ikke: Name, Industry, OwnerId. Du kan tilføje brugerdefinerede felter til de fleste standardobjekter, og hvert felt, du tilføjer, ender på __c: Region__c (Custom Fields (opens in a new tab)). Det suffiks er det, der beskytter dig. Salesforce tilføjer nye standardfelter til Account i sine releases, og fordi dine altid ender på __c og deres aldrig gør, kan et fremtidigt standardfelt aldrig støde sammen med et felt, du allerede har.
Brugerdefinerede objekter. Dit eget objekt ender på __c, Truck__c (Custom Objects (opens in a new tab)), og det gør de brugerdefinerede felter, du sætter på det, også: Unit_Number__c. Men de felter, det blev født med, dem fra forrige afsnit, er standardfelter: Name, OwnerId, CreatedDate, uden suffiks. Så selv på dit eget objekt fortæller suffikset dig, hvem der lavede hvert felt.
Objekter fra managed packages. Når du installerer en managed package fra AppExchange, kommer dens objekter og felter med leverandørens namespace-præfiks: abc__Inspection__c og felter som abc__Result__c. Det præfiks er unikt for leverandøren, og det ændrer sig ikke (Namespace Prefix (opens in a new tab)). Med Salesforces egne ord føjes præfikset til hver komponent for at gøre den unik: name__c bliver til prefix__name__c (AppExchange Object Prefixes and the API (opens in a new tab)). Så to leverandører kan begge levere et objekt ved navn Invoice__c uden nogensinde at støde sammen med hinanden eller med dig. Pakkens objekter har stadig deres standardfelter, Name og OwnerId, uden præfiks. En pakke kan også tilføje sine egne felter med præfiks til standardobjekter, som abc__Score__c på Account. Og du kan tilføje dine egne brugerdefinerede felter til en pakkes objekter: Depot__c på abc__Inspection__c får dit __c-suffiks, men aldrig leverandørens præfiks, fordi det er dig, der har lavet det, ikke dem (Known Issue: unmanaged custom field on a managed package object (opens in a new tab)).
Læs et hvilket som helst API-navn, og du ved, hvem der lavede det. Intet suffiks: Salesforce. __c uden præfiks: din org. abc__ foran: leverandøren. Det betyder noget, hver gang du planlægger en ændring. Det, der er dit, kan du ændre. Det, der er Salesforces, konfigurerer og udvider du. Det, der er leverandørens, er for det meste låst: Nogle få ting, som sidelayouts og hjælpetekst, kan du redigere, men det meste af pakken og hvert eneste API-navn tilhører leverandøren, og deres opgraderinger bringer deres ændringer med (Editable Properties After Package Promotion or Installation (opens in a new tab)).
Unmanaged packages gør ikke. Installér en unmanaged package, og dens objekter lander i din org, som om du selv havde bygget dem, uden præfiks. Hvis den har et Truck__c med, og du allerede har et, har du en navnekollision. Tjek før du installerer.
Byg kun det, Salesforce ikke har
Sektion kaldt “Byg kun det, Salesforce ikke har ”Det er nemt at oprette et brugerdefineret objekt; det er præcis derfor, jeg mener, vi opretter for mange af dem. Skærmen New Custom Object laver gladelig et Customer__c til dig i en org, der allerede har Account. Så før du klikker, så stil spørgsmålet fra sidste modul: Har moderskibet allerede det her? Hvis det har, så brug det. Hvis ikke, så byg det, og udfyld hele skærmen som en arkitekt.
Næste modul stiller et endnu tidligere spørgsmål: Skal disse data overhovedet være i Salesforce?
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”- Om Salesforce allerede har et standardobjekt til det her, før du bygger et brugerdefineret.
- API-navnet, valgt én gang, og en beskrivelse skrevet til både mennesker og maskiner.
- Postnavnet: Text eller Auto Number, med den forventede volumen i tankerne.
- Hvilke valgfrie funktioner, hvilken API-adgang og hvilken søgning der skal slås til, med vilje.
- Hvad suffikserne i en org fortæller dig: brugerdefineret, managed, big object, eksternt objekt, personkonto.
- Om en pakke, du er ved at installere, kan støde sammen med det, du har bygget.
Læs mere
Sektion kaldt “Læs mere ”- Custom Objects (opens in a new tab) og Custom Fields (opens in a new tab), Object Reference (på engelsk, kontrolleret 2026-10-13): Navnene på brugerdefinerede objekter har et suffiks med to understregninger efterfulgt af et lille »c«; det samme gælder brugerdefinerede felter; og tabellen over standardobjekter, der understøtter brugerdefinerede felter.
- AppExchange Object Prefixes and the API (opens in a new tab), Object Reference (på engelsk, kontrolleret 2026-10-13): Et namespace-præfiks gør hver pakket komponent unik; »name__c becomes prefix__name__c«.
- Namespace Prefix (opens in a new tab), Apex Developer Guide (på engelsk, kontrolleret 2026-10-13): Namespace-præfikser holder managed packages’ objekt- og feltnavne adskilt fra andre org’ers.
- Editable Properties After Package Promotion or Installation (opens in a new tab), Second-Generation Managed Packaging Developer Guide (på engelsk, kontrolleret 2026-10-13): hvilke egenskaber ved en pakkes komponenter udvikleren, abonnenten, begge eller ingen af dem kan redigere.
- Custom Object Standard Fields (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-12): de standardfelter, hvert brugerdefineret objekt får (Name, Owner, Created By, Last Modified By, Currency, Division), og hvorfor Owner fjernes på detaljesiden af en master-detail-relation.
- Standard User Licenses (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-12): En Lightning Platform Light App kan ikke bruge Bulk API eller Streaming API (»can’t use the Bulk API or Streaming API«); en Enterprise App understøtter deling på postniveau og kan bruge Bulk API og Streaming API.