Tietojen pitäminen johdonmukaisina

🌐 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 9/10 luvussa Salesforcen tietoarkkitehtuuri, Data Architect -kurssin luku 3. Jokainen moduuli on itsenäinen. Edellinen: Omistajuus ja elinkaari · Seuraava: Suunnittele Salesforcen fyysinen malli

Kysymys, johon tämä moduuli vastaa: Miten pidän tiedot johdonmukaisina, ja mitä kukin kerros maksaa?

Kaikki haluavat puhtaita tietoja. En ole koskaan astunut vaatimuspalaveriin, jossa joku olisi sanonut: ”Haluaisimme oikeastaan epäjohdonmukaisia tietoja.” Erimielisyys tulee myöhemmin: missä säännöt pannaan täytäntöön? Näytöllä? Pakollisella kentällä? Valintaluettelolla, vahvistussäännöllä, kaksoiskappalesäännöllä, flow’lla, Apexilla? Ne kaikki auttavat. Ne eivät ole keskenään vaihdettavissa, ja jokaisella kerroksella on hintansa.

Yleissääntöni on työntää sääntö niin alas kuin kohtuudella voi. Jos arvo voi olla vain yksi viidestä vaihtoehdosta, älä anna ihmisten kirjoittaa mitä tahansa ja siivoa sitä myöhemmin automaatiolla. Jos kahdella tietueella ei saa koskaan olla samaa tunnistetta, älä luota siihen, että joku huomaa sen raportista. Jos säännön on pidettävä, tuli tietue sitten näytöltä, API:sta, integraatiosta, tietojen latauksesta tai agentilta, älä pane sitä täytäntöön vain käyttöliittymässä. Mitä lähempänä tietoja sääntö on, sitä vaikeampi sitä on kiertää. Kutsun tätä johdonmukaisuuden tikkaiksi.

Ensimmäinen askelma: kenttätyyppi ja sanasto

Ensimmäinen johdonmukaisuussääntö on moduulista 6: valitse oikea tyyppi. Päivämäärä on Date, hetki on Date/Time, raha on Currency. Se on johdonmukaisuutta ennen kuin kukaan kirjoittaa sääntöä.

Tee toimituksen tilasta tekstikenttä, niin saat arvot Delivered, delivered, DELIVERED, Complete, Done ja Dropped off, ja jonkun on selvitettävä, tarkoittavatko nuo kuusi samaa asiaa. Tai määritä sanasto kerran: Delivered, yksi arvo, yksi merkitys. Tee siitä rajoitettu valintaluettelo, jotta se hylkää kaiken, mikä ei ole luettelossa, myös API:n kautta, ja yleinen arvojoukko, kun useampi kenttä jakaa luettelon (moduulissa 6 ovat yksityiskohdat).

Mutta älä käytä valintaluetteloa vain estääksesi ihmisiä kirjoittamasta. Onko se oikeasti arvo vai toinen entiteetti? Yhdeksän jakelukeskusta, joilla kullakin on nimi, voi näyttää valintaluettelolta; yhdeksän, joilla on osoitteet, johtajat, kapasiteetti ja kuorma-autot, ovat tietueita. Säännön pitäisi vahvistaa mallia, ei paikata huonoa mallia. Ja jos se todella on hallittu sanasto, hallitse sitä kentässä. Älä salli kaaosta ja rakenna sitten flow’ta, joka muuttaa arvot AZ, Arizona, Ariz ja Phoenix area siksi arvoksi, jonka halusit alun perin.

Toinen askelma: pakollinen ja yksilöllinen

Required ja Unique houkuttelevat, koska ne ovat yksinkertaisia: rastita ruutu, ongelma ratkaistu. Joskus. Jos jokaisella kuorma-autolla on kalustonumero luomispäivästä lähtien eikä kahdella kuorma-autolla ole samaa, molemmat ruudut ilmaisevat todellisia liiketoimintasääntöjä. Se on vahvaa johdonmukaisuutta.

Mutta kun alusta panee säännön täytäntöön, se ei välitä siitä, että prosessissasi on poikkeus tiistai-iltapäivänä. Olen käyttänyt tätä esimerkkiä kurssilla vuosia. Objekti on ollut olemassa jonkin aikaa, ja tietueita on paljon. Joku lisää kentän ja rastittaa Required. Hän testaa tietueen luomista: toimii hienosti. Sitten lauantai-iltana käyttöönotto, testit ajetaan, ja vanha testiluokka luo objektin ilman uutta kenttää. Pum. Tai joku muokkaa vanhaa tietuetta ajalta ennen kentän olemassaoloa. Tai integraatio lähettää saman payloadin, jota se on lähettänyt viisi vuotta. Pum. ”Mutta emmehän me muuttaneet sitä kenttää.” Alusta ei välitä: muutit sopimusta siitä, mikä on kelvollinen tietue. Uusi sääntö ei vaikuta vain uusiin tietoihin; se muuttaa sitä, mitä voit tehdä vanhoille tiedoille.

Kolmas askelma: vahvistussäännöt

Vahvistussäännöillä voi sanoa paljon rikkaampia asioita. Jos tila on Delivered, todellinen toimitusaika on täytettävä. Jos pysähdys on asennus, tarkistuslistan on oltava valmis ennen kuin pysähdyksen voi sulkea. Ne ajetaan, kun tietue tallennetaan, joten ne suojaavat tietuetta, tallennettiinpa se sivulta, API:n kautta, tietojen latauksella, integraatiolla tai agentilla. Siinä on koko pointti. Jos säännön on suojattava tietuetta, sijoita se sinne, missä jokainen kirjoitus kohtaa sen.

Niillä on myös hampaat. Se on niiden vahvuus ja niiden hinta.

Vanhan tietueen ongelma

Tässä kohtaa siitä tulee rumaa. Sinulla on miljoona tietuetta, ja tänään lisäät säännön: toimitusaika ei voi olla ennen reitin lähtöä. Järkevää. Mutta kaksikymmentätuhatta vanhaa tietuetta rikkoo sitä seitsemän vuoden takaisen migraation ansiosta. Käyttäjä avaa yhden niistä ja muuttaa puhelinnumeron. Tallenna. Sääntö laukeaa. ”Muutin puhelinnumeron. Miksi kerrot minulle toimitusajasta vuodelta 2019?” Hyvä kysymys.

Vahvistussäännön ei siis pitäisi sanoa vain, minkä täytyy olla totta. Sen pitäisi sanoa, milloin se pannaan täytäntöön. Funktiot kuten ISNEW() ja ISCHANGED() antavat rajata säännön uusiin tietueisiin tai tallennuksiin, joissa olennaiset kentät todella muuttuvat (Validation Rule Considerations (opens in a new tab)).

Mutta tietue ei muutu vain silloin, kun ihminen muokkaa sitä, ja monet syyt ovat hallintasi ulkopuolella. Integraatio päivittää tilan yön aikana. Flow leimaa päivämäärän. Esihenkilö osoittaa alueen uudelleen, ja omistaja vaihtuu kymmenessätuhannessa tietueessa. Joku muokkaa toimitusriviä, toimituksen koontikenttä lasketaan uudelleen, ja se tallentaa toimituksen, joten toimituksen vahvistussääntö laukeaa käyttäjälle, joka ei koskaan koskenut siihen (Roll-Up Summary Field (opens in a new tab) varoittaa, että vahvistusvirheet voivat näkyä detail- tai master-tietueessa). Jokainen noista tallennuksista kohtaa uuden sääntösi. Joten kysy jokaisen uuden säännön kohdalla: pitäisikö tämän säännön koskea tuota tallennusta?

Nämä ovat vaihtoehdot, ja punot ne sääntöön:

• Aina, jokaisessa tallennuksessa. Oikein, kun sääntö todella koskee tietuetta ja vanhat tiedot läpäisevät sen. Mutta tiedä, mitä ”jokainen tallennus” tarkoittaa: myös eräajon, joka muuttaa vain omistajan, tai minkä tahansa pienen muokkauksen mihin tahansa tietueen kenttään on läpäistävä se.
• Vain uusille tietueille, ISNEW()-funktiolla. Sääntö tarkistaa tietueen kerran, kun se luodaan, eikä koskaan uudelleen. Menneisyys pysyy ennallaan, mutta niin pysyy tulevaisuuskin: myöhempi muokkaus voi saada uuden tietueen rikkomaan sääntöä, eikä kukaan pysäytä sitä. Jos sillä on väliä, yhdistä se seuraavaan.
• Vain kun sen kohteena olevat kentät muuttuvat, ISCHANGED()-funktiolla. Puhelinnumeron muokkaaminen ei herätä toimitusaikasääntöä.
• Ei tietyille kirjoittajille. Mukautettu käyttöoikeus (custom permission), joka tarkistetaan kaavassa muodossa $Permission, päästää integraatiokäyttäjän tai tietojen migraation läpi, kun taas ihmiset kohtaavat yhä säännön (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). Anna se tarkoituksella ja harvoille.
• Tietystä päivästä eteenpäin, vertaamalla CreatedDate-kenttää siihen päivään, jona sääntö otettiin käyttöön, kun ”uusi” tarkoittaa ”siitä lähtien, kun aloimme valvoa tätä”. Toisin kuin ISNEW(), se jatkaa noiden tietueiden tarkistamista jokaisessa myöhemmässä tallennuksessa, joten sama varoitus pätee: pieni muutos, kuten omistajan eräpäivitys, voi epäonnistua tietueessa, joka on ajautunut sivuun.

Lisäätkö säännön tietueisiin, jotka sinulla jo on? Mieti seuraukset ennen kuin otat sen käyttöön. Jokaisen olemassa olevan tietueen on nyt läpäistävä se seuraavassa tallennuksessaan, ja se tallennus voi tulla jostain, mitä et odottanut: öisestä integraatiosta, omistajan eräpäivityksestä, koontikentästä, luettelonäkymän joukkopäivityksestä. Mitkä niistä osuvat siihen, ja mitä sille ajolle tapahtuu, kun yksi tietue epäonnistuu? Osiossa Ennen kuin otat sen käyttöön on järjestys, jota käytän.

Älä kirjoita historiaa uudelleen säännön mieliksi

Entä ne kaksikymmentätuhatta vanhaa tietuetta? Jos tiedot ovat vääriä ja tiedät oikeat arvot, korjaa ne. Mutta olen nähnyt toisenlaisenkin ”korjauksen”: kukaan ei tiedä historiallista totuutta, tietueiden pitää vain läpäistä sääntö, joten ne päivitetään arvoilla, jotka tyydyttävät tämän päivän säännön. En pidä siitä. Vanhojen tietueiden päivittäminen säännön mukaisiksi muuttaa LastModifiedDate-kentän ja tuhoaa keskeistä historiallista tietoa, ja arvojen keksiminen tarkoittaa, että teeskentelemme tietävämme menneisyydestä jotain, mitä emme tiedä. Anna säännölle ohitus sitä vanhemmille tietueille sen sijaan, että kirjoittaisit historiaa uudelleen. Se voi olla rumaa, mutta se on rehellistä.

Käyttöliittymän vahvistus ei ole tietojen vahvistusta

Tee kentästä pakollinen sivuasettelussa, niin käyttäjät eivät voi tallentaa ilman sitä. Sitten öinen integraatio lisää 50 000 tietuetta. Käyttikö se sivuasi? Ei. Eikä joukkolataus, API-asiakas tai agentti. Käyttöliittymän vaatimus suojaa tuota näkymää, ei tietoja. Dynaamisten lomakkeiden (dynamic forms) kenttävahvistuksen voi kiertää samalla tavalla. Joten kysy: mistä nämä tiedot voivat tulla sisään? Lightning, portaali, mobiili, integraatio, API, joukkolataus, Flow, Apex, agentti. Mitä enemmän ovia on, sitä vähemmän luotan sääntöön, joka vartioi vain yhtä niistä.

Neljäs askelma: kaksoiskappalesäännöt

Nyt siirrymme tietueen sisäisestä johdonmukaisuudesta tietueiden välisen johdonmukaisuuteen. Acme Corporation, ACME Corp, Acme Inc.: neljä asiakasta vai yksi? Mikään kenttäsääntö ei voi vastata siihen. Vastaavuussäännöt (matching rules) määrittävät, miten tietueita verrataan; kaksoiskappalesäännöt (duplicate rules) päättävät, mitä tapahtuu, kun todennäköinen kaksoiskappale löytyy: salli varoituksella, estä tai raportoi. Objektilla voi olla enintään viisi aktiivista kaksoiskappalesääntöä ja kussakin enintään kolme vastaavuussääntöä, ja täsmäysavaimet (match keys) rajaavat kunkin vertailun 100 todennäköisimpään kaksoiskappaleeseen (Things to Know About Duplicate Rules (opens in a new tab)).

Niiden hinta on kitka. Jos jokainen myyjän luoma tili sanoo Possible duplicate found (mahdollinen kaksoiskappale löytyi), joskus se on juuri sitä, mitä haluat, ja joskus ihmiset oppivat napsauttamaan ohi lukematta. Oikeutetut tietueet voivat näyttää samanlaisilta, ja integraatio voi tarvita eri toimintaa kuin ihminen. Ja varoitus on Salesforcen oma: sen hälytys ja mahdollisten kaksoiskappaleiden luettelo eivät välttämättä sulaudu rakentamaasi mukautettuun näkymään, ja kun tallennus on headless, eli integraatio, tietojen lataus tai agentti, näyttöä, jolla sen näyttäisi, ei ole lainkaan. Päätä siis, miten kaksoiskappale tulee esiin kullakin polulla: varoitus ihmiselle, estetty tallennus ja virhe API:lle tai Report-vaihtoehto ja kaksoiskappaletietuejoukot (duplicate record sets) jonkun myöhemmin tarkistettaviksi. Hyvä arkkitehtuuri ei ole mahdollisimman tiukkaa valvontaa; se on oikeaa valvontaa.

Ja tarkista, mitä ovia kaksoiskappalesääntö oikeasti vartioi (Things to Know About Duplicate Rules (opens in a new tab)). API:n ja tietojen tuontityökalujen kautta kukaan ei näe varoitusta: hälyttämään asetettu sääntö yksinkertaisesti estää tallennuksen. Jotkin polut ohittavat säännöt kokonaan: Quick Create, Undelete-painike, manuaalinen yhdistäminen, Lightning Syncin tai Einstein Activity Capturen lisäämät tietueet. Ja samalla hetkellä tallennettuja tietueita ei verrata toisiinsa, vain Salesforcessa jo oleviin tietueisiin. Lataa tiedosto, jossa sama asiakas on kahdesti, niin molemmat rivit voivat päästä läpi. Kaksoiskappalesääntö on hyvä verkko. Se ei ole lukko ovessa.

Koetieto. Kaksoiskappalesäännöt eivät vertaa samalla hetkellä tallennettuja tietueita toisiinsa, vain Salesforcessa jo oleviin tietueisiin. API:n ja tuontityökalujen kautta hälytystä ei tule: kaksoiskappale, jonka sääntö havaitsee, jää yksinkertaisesti tallentamatta. Ja tallennus ja kaikki, mitä se käynnistää, ajetaan yhtenä transaktiona: jos jokin osa epäonnistuu, kaikki perutaan.

Yksi raja. Kaksoiskappalesäännöt pitävät yhden orgin puhtaana. Ne eivät ratkaise yrityksen identiteettiongelmaa. Jos Salesforcessa on Acme Corporation, ERP:ssä ACME-10382 ja laskutuksessa asiakas 77193, kaksoiskappalesääntö ei voi kertoa, että ne ovat sama yritys. Se on perustietojen asia, luku 6.

Viides askelma: automaatio

Jotkin säännöt ovat liian monimutkaisia alemmille askelmille: ne tarvitsevat liittyviä tietueita, toisen järjestelmän, riippuvaisia tietueita, monivaiheisen prosessin. Silloin tarvitaan Flow’ta, Apexia, joskus integraatiologiikkaa. (Ei Workflow Rulesia tai Process Builderia; niiden tuki on päättynyt.) Automaatio on tehokasta ja kalliimpaa: enemmän liikkuvia osia, enemmän testausta, enemmän virheenkäsittelyä, enemmän tapoja, joilla yksi automaatio kompastuu toiseen. Ja koodi tuo omat virheensä. Jos kenttätyyppi voi panna sen täytäntöön, en kirjoita Apexia. Jos vahvistussääntö sanoo sen selvästi, en rakenna flow’ta vain siksi, että Flow on olemassa. Älä ratkaise kenttäongelmaa prosessimoottorilla.

Kaikki tai ei mitään: kun tietueet muuttuvat yhdessä

Tähän asti jokainen askelma suojaa yhtä tallennusta. Mutta tietueet muuttuvat yhdessä: toimitus ja sen rivit, tilaus ja sen rivit, flow, joka päivittää kolmea objektia. Tässä alusta antaa vahvan takuun. Tallennus ja kaikki, mitä se käynnistää, triggerit, flow’t ja niiden kutsumat luokat, ajetaan yhtenä transaktiona: jos jokin osa epäonnistuu, koko kokonaisuus perutaan eikä mitään vahvisteta (Apex Transactions (opens in a new tab)). Puolikasta toimitusta et saa.

Joukkotyö on poikkeus, jonka valitset itse. Tietojen lataus tai Apexin Database-metodi voi sallia osittaisen onnistumisen: hyvät tietueet tallentuvat, huonot palaavat virheineen, ja jonkun on käsiteltävä ne (DML Statements vs. Database Class Methods (opens in a new tab)). Se on usein oikein miljoonan rivin latauksessa, mutta silloin johdonmukaisuus on prosessi: kuka lukee virhetiedoston, ja mitä epäonnistuneille tietueille tapahtuu?

Ja sitten on ajoitus. Kaksi samalla hetkellä tehtyä tallennusta voi kumpikin läpäistä tarkistuksen, jonka kumpikin yksinään reputtaisi. Flow, joka etsii olemassa olevaa tilausta ja sitten luo sellaisen, voi päästää kaksi läpi, ja juuri näimme, että kaksoiskappalesäännöt eivät vertaa samaan aikaan tallennettuja tietueita. Kentän, joka on merkitty Unique, tai External ID:n alusta tarkistaa jokaisessa tallennuksessa, joten vain yksi niistä voittaa. Se on yksi syy lisää työntää yksilöllisyys alas kenttään asti. Lukitukset, kilpailutilanteet ja uudelleenyritykset ovat oma aiheensa; luku 11, Transaktiot, rinnakkaisuus ja luotettavuus, menee niihin syvälle.

Työnnä sääntö alas, kunnes se ei enää kuulu sinne

”Niin alas kuin kohtuudella voi” ei tarkoita ”aina alimmaksi”. Jos kenttä on pakollinen vasta, kun myyntimahdollisuus saavuttaa tietyn vaiheen, sen tekeminen pakolliseksi skeemassa on väärin; sääntö on ehdollinen, joten vahvistussääntö on oikea askelma. Jos kaksoiskappaleen pitäisi varoittaa ihmistä mutta hyväksytyllä integraatiolla on oma täsmäytys- ja sovitusmenettelynsä, suunnittele molempia polkuja varten. Tavoite: alin kerros, joka kuvaa liiketoimintasäännön oikein.

Jokaisella kerroksella on hintansa

Click to enlarge

Tämän kompromissin haluan sinun näkevän. Kenttätyypit ja hallitut arvot ovat yksinkertaisia ja vahvoja, mutta vain siihen, minkä kenttä voi ilmaista. Required ja Unique ovat tylppiä: kun ne ovat päällä, jokaisen kirjoituksen on täytettävä ne. Vahvistussäännöt ilmaisevat rikkaampia ehtoja mutta voivat estää vanhojen tietueiden muokkaamisen ja yllättää käyttöönoton. Kaksoiskappalesäännöt suojaavat tietueiden välillä mutta lisäävät kitkaa käyttäjille ja integraatioille. Automaatio hoitaa mitä tahansa mutta pakottaa sinut omistamaan orkestroinnin, virheet, testit ja suorituskyvyn. Ilmaista kerrosta ei ole. Valitse kunkin säännön kerros tietäen, miten se pettää.

Ennen kuin otat sen käyttöön

Säännön lisääminen olemassa olevaan orgiin on käyttöönottoprojekti, ei valintaruutu. Kuinka moni tietue rikkoo sitä tänään, ja miksi? Ovatko ne oikeasti vääriä? Voimmeko tietää oikean arvon? Onko sääntö totta historiallisesti vai vasta tästä eteenpäin? Mitkä integraatiot, testit ja automaatiot osuvat siihen? Hyvä järjestys: mittaa, siivoa se, minkä voit todistaa vääräksi, rajaa sääntö, lisää harkittu ohitus oikeutetulle historialle, testaa jokainen kirjoituspolku ja pane sitten täytäntöön. Mittaaminen ja siivoaminen ovat omia tieteenalojaan, profilointi, standardointi, valvonta ja tietojen vastuuhenkilöiden työ (stewardship), ja luku 5, Tietojen laatu ja hallinta, käsittelee niitä. Paljon parempi kuin rastittaa ruutu perjantaina ja huomata seuraukset lauantai-iltana.

Kokeen jälkeen: mitä tekoäly muuttaa. Agentti voi luoda tietueita nopeammin kuin kukaan ihminen, ja huonoja tietueita yhtä nopeasti. ”Käyttäjät tietävät, ettei niin tehdä” ei ole suoja, kun käyttäjä on agentti. Sijoita tärkeät säännöt tietokerrokseen, jossa jokainen kirjoittaja kohtaa ne, jotta agentin ei tarvitse muistaa yrityksen kirjoittamattomia sääntöjä.

Steve Trucking: suojaa toimitus

Otetaan toimitus. Sen tila tulee yhdestä sanastosta: valintaluettelo, rajoitettu. Vähittäiskauppakumppanin tilausviitteen on oltava yksilöllinen kumppania kohden, joten se on External ID, merkitty yksilölliseksi, ja sitä käytetään kuormaluettelon upsertiin. Todellinen toimitusaika on pakollinen, kun tila on Delivered: vahvistussääntö, rajattu siihen muutokseen. Asennuspysähdystä ei voi sulkea ennen kuin sen tarkistuslista on valmis ja sen vaaditut valokuvat on otettu (astianpesukoneelle vesiputki, poistoputki ja vaaitus): vahvistussääntö, tai automaatio, jos sen on tarkistettava alustan ulkopuolelle tallennetut valokuvat. Sama tilaus, joka saapuu kahdesti uudelleen lähetetystä kuormaluettelosta, jää kiinni External ID:hen; kaksi eri tilausta, jotka näyttävät samanlaisilta, ovat täsmäyskysymys.

Huomaa, etten sanonut ”laita ne kaikki flow’hun”. Jokainen sääntö on omalla askelmallaan. Kysy jokaisen säännön kohdalla: mikä on alin kerros, joka panee tämän täytäntöön oikein jokaisella merkityksellisellä kirjoituspolulla?

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

• Mille askelmalle kukin sääntö kuuluu: kenttätyyppi, hallittu sanasto, pakollinen tai yksilöllinen, vahvistussääntö, kaksoiskappalesääntö vai automaatio.
• Mitkä kirjoituspolut on suojattava: käyttöliittymä, portaali, mobiili, integraatiot, joukkolataukset, API:t, automaatio ja agentit.
• Koskeeko uusi sääntö historiallisia tietueita, vai rajataanko se uusiin ja muuttuneisiin tietoihin ohituksella menneisyydelle.
• Voidaanko olemassa olevat huonot tiedot korjata näytön perusteella sen sijaan, että ne kirjoitetaan uudelleen läpäisemään sääntö.
• Kuinka paljon kitkaa, monimutkaisuutta ja ylläpitoa sääntö on arvoinen.

Puhtaat tiedot eivät synny pyytämällä ihmisiä syöttämään hyviä tietoja. Ne syntyvät arkkitehtuurista, joka tekee oikeasta asiasta helpon, väärästä vaikean ja tärkeistä säännöistä vaikeasti ohitettavia. Seuraavaksi kokoamme luvun yhteen Steve Truckingin siivun avulla.

Lue lisää

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) ja Roll-Up Summary Field (opens in a new tab), englanniksi, tarkistettu 2026-10-13.
• Salesforce Help, Picklist Limitations (opens in a new tab), englanniksi, tarkistettu 2026-10-02.
• Salesforce Help, Validation Rule Considerations (opens in a new tab), englanniksi, tarkistettu 2026-10-02.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab), englanniksi, tarkistettu 2026-10-13: rajat, polut, joilla säännöt eivät toimi, API- ja tuontitallennukset estetään ilman hälytystä, samanaikaisia tallennuksia ei verrata.
• Apex Developer Guide, Apex Transactions (opens in a new tab) ja DML Statements vs. Database Class Methods (opens in a new tab), englanniksi, tarkistettu 2026-10-13: yksi transaktio perutaan kokonaisuutena; Database-metodit voivat sallia osittaisen onnistumisen.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab), englanniksi, tarkistettu 2026-10-02.