Kentätkin ovat arkkitehtuuria

🌐 Saatavilla myös 28 kielellä

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 · Norsk bokmål · Español (México) · Français (Canada) · Deutsch (Schweiz)

Kuva on luotu tekoälyllä

Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Moduuli 6/10 luvussa Salesforcen tietoarkkitehtuuri, Data Architect -kurssin luku 3. Jokainen moduuli on itsenäinen. Edellinen: Valitse oikea objekti · Seuraava: Suhteilla on seurauksia

Kysymys, johon tämä moduuli vastaa: Miten Salesforcen pitäisi fyysisesti esittää kukin tieto?

Kentän luominen vie noin minuutin. New Field, valitse tyyppi, nimeä se, Next, Next, Save. Juuri siksi kenttiä ei kohdella arkkitehtuurina.

Mene orgiin, joka on ollut olemassa kymmenen vuotta, ja avaa tili (Account). Viisisataa kenttää. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Kolme eri asiakasnumeroa. Valintaruutu, jota kukaan ei poista, koska kukaan ei tiedä, mikä integraatio sitä vielä käyttää. Kentän luominen vei minuutin. Sen kanssa eläminen vie vuosia. Joten tämän moduulin ajatus on yksinkertainen: kenttä on arkkitehtuuripäätös. Ei aina iso, mutta jokainen kenttä koodaa jotain tietojen merkityksestä, toiminnasta, tunnistamisesta tai laadusta, ja objektien tavoin kenttiä on helppo lisätä ja yllättävän vaikea poistaa.

Mitä nämä tiedot oikeastaan tarkoittavat?

Luvussa 2 annoimme entiteeteillemme attribuutit: toimituksella (Delivery) on suunniteltu aikaikkuna, kuorma-autolla (Truck) on VIN-tunnus. Nyt toteutamme ne, ja tässä kohdassa ihmiset hyppäävät suoraan ”tekstikenttään”. Odota. Ennen tyyppiä haluan tietää, mitä tiedot tarkoittavat. Onko se luku vai tunniste, jossa sattuu olemaan numeroita? Päivämäärä vai ajanhetki? Vapaata tekstiä vai yksi hyväksytyistä arvoista? Syöttääkö sen ihminen, vai omistaako sen toinen järjestelmä? Voiko se muuttua? Pitääkö sen olla yksilöllinen? Voiko se puuttua? Pitäisikö se tallentaa lainkaan vai laskea? Nämä eivät ole Setup-kysymyksiä. Ne ovat tietoarkkitehtuurikysymyksiä, ja kenttätyyppi tulee vasta, kun olemme vastanneet niihin.

Numero ei aina ole luku

Steve Trucking antaa jokaiselle kuorma-autolle kalustonumeron, vaikkapa 001247. Number-kenttä? Luultavasti ei. Laskemmeko kalustonumeroita yhteen? Onko auto 1247 miinus auto 1246 yksi auto? Se on tunniste, jossa sattuu olemaan numeroita, ja Number-kenttä jopa pudottaisi etunollat. Sama pätee postinumeroihin, tuotekoodeihin, tilinumeroihin ja seurantanumeroihin. Se, miltä arvo näyttää, ei kerro, mitä se tarkoittaa. Valitse tyyppi tarvitsemasi toiminnan mukaan, älä sen mukaan, miltä esimerkkitiedot näyttävät.

Tarvitseeko ihmisen tunnistaa se?

Jokainen mukautettu objekti saa Name-kentän, ja ensimmäinen päätös on teksti vai automaattinen numero. Kysyn: tarvitseeko ihmisen tunnistaa tämä asia? Ihmiset tuntevat vähittäiskauppakumppanin nimeltä ja kuorma-auton kalustonumerolta. Mutta kuormaluettelo (manifest), jonka järjestelmä tuottaa joka yö? Kenenkään ei pitäisi kirjoittaa ”Kuormaluettelo 10-02 numero 3” vain siksi, että Salesforce vaati nimen. Anna sille automaattinen numero. Älä vain sekoita tuota tuotettua nimeä tietueen tunnisteeseen: automaattinen numero auttaa käyttäjiä, Salesforcen ID yksilöi tietueen, ja vähittäiskauppakumppanin oma kuormaluetteloviite voi yksilöidä saman asian järjestelmien välillä. Kolme eri tehtävää.

Tietonäkymä

Valitse tyyppi, napsauta Next, niin Setup kysyy yksityiskohtia. Tässä näkymässä suurin osa tämän moduulin päätöksistä oikeasti tehdään, yleensä kiireessä.

New Custom Field, vaihe 2: yksityiskohdat (kuvakaappaus, 2026-10-12). Täysikokoinen

Kaksi kenttää näyttää samalta mutta tekee eri tehtäviä. Description (kuvaus) on orgia ylläpitäville ihmisille, ja nykyään myös sitä lukeville tekoälytyökaluille: mitä kenttä tarkoittaa, kuka sen omistaa, mistä se tulee. Help Text (ohjeteksti) on näytön ääressä olevalle käyttäjälle: mitä tähän kirjoitetaan. Täytä molemmat. Sitten tulevat Required, Unique ja External ID, ja kukin niistä ansaitsee oman osionsa. Niiden alla Default Value (oletusarvo) voi olla kaava, joten uusi tietue voi alkaa järkevällä arvolla tyhjän sijaan.

Required on isompi päätös kuin miltä näyttää

Kenttäohjatussa toiminnossa on pieni valintaruutu nimeltä Required (pakollinen), ja kuten näimme luvussa 1, se voi olla aikapommi. Sinulla on ollut objekti viisi vuotta ja kaksi miljoonaa tietuetta, ja nyt joku päättää, että uudella kentällä on aina oltava arvo. Entä ne kaksi miljoonaa tietuetta, jotka ovat sitä vanhempia? Integraatiot, jotka eivät lähetä sitä? Automaatio, joka luo tietueen ennen kuin arvo tiedetään? Prosessi, jossa arvo selviää vasta kolme vaihetta myöhemmin?

”Pakollinen” kuulostaa tietojen laadun päätökseltä, ja joskus se onkin. Mutta se, milloin arvo tulee tiedetyksi, on osa liiketoimintaprosessia. Älä siis rastita Required-ruutua siksi, että joku sanoo ”haluamme sen aina”. Kysy, milloin se tiedetään, kuka sen antaa ja mitä tapahtuu, kun sitä ei ole. Sijoitamme tämän koko johdonmukaisuuden tikkaille moduulissa 7.

Myös yksilöllisyys tarkoittaa jotain

Jos merkitsen kentän yksilölliseksi, teen väitteen liiketoiminnasta: en ”se ei yleensä toistu”, vaan ”kahdella tietueella ei saa koskaan olla tätä arvoa”. Se on vahva väite. Ja näkymä pakottaa päättämään vielä yhden asian: ovatko ”ABC” ja ”abc” sama arvo vai eri arvoja? Kirjainkoosta riippumaton on turvallisempi oletus kaikelle, mitä ihminen kirjoittaa. Luvun 2 avainsääntö, yksilöllinen, muuttumaton, merkityksetön, ei koskaan henkilötietoa (PII), pätee tässä. Jos joku sanoo minulle, että työntekijän sähköpostiosoite on yksilöllinen, alan kysellä: voiko se muuttua, voiko joku lähteä ja palata, voidaanko osoitteita käyttää uudelleen, mitä tapahtuu yrityskaupan jälkeen? Sähköposti voi olla hyödyllinen, jopa yksilöllinen tänään. Se ei tee siitä hyvää tunnistetta.

External ID:t: tunnistaminen rajan yli

Tässä External ID:t ansaitsevat paikkansa. Näkymä kuvaa sen hyvin: kentästä tulee ulkoisen järjestelmän yksilöllinen tietueen tunniste (”the unique record identifier from an external system”). ERP:ssä on asiakas 873492; Salesforcella on oma tietueen ID:nsä. Kun ERP lähettää päivityksen, mistä tiedämme, mihin tietueeseen se kuuluu? Merkitse kenttä External ID:ksi, niin integraatio voi tehdä upsertin sen perusteella: luoda tietueen, jos sitä ei ole, ja päivittää sen, jos on (Upsert a Record Using an External ID (opens in a new tab)). Ja kun lataat lapsitietueita, voit osoittaa vanhempaan sen External ID:n avulla sen sijaan, että hakisit ensin Salesforcen ID:n. Sanon mielelläni, että annat Salesforcen tehdä haun puolestasi. Todella tehokasta.

Huomaa, että ERP:n numerosta ei tule Salesforce-tietueen tunnistetta. Se on attribuutti, ja tietueella voi olla niitä useita: ERP:n asiakas-ID, vanhan järjestelmän ID, kumppanin ID. Se on hyvä. Useat järjestelmät voivat tuntea yhden liiketoimintaentiteetin eri tavoin. Arkkitehtuurinen kysymys on, mikä järjestelmä omistaa kunkin tunnisteen ja minkä lupauksen se antaa: merkitse se yksilölliseksi vain, jos liiketoiminta todella takaa sen.

Kenttätyyppi kerrallaan

Nyt itse tyypit. Avaa New Field missä tahansa objektissa, niin Setup näyttää koko luettelon ryhmiteltynä samalla tavalla kuin käyn sen läpi: kentät, jotka Salesforce laskee puolestasi, suhdekentät ja sitten tietotyypit.

Setup, New Custom Field, vaihe 1: tietotyypit (kuvakaappaus, 2026-10-12). Täysikokoinen

Tässä koko luettelo yhdellä silmäyksellä, ja kustakin se yksi asia, jonka haluaisin sinun muistavan.

Ryhmä	Tyyppi	Muista
Lasketut	Auto Number	Enintään 30 merkkiä, joista 20 etu- tai jälkiliitettä; nimike ihmisille, ei tietueen tunniste
	Formula	Lasketaan luettaessa, ei tallenneta; 3 900 merkkiä
	Roll-Up Summary	Detail-tietueiden määrä, summa, minimi tai maksimi; vain master-detail
Suhteet	Lookup, Master-Detail, External Lookup	Moduuli 7
Tiedot	Checkbox	Tosi tai epätosi, valitsemasi oletusarvo; null voi silti esiintyä flow’ssa
	Number, Percent, Currency	Pyöristyssäännöt; etunollat putoavat; 15 desimaalia
	Date, Date/Time, Time	Päivä, hetki tai kellonaika; hetket tallennetaan UTC-aikana
	Email, Phone, URL	Muotoillaan ja tarkistetaan tallennettaessa: 80, 40 ja 255 merkkiä
	Geolocation, Address	Yhdistelmäkentät, jotka maksavat enemmän kuin yhden kentän: 3 ja 9
	Picklist, Multi-Select	Hallittu sanasto, jonka omistaa ylläpitäjä
	Text, Text Area, Long, Rich, Encrypted	Enintään 255 tietueessa ja indeksoitavissa; sen yli ei indeksiä eikä suodatusta

Kentät, jotka Salesforce laskee

Auto Number antaa jokaiselle uudelle tietueelle sarjan seuraavan numeron määrittämässäsi muodossa, kuten T-{000000}. Käytä sitä, kun ihminen tarvitsee kätevän tunnuksen eikä kenenkään pitäisi joutua keksimään sitä. Koko arvo on enintään 30 merkkiä, ja niistä 20 on varattu etu- tai jälkiliitteelle. Muista vain luvusta 2: se on nimike ihmisille, ei tietueen tunniste, eivätkä numerot ole aina tiukasti peräkkäisiä.

Formula-kentät laskevat arvon muista kentistä. Ne ovat tehokkaita, ja ne lasketaan, kun tietue luetaan, eivät kun se tallennetaan, joten mitään tallennettua ei pääse vanhenemaan. Valitset, mitä kaava palauttaa: valintaruudun, valuutan, päivämäärän, päivämäärän ja ajan, luvun, prosentin, tekstin tai kellonajan.

New Custom Field, kaava: palautustyypin valinta (kuvakaappaus, 2026-10-12). Täysikokoinen

Sitten kirjoitat itse kaavan kenttineen, operaattoreineen ja funktioineen ja tarkistat sen syntaksin. Huomaa Use Formula Assistant -painike: Salesforcen tekoäly auttaa nyt kirjoittamaan kaavan. Käytä sitä ja lue sitten, mitä se kirjoitti. Sinä omistat kaavan, et avustaja.

Kaavaeditori ja Formula Assistant (kuvakaappaus, 2026-10-12). Täysikokoinen Kaava voi olla enintään 3 900 merkkiä, eikä se saa ylittää 15 000 tavua tallennettuna tai käännettynä; pitkän kaavan voi jakaa useisiin kaavakenttiin, jotka viittaavat toisiinsa. Pitkiä tekstialueita, salattuja kenttiä ja Description-kenttiä ei voi käyttää niissä.

Roll-Up Summary -kentät ovat master-tietueessa ja laskevat sen detail-tietueiden määrän, summan, minimin tai maksimin. Ne toimivat vain master-detail-suhteen yli, mikä on yksi suurimmista syistä valita master-detail ylipäätään. Palaamme niihin ja niiden rajoihin moduulissa 7.

Tallennettu vai johdettu?

Pitääkö tämä arvo tallentaa lainkaan? Jos minulla on määrä ja yksikköhinta, pitääkö jonkun, tai jonkin automaation, ylläpitää loppusummaa? Ehkä kaavan pitäisi johtaa se: yksi lähde laskennalle, laskettuna uudelleen luettaessa, joten muuta määrää, niin vastaus seuraa perässä. Kaavoilla on omat rajansa (tallennuskoko ja näytettävä pituus; Formula Field Limits and Restrictions (opens in a new tab)), ja monimutkaisia on vaikea ylläpitää.

Mutta joskus liiketoiminta ei halua tämän päivän vastausta. Se haluaa vastauksen sellaisena kuin se oli. Jos alennussääntö muuttuu ensi vuonna, pitäisikö viime vuoden laskun yhtäkkiä näyttää eri summaa? Ei tietenkään. Kysymys ei siis ole ”voiko Salesforce laskea tämän?” Se on ”onko tämä ajantasainen laskelma vai historiallinen tosiasia?” Historialliset tosiasiat tallennetaan.

Suhdekentät

Lookup-, Master-Detail- ja External Lookup -suhteet ovat nekin kenttiä, ja niissä mallisi viivoista tulee todellisia. Lookup on löysä linkki; master-detail sitoo lapsen elämän, omistajuuden ja suojauksen vanhempaan; external lookup ylettyy moduulin 4 ulkoiseen objektiin ja täsmää sen External ID:hen. Niiden välillä valitseminen on niin iso päätös, että se saa oman moduulinsa.

Checkbox

Valintaruutu (Checkbox) on yksinkertaisin kenttä, mitä on: tosi tai epätosi, valittu tai valitsematon. Se sopii täydellisesti tietueen kyllä/ei-tosiasialle: Is Active, Install Required, Signed For. Kun luot sellaisen, Salesforce pakottaa valitsemaan sen oletusarvon, valittu tai valitsematon, ja se on todellinen päätös: sillä jokainen uusi tietue alkaa, myös tietueet, jotka integraatio luo lähettämättä kenttää. Raportit ja luettelonäkymät suodattavat sen arvoina True ja False; tuontityökalut ja viikoittainen vienti näyttävät sen arvoina 1 ja 0.

Yksi ansa, joka on hyvä tietää. Tietueen kentällä on kaksi arvoa, mutta sen ympärillä olevalla automaatiolla voi olla kolmas. Flow’ssa valintaruutumuuttuja, jota ei koskaan asetettu, on null eikä false, ja sen tallentaminen tietueeseen epäonnistuu (Trailblazer Community (opens in a new tab); katso myös Salesforcen tunnettu ongelma W-11208535 (opens in a new tab)). Valitse järkevä oletusarvo, ja käsittele null flow’issa ja koodissa tarkoituksella.

Number, Percent ja Currency

Number tallentaa reaaliluvun ja pudottaa mahdolliset etunollat, ja juuri siksi 001247-kaltainen kalustonumero ei ole Number. Salesforce pyöristää lukukentät puolikkaat poispäin nollasta: 12,345 muuttuu muotoon 12,35, ja −12,345 muotoon −12,35. Ja yhdistämiskentissä (merge fields) se pyöristää käyttäjän alueasetusten mukaan, ei kenttään asettamiesi desimaalien mukaan.

Percent tallentaa desimaaliluvun ja näyttää prosentin: syötä 0,10, niin näet 10 %. Arvot menettävät tarkkuutta 15 desimaalin jälkeen.

Currency on muotoiltu rahalle, ja orgissa, jossa on useita valuuttoja, se kantaa valuuttakoodiaan ja voi käyttää valuuttakursseja; edistyneen valuutanhallinnan (opens in a new tab) (advanced currency management) avulla myyntimahdollisuudet voivat käyttää päivättyjä valuuttakursseja, eli sen jakson kurssia, jolla kauppa suljettiin. Vain myyntimahdollisuudet ja niiden ympärillä olevat asiat (tuotteet, aikataulut, jaot ja niiden raportit) käyttävät päivättyjä kursseja; muiden objektien valuuttakentät pitävät yhden staattisen kurssin. Varo pyöristystä: ilman desimaaleja Salesforce yksinkertaisesti katkaisee (23,5 muuttuu muotoon 23); yhdellä tai useammalla desimaalilla se pyöristää puolikkaat poispäin nollasta.

Date, Date/Time ja Time

Kolme tyyppiä, kolme eri merkitystä. Date on päivä: sopimus päättyy tiettynä päivänä. Date/Time on hetki: toimitus saapui sinä aamuna klo 9.42. Time on kellonaika ilman päivämäärää: myymälä aukeaa klo 7.00, joka päivä.

Ansa on hetki. Salesforce tallentaa päivämäärä- ja aika-arvot GMT-aikana (UTC). Käyttäjän kirjoittama aika luetaan hänen aikavyöhykkeessään, muunnetaan ja tallennetaan; kun joku lukee sen, se muunnetaan taas lukijan aikavyöhykkeeseen. Useimmiten juuri sitä haluat. Mutta tässä esimerkki, jota käytän kurssilla: Los Angelesissa työskentelevä koordinaattori kirjaa toimituksen myöhään sunnuntai-iltana, klo 22 Tyynenmeren aikaa. Pinnan alla Salesforce tallensi maanantaiaamun, klo 5 GMT. Raportti, joka ryhmittelee päivittäin toisella aikavyöhykkeellä, tai integraatio, joka lukee raakaa arvoa, voi siirtää tuon sunnuntain toimituksen maanantaille. ”Päivä, jona se tapahtui” riippuu siitä, kenen kellolta kysyt. Seuraa käyttäjien aikavyöhykkeitä ja päätä, mitä niistä liiketoiminta tarkoittaa.

Ja ole varovainen vertaillessasi niitä. Pinnan alla päivämäärä ja aika on yksi iso luku: Apex lukee sen millisekunteina 1.1.1970 klo 00.00.00 GMT:stä lähtien (Datetime Class (opens in a new tab)). Se on tarkka hetki, ei päivä. Joten kysymys siitä, ovatko kaksi päivämäärä-aika-arvoa yhtä suuret (==), ei melkein koskaan tee sitä, mitä haluat: 9.42.00 ja 9.42.01 eivät ole yhtä suuret, eivätkä myöskään ”maanantai” ja mikä tahansa maanantain hetki. Kysy sen sijaan väliä: alku tai sen jälkeen (>=) ja loppu tai sitä ennen (<=). ”Jokainen maanantain toimitus” on jokainen toimitus >= maanantai klo 00.00 ja <= maanantai klo 23.59.59, sillä aikavyöhykkeellä, jonka päätit liiketoiminnan tarkoittavan.

Ja hauska yksityiskohta: Salesforce ei voi tallentaa mitä tahansa päivämäärää. Kelvolliset päivämäärät ovat välillä 1.1.1700–31.12.4000, ja Salesforce antaa saman välin päivämäärille ja päivämäärä-aika-arvoille (Data Import Dates (opens in a new tab)). Reunatkin ovat GMT-hetkiä, joten Tyynenmeren aikavyöhykkeen käyttäjälle aikaisin kelvollinen arvo on 31.12.1699 klo 16. Kotiseutuyhdistyksesi perustamispäivä ei ehkä mahdu mukaan. Ja klassinen ”ei päättymispäivää” -temppu, 31.12.9999, hylätään; jos tarvitset kaukaisen tulevaisuuden paikkamerkin, sen on oltava vuonna 4000 tai aiemmin.

Email, Phone ja URL

Nämä ovat muotoiltuja kenttiä, ja ne tekevät enemmän kuin tallentavat merkkejä. Email sisältää enintään 80 merkkiä, ja sen muoto tarkistetaan; yhteyshenkilöissä ja liideissä sen napsauttaminen aloittaa sähköpostin siihen osoitteeseen. Phone sisältää enintään 40 merkkiä, se muotoillaan puhelinnumeroksi, ja siitä tulee click-to-dial (soita napsauttamalla), kun orgiin on yhdistetty puhelinjärjestelmä. URL sisältää enintään 255 merkkiä ja avautuu linkkinä. Siinä alusta antaa sinulle toimintaa ilmaiseksi, ja siksi en koskaan tallentaisi puhelinnumeroa tavalliseen tekstikenttään.

Myös integraatiot tarkistetaan. Arvo, joka ei vastaa kentän muotoa, kuten virheellisesti muodostettu sähköpostiosoite, ei läpäise vahvistusta, ja koko tietue hylätään, ei vain se kenttä. Joten kun lähdejärjestelmän tiedot ovat sotkuisia, siivoa ne ennen kuin ne saapuvat, tai varaudu tietueisiin, jotka eivät lataudu.

Geolocation ja Address

Geolocation sisältää leveys- ja pituusasteen. Pinnan alla kenttä nimeltä Location__c on oikeastaan kaksi arvoa, joita voi lukea ja asettaa erikseen: Location__Latitude__s ja Location__Longitude__s. Ja sen perusteella voi tehdä kyselyjä: SOQL:n DISTANCE- ja GEOLOCATION-funktiot löytävät tietueet tietyn säteen sisältä tai järjestävät ne etäisyyden mukaan. ”Jokainen avoin toimitus 25 mailin säteellä tästä kuorma-autosta” on yksi kysely: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab)). Address sisältää kokonaisen osoitteen, katuosoitteen, kaupungin, osavaltion tai provinssin, postinumeron ja maan, ja käyttäjät voivat hakea osoitetta ja saada osat täytetyiksi.

Molemmat ovat yhdistelmäkenttiä (compound fields): yksi kenttä näytöllä, useita pinnan alla. Ja ne maksavat objektisi rajaa vastaan enemmän kuin yhden kentän: Geolocation lasketaan kolmeksi mukautetuksi kentäksi ja Address yhdeksäksi. Objektissa, joka on jo täynnä, sillä on väliä.

Picklist ja Multi-Select

Valintaluettelo (picklist) hallitsee, mitä käyttäjät voivat syöttää: yhden arvon määrittämästäsi luettelosta. Tila? Valintaluettelo, luultavasti. Mutta arvot ovat metatietoa, ja ylläpitäjän on lisättävä tai muutettava ne. Joten kysyn silti, kuka omistaa arvot, kuinka usein ne muuttuvat, tarvitsevatko useat objektit saman luettelon, kantavatko arvot omaa tietoa ja omistaako sanaston jokin toinen järjestelmä.

Myös se, missä arvot asuvat, on päätös. Kun luetteloa käytetään kerran, yhdessä kentässä, pidä arvot itse kentässä, objektissa; niin Salesforce tekee oletuksena. Mutta kun sama arvojoukko alkaa näkyä useissa paikoissa, alue (Region) tilissä, toimituksessa ja varastossa, ylennä se yleiseksi arvojoukoksi ennen kuin kopiot ajautuvat erilleen. Yleinen arvojoukko (global value set) pitää yhden luettelon niille kaikille, enintään 1 000 arvoa aktiiviset ja passiiviset yhteensä (Picklist Limitations (opens in a new tab)). Setupin oma kuvaus kertoo, miksi sillä on väliä: arvojoukko on rajoitettu, joten käyttäjät eivät voi lisätä hyväksymättömiä arvoja API:n kautta (”is restricted so users can’t add unapproved values through the API”). Yksi luettelo, yksi omistaja, eikä mikään integraatio salakuljeta sisään uutta kirjoitusasua.

Tuo viimeinen kohta on ero rajoitetun ja rajoittamattoman välillä. Rajoitetussa valintaluettelossa sallitaan vain ylläpitäjän määrittämät arvot, tulivat ne mistä tahansa: käyttäjä, tuonti tai integraatio, joka lähettää jotain muuta, saa virheen ”bad value for restricted picklist field”, eikä tietuetta tallenneta. Rajoittamattomassa valintaluettelossa käyttäjät valitsevat yhä näytön luettelosta, mutta API, tuonnit ja automaatio voivat lähettää minkä tahansa arvon, ja Salesforce tallentaa sen ja lisää sen passiivisena arvona (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab)). Niin orgiin päätyy ”Delivered”, ”delivered” ja ”Dlvrd”. Yleiset arvojoukot ovat aina rajoitettuja. Oletukseni on rajoitettu; rajoittamaton on harkittu valinta silloin, kun toinen järjestelmä todella omistaa arvot, ja silloin jonkun vastuulla on passiivisten arvojen siivoaminen.

Setup, Picklist Value Sets: uusi yleinen arvojoukko (kuvakaappaus, 2026-10-12). Täysikokoinen

Monivalintaluettelo (multi-select picklist) antaa käyttäjän valita useita arvoja, jotka tallennetaan yhdessä puolipisteillä erotettuina. Kätevä näytöllä, kömpelö kaikkialla muualla: vaikeampi suodattaa, raportoida ja integroida, eikä sitä voi käyttää koontikentän (roll-up summary) suodattimessa. Useampi arvo yhdelle tietueelle tarkoittaa yleensä luvun 2 opetusta: siellä on lapsiobjekti yrittämässä ulos.

Valintaluettelolla on myös yksi arvo enemmän kuin määrittämäsi: tyhjä. Tietue voi olla ilman valintaa, ja se yllättää ihmiset. Kaavassa tai vahvistussäännössä valintaluetteloa ei voi testata pelkällä ISBLANKilla; kirjoitat ISBLANK(TEXT(Field__c)) tai ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab)). Päätä siis jokaisen valintaluettelon kohdalla, mitä ”ei arvoa” tarkoittaa: onko se sallittu, ja mitä se tarkoittaa, kun niin käy? Tee sitten kaavoistasi, vahvistussäännöistäsi ja suodattimistasi sellaiset, että ne käsittelevät sen.

Ja joskus attribuutti on oikeastaan entiteetti. Joku pyytää valintaluetteloa jakelukeskuksista. Niitä on yhdeksän. Helppoa. Sitten selviää, että jokaisella on osoite, johtaja, aukioloajat, kapasiteetti, alue ja kuorma-autoja. Se ei ole valintaluettelo; se on asia. Älä tee entiteetistä valintaluetteloa vain siksi, että niitä ei ole vielä montaa. Se tuntuu hienolta ensimmäisenä vuonna ja kamalalta viidentenä. (Luvun 2 moduulissa 5 ovat nyrkkisääntöni siihen, milloin luettelo ansaitsee oman objektinsa.)

Tekstiperhe

Opetan tekstin kahtena lajina, ja niiden välinen raja on 255 merkkiä.

Enintään 255: tallennetaan tietueen mukana. Text sisältää enintään 255 merkkiä, ja sitä voi käyttää melkein missä tahansa: kaavoissa, suodattimissa, raporteissa, luettelonäkymissä, yksilöllisenä kenttänä tai External ID:nä, ja sen voi indeksoida. Text Area sisältää myös 255 merkkiä, eri riveillä, kuten lyhyt muistiinpano.

Yli 255: tallennetaan viittauksena. Text Area (Long) sisältää enintään 131 072 merkkiä, ja Text Area (Rich) sisältää saman määrän muotoiluineen, linkkeineen ja kuvineen. Ajattelen niiden olevan tallennettuina sivuun niin, että tietueessa on osoitin, ja ne käyttäytyvät niin: ei indeksiä, joten niistä ei voi tehdä yksilöllisiä eikä External ID:tä; niillä ei voi suodattaa SOQL:n WHERE-lauseessa (SOQL WHERE (opens in a new tab)); kaavat eivät voi käyttää niitä (Formula Field Limits and Restrictions (opens in a new tab)); ja raportit näyttävät mukautetusta kentästä vain ensimmäiset 254 merkkiä, ja raporttisuodattimet hakevat vain noin ensimmäisistä 255 merkistä (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Rich text -kenttään ladatut kuvat voivat olla enintään 1 Mt kukin, ja ne lasketaan tiedostotallennustilaan, kun taas teksti lasketaan tietotallennustilaan (Rich Text Area Field Considerations (opens in a new tab)). Joten jos jonkun pitää hakea, järjestää, täsmäyttää tai raportoida arvon perusteella, pidä se alle 255 merkissä ja pidä se Text-kenttänä.

Text (Encrypted) tallentaa enintään 175 merkkiä salatussa muodossa Classic Encryptionilla. Jos orgisi käyttää Shield Platform Encryptionia, salaat sen sijaan tavallisen Text-kentän, ja monia muitakin tyyppejä voi salata sillä tavalla.

Anna jokaiselle kentälle kuvaus

Standardini: jokainen kenttä saa kuvauksen. Olen uskonut siihen pitkään, ja tekoälyn aikakaudella sillä on enemmän merkitystä kuin koskaan: jokainen orgiasi lukeva tekoälytyökalu ja agentti lukee kuvaukset ymmärtääkseen, mitä kenttä tarkoittaa. Tyhjä kuvaus on arvaus, joka odottaa tapahtumistaan. Mitä Customer_Status__c tarkoittaa? Kuka sen omistaa? Mistä se tulee? Voivatko käyttäjät muokata sitä, vai kirjoittaako ERP sen yli tänä yönä? Puolen vuoden päästä en muista, ja kolmen vuoden päästä orgia ylläpitävä ylläpitäjä ei tiedä, ellemme kertoneet hänelle. Nimike ei ole dokumentaatiota, eikä API-nimikään ole.

Paljon jaetuissa objekteissa (Account, Contact, Opportunity) käytän myös nimeämisetuliitteitä erikoiskentille, jotta niiden alkuperä ja tarkoitus näkyvät itse nimessä: esimerkiksi kaikki, minkä ERP omistaa, alkaa samalla etuliitteellä. En tavoittele kahdentoista sanan API-nimiä. Haluan, että malli selittää itse itsensä.

Luokittele se, millä on väliä: taksonomiakentät

Salesforce antaa jokaiselle kentälle joukon luokittelumetatietoja. Kutsun niitä taksonomiakentiksi. Voit kirjata tietojen omistajan (data owner); kentän käytön (field usage: Active, DeprecateCandidate, Hidden); tietojen arkaluonteisuustason (data sensitivity level: Public, Internal, Confidential, Restricted, MissionCritical); sekä vaatimustenmukaisuusluokittelun (compliance categorization): PII, HIPAA, GDPR, PCI, CCPA ja muut. Ne toimivat vakiokentissä siinä missä mukautetuissakin (Data Classification Metadata Fields (opens in a new tab)).

Miksi vaivautua? Koska prosessit voivat lukea niitä. Merkitse kenttä GDPR-kentäksi, niin prosessi voi löytää tietueen jokaisen GDPR-kentän ja peittää tai poistaa sen. Ja kun Salesforcen luottamuskerros (trust layer) lähettää kehotteen suurelle kielimallille, se voi käyttää juuri tätä luokittelua arkaluonteisten kenttien peittämiseen: se vaihtaa asiakkaan nimen, vaikkapa ”Maria Lopez”, paikkamerkkiin matkalla ulos, malli ei koskaan näe nimeä, ja nimi vaihdetaan takaisin vastaukseen matkalla sisään (Einstein Trust Layer (opens in a new tab)).

Päivitys. Salesforce dokumentoi nyt, että kuvio- ja kenttäpohjainen peittäminen kielimalleille on poistettu käytöstä agenteilta: peittäminen voi riisua kontekstin, jota agentti tarvitsee vastatakseen (Data Masking Limitations in Agentforce (opens in a new tab)). Luokittelu ohjaa yhä peittämistä muissa generatiivisen tekoälyn ominaisuuksissa, mutta älä luota siihen henkilötietojen pitämisessä poissa agentilta; se on pääsyn ja suunnittelun päätös (luku 12).

Kantani: luokittelu on tärkeää ratkaisevina hetkinä. Älä tee siitä kolmen viikon urakkaa jokaisen ruudun täyttämiseksi, koska hallintomalli niin sanoi. Käytä sitä siellä, missä sillä on väliä: henkilötiedot, taloustiedot, säännellyt tiedot ja kentät, joille liiketoiminta tarvitsee nimetyn omistajan. Pointti on, että arkaluonteisuus lakkaa olemasta tietoa jonkun päässä ja muuttuu osaksi kenttää.

Kokeen jälkeen: mitä tekoäly muuttaa. Huono kenttädokumentaatio rankaisi ennen seuraavaa ylläpitäjää. Nyt se johtaa harhaan jokaista skeemaa lukevaa tekoälytyökalua ja agenttia: onko Flag2__c arkaluonteinen, auktoritatiivinen, yhä käytössä? Tekoäly myös luo kenttiä nopeammin kuin mikään tiimi, joten nimet, kuvaukset ja luokittelu ovat osa arkkitehtuuria, eivät kotitaloustöitä.

Jokainen kenttä on sitoumus

Kun kenttä on kerran käytössä keräämässä tietoja, kaikki alkaa nojata siihen. Näkymät näyttävät sen, flow’t haarautuvat sen mukaan, vahvistussäännöt tarkistavat sen, raportit ryhmittelevät sen mukaan, integraatiot lähettävät ja lukevat sitä, ja nyt tekoälytyökalut päättelevät sen perusteella. Jokainen niistä tekee kentästä oletuksia: sen tyypistä, sen pituudesta, onko se koskaan tyhjä ja mitä sen arvot tarkoittavat. Muuta kenttää myöhemmin, niin sinun on ensin löydettävä jokainen noista oletuksista. Valintaluettelon arvon nimeäminen uudelleen, tekstikentän lyhentäminen tai Text-kentän muuttaminen valintaluetteloksi kuulostaa pieneltä muutokselta, ja se voi rikkoa integraation toisen yrityksen järjestelmässä. Siksi kenttä on sitoumus.

Click to enlarge

En halua, että lähdet tästä moduulista peläten kenttien luomista. Salesforce on rakennettu laajennettavaksi; käytä sitä. Haluan, että kysymys muuttuu muodosta ”minkä kenttätyypin valitsisin?” muotoon ”mitä nämä tiedot tarkoittavat, ja mihin toimintaan sitoudumme?” Tyyppi, pakollisuus, yksilöllisyys, External ID, valintaluettelo, kaava, kuvaus, luokittelu: yhdessä ne ovat luvun 2 loogisen mallin fyysinen ilmentymä.

Mitä arkkitehti tässä päättää

• Mitä arvo tarkoittaa ennen kenttätyypin valintaa, ja onko se attribuutti, tunniste, hallittu sanasto vai oikeastaan toinen entiteetti.
• Onko arvo ajantasainen laskelma, joka voidaan johtaa, vai historiallinen tosiasia, joka on tallennettava.
• Mikä järjestelmä omistaa kunkin tunnisteen, ja onko sen yksilöllisyys todellinen liiketoiminnan lupaus.
• Milloin pakollinen arvo oikeasti tiedetään, ja mitä tapahtuu tietueille ja integraatioille, joilla sitä ei ole.
• Mitä kuvausta, nimeämistä ja luokittelua kenttä tarvitsee, jotta ihmiset, prosessit ja tekoäly voivat käyttää sitä turvallisesti.

Lue lisää

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab), englanniksi, tarkistettu 2026-10-02.
• Salesforce Help, Einstein Trust Layer: Designed for Trust (opens in a new tab) ja Data Masking Limitations in Agentforce (opens in a new tab), englanniksi, tarkistettu 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab), englanniksi, tarkistettu 2026-10-02.
• Salesforce Help, Picklist Limitations (opens in a new tab), englanniksi, tarkistettu 2026-10-02.
• Salesforce Help, Formula Field Limits and Restrictions (opens in a new tab), englanniksi, tarkistettu 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab), englanniksi, tarkistettu 2026-10-02.