Salesforcen tietoarkkitehtuuri

🌐 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

Luvun 3 opiskeluopas Data Architect -kurssilla. Lue ensin kymmenen moduulia; tämä sivu auttaa sinua tarkistamaan, mitä jäi mieleen.

Tästä opiskeluoppaasta. Se on koottu vain tämän kurssin omasta sisällöstä ja Salesforcen julkaiseman kokeen oppaan tavoiteluettelosta. Se ei koskaan perustu oikeisiin koekysymyksiin, eikä se väitä tietävänsä, mitä kokeessa on. Jos olet suorittanut kokeen, älä lähetä minulle sen kysymyksiä: sertifiointisopimus kieltää niiden jakamisen, ja vastausten ulkoa opettelu on joka tapauksessa väärä tapa tulla arkkitehdiksi.

Tässä luvussa malli kohtaa alustan, ja se kantaa suuren osan kokeesta. Se ruokkii molempia suurimpia osioita, Data Modeling and Database Design ja Salesforce Data Management, joiden kummankin osuus kokeesta on neljännes. Alustan luvut muuttuvat: tarkistuslista antaa ne, joihin moduulit viittaavat, ja päivämäärän, jolloin ne tarkistettiin. Opettele, mihin kukin raja on olemassa, ja tarkista nykyinen luku ennen kuin luotat siihen.

Koetta varten

Rastita kohdat sitä mukaa kuin etenet. Jokainen linkittää kohtaan, jossa asia opetetaan.

DM-1: tietomallin suunnittelu alustalle

• Tiedän, että Salesforce on metatietoihin perustuva (metadata-driven) monivuokralainen (multitenant) alusta: objekti on metatietoa, ei uusi taulu, ja jokainen objekti saa API:nsa heti, kun se on olemassa. (Metatiedot ovat pohjapiirustus, API tuli objektin mukana)
• Tiedän, että governor limits (alustan rajat) ovat olemassa, jotta yksi vuokralainen ei voi ottaa jaettuja resursseja haltuunsa. (Hissiä ei voi ottaa omaksi)
• Osaan lukea vakiotietomalleja: liidin (Lead) muuntaminen tiliksi (Account), yhteyshenkilöksi (Contact) ja myyntimahdollisuudeksi (Opportunity); myyntimahdollisuuden tuote (Opportunity Product) osoittaa hinnaston merkintään (Price Book Entry), joka osoittaa Product2-objektiin; ja palvelupuolella tapaus (Case), omaisuuserä (Asset) ja Entitlement. (Myyntimalli, Palvelumalli)
• Tiedän, mitä New Custom Object -näkymä päättää: Text- tai Auto Number -tyyppisen tietuenimen; Object Classificationin (kun jakaminen, Bulk API ja Streaming API ovat päällä, kyseessä on Enterprise Application -objekti, kun ne ovat pois päältä, Light Application -objekti); ja Allow Search -asetuksen, joka on oletuksena pois päältä. (New Custom Object -näkymä)
• Osaan lukea API-nimen: vakio-objekteilla ja -kentillä ei ole etu- eikä jälkiliitettä; mukautetut objektit ja kentät päättyvät __c; hallittu paketti lisää nimiavaruutensa etuliitteen (abc__); ja kenttä, jonka lisäät paketin objektiin, saa __c-päätteen mutta ei koskaan toimittajan etuliitettä. (Etuliitteet ja jälkiliitteet)
• Osaan soveltaa vakio-objektiin puhtaan sopivuuden testiä, ja tiedän, milloin merkitys tai paino osoittaa kohti mukautettua objektia. (Puhtaan sopivuuden testi)
• Tiedän, mihin omaisuuserä (Asset) ja henkilötilit on tarkoitettu, että henkilötili vie noin kaksi kertaa yritystilin tallennustilan ja että kun henkilötilit on otettu käyttöön, niitä ei voi poistaa käytöstä. (Omaisuuserä on hyvä esimerkki, Henkilötilit, Milloin henkilö on tili?)
• Valitsen kenttätyypin tarvitsemani käyttäytymisen mukaan (kaluston numero ei ole Number), ja tiedän, että päivämäärä ja aika tallennetaan GMT-aikana ja näytetään kunkin lukijan aikavyöhykkeellä, joten niitä verrataan väleillä, ei yhtäsuuruudella. (Numero ei aina ole luku, Date, Date/Time ja Time)
• Tiedän, että tekstiä on kahta lajia: enintään 255 merkkiä tietueella (indeksoitavissa, käytettävissä yksilöllisenä tai External ID:nä) ja sitä pidempi Long- tai Rich-teksti, jolla ei ole indeksiä, WHERE-suodatusta eikä kaavoja. (Tekstiperhe)
• Tiedän, milloin käyttää Auto Number -tyyppistä Name-kenttää, ja ettei se ole tietueen ID. (Tarvitseeko ihmisen tunnistaa se?)
• Tiedän, miten External ID antaa integraation tehdä upsertin ja ladata lapsitietueet niiden vanhemman External ID:n avulla. (External ID:t)
• Tiedän, milloin arvo pitäisi johtaa kaavalla ja milloin se on historiallinen tosiasia, joka täytyy tallentaa. (Tallennettu vai johdettu?)
• Tiedän eron loogisen liitosobjektin (mallinnuksen idea: objekti, joka yhdistää kaksi muuta monen suhde moneen -suhteessa ja jolla on omia attribuutteja) ja Salesforcen liitosobjektin (Salesforce Junction Object) (mukautettu objekti, jolla on kaksi master-detail-suhdetta) välillä, ja tiedän, että Salesforce tarkoittaa jälkimmäistä. (Kaksi vanhempaa leveä)
• Tunnen hierarkkisen suhteen: erityinen lookup-suhde vain User-objektissa, kuten vakiokenttä Manager, joka ei voi kiertää takaisin samaan käyttäjään suoraan eikä epäsuorasti, eikä se ole roolihierarkia. (Hierarkkinen)
• Tiedän eron lookup-suhteen ja master-detail-suhteen välillä: omistajuus, jakaminen, pakollinen vanhempi, ketjupoisto, koontikentät. (Lookup, Master-detail)
• Tiedän, ettei master-detail-suhdetta voi luoda objektiin, jossa on jo tietoja (luo lookup, täytä se, muunna), että sen voi muuttaa takaisin lookupiksi vain, jos masterissa ei ole koontikenttiä, ja että lapsen siirtäminen vaatii Allow reparenting -asetuksen. (Voiko lapsi vaihtaa vanhempaa?)
• Tunnen alustan muodon master-detail-suhteille: enintään kolme mukautettua detail-tasoa syvä (lookup voi katkaista ketjun missä kohdassa tahansa) ja kaksi master-detail-vanhempaa leveä. Salesforcen liitosobjektissa ensin luotu master-detail on ensisijainen (omistaja, ulkoasu, divisioona), toinen on toissijainen, ja pääsy vaatii molemmat vanhemmat: rajoittavin voittaa. (Kolme tasoa syvä, Kaksi vanhempaa leveä)
• Tiedän lookup-suhteen kolme vaihtoehtoa, kun vanhempi poistetaan: tyhjennä kenttä (oletus), estä poisto tai ketjupoisto, joka on pois päältä, kunnes Salesforce ottaa sen käyttöön, ja ohittaa jakamisen. (Lookup)
• Tiedän, että itseensä viittaavan suhteen täytyy olla lookup, ja tunnen kaksi sisäänrakennettua: tilin Parent Account ja tapauksen Parent Case. (Itseensä viittaavat suhteet)
• Tiedän, että koontikenttien uudelleenlaskenta voi viedä aikaa, ettei koontikenttä voi käyttää kaavaa, jossa on NOW(), TODAY() tai objektien välinen viittaus, ja ettei master-detail-suhdetta pidä valita vain koontikentän takia: vaihtoehto on tallennettu kenttä, jota flow tai trigger pitää ajan tasalla. (Koontikentät ovat hyödyllisiä, mutta eivät ilmaisia)
• Tiedän moduulin mainitsemat suhderajat: kaksi master-detail-suhdetta objektia kohden; oletuksena 40 suhdekenttää (enintään 50); oletuksena 25 koontikenttää (enintään 40). (Suhteillakin on rajansa)

DM-2: malli, joka kunnioittaa jakamista ja skaalautuu

• Tiedän, ettei master-detail-lapsella ole omaa omistajaa eikä jakotaulua: pääsy seuraa masteria. (Omistajuus tulee kyytiin)
• Tunnen parent-child skew’n: Salesforcen ohjeen mukaan yhdellä vanhemmalla saa olla enintään noin 10 000 lasta. (10 000 lapsen kysymys)
• Tunnen ownership skew’n (yksi käyttäjä omistaa yli 10 000 objektin tietuetta) ja ohjeen: hajauta omistajuus tai pidä käyttäjä poissa roolihierarkiasta tai yksin sen huipulla sekä poissa julkisista ryhmistä, joita jakamissäännöt käyttävät. (Omistajuudesta voi tulla mittakaavaongelma)
• Tunnen jakotaulun: mukautetun objektin jako-objekti on Object__Share; detail-objektilla sitä ei ole, vaan sen pääsy tulee masterilta; ja omistajan vaihto poistaa manuaaliset jaot mutta säilyttää Apex-jakamisen, jolla on oma syynsä. (Jakotaulu)
• Osaan päättää, kuka omistaa integraatioiden ja agenttien luomat tietueet sen perusteella, ohjaako omistajuus jakamista. (Kuka omistaa tietueet, jotka järjestelmät luovat?)

DM-4: big objectit verrattuna vakio- ja mukautettuihin objekteihin

• Tunnen tietojen kolme kotia: coressa (sObjectit, päivittäisessä käytössä), viitattu (toinen järjestelmä on totuuden lähde: Salesforce Connectin ulkoiset objektit, __x, tai mukautetut kutsut) ja arkistoitu (coressa big objecteissa, __b, tai coren ulkopuolella tietovarastossa). (Coressa ja coren ulkopuolella)
• Tiedän, että ulkoiset objektit tekevät kutsun (callout) aina, kun niihin kosketaan, joten viive ja lähdejärjestelmän saatavuus ovat tärkeitä. (Viitattu)
• Tunnen big objectit: valtavat määrät, kysely indeksin kautta tarkalla osumalla tai välillä, ei vakiokäyttöliittymää eikä raportointia, vain objekti- ja kenttäoikeudet, ei automaatiota. (Arkistoitu)
• Tiedän, että useimmat tietueet lasketaan noin 2 kt:ksi tietojen tallennustilaa kenttien määrästä riippumatta ja että tiedostot mitataan erikseen tiedostojen tallennustilassa. (Kaksi saraketta vai kaksisataa, Tiedostot ja liitteet)

SDM-1: lisenssit ja objektit, joita ihmiset voivat käyttää

• Tunnen kolme sisäistä lisenssiä, Sales Cloud, Service Cloud ja Platform, ja tiedän, mitä kukin voi käyttää. (Kolme sisäistä lisenssiä)
• Tiedän, että lisenssit ovat osa tietomallia: Salesforce Platform -käyttäjät eivät saa liidejä, kampanjoita, myyntimahdollisuuksia eivätkä ennusteita, eivätkä Customer Community -käyttäjät voi käyttää myyntimahdollisuuksia. (Ja nyt monimutkaistan kaiken: lisensointi)
• Tunnen ulkoisten lisenssien tasot: Customer Community, Customer Community Plus (raportit, koontinäytöt, vakiojakaminen), Partner Community (myyntiobjektit); ja tiedän, ettei Partner Communitya voi käyttää henkilötilien kanssa. (Stadion)
• Tunnen jäsenpohjaisen (member-based) ja kirjautumispohjaisen (login-based) lisensoinnin eron ja tiedän, mille käyttäjäjoukolle kumpikin sopii. (Maksutapa muuttaa suunnitelmaa)
• Tiedän, että jotkin Platform-lisenssit rajaavat käyttäjät yhteen sovellukseen, jossa on enintään kymmenen mukautettua objektia, ja tunnen tietuetyyppimallin, jolla rajan sisällä voi työskennellä. (Kun lisenssi muovaa mallia)
• Tiedän, että Salesforce Integration -lisenssi on järjestelmien välisille, pelkkää API:a käyttäville käyttäjille. (Ihmiset eivät ole enää ainoita käyttäjiä)
• Tiedän, että SLA-raportointi vaatii entitlementit ja milestonet, jotka vaativat Service-lisenssit. (Ja nyt monimutkaistan kaiken: lisensointi)

SDM-2: tietojen pitäminen johdonmukaisina

• Osaan sijoittaa säännön oikealle askelmalle johdonmukaisuuden tikkailla: kenttätyyppi ja sanasto, pakollinen ja yksilöllinen, vahvistussäännöt, kaksoiskappalesäännöt, automaatio. (Tietojen pitäminen johdonmukaisina)
• Tiedän, että rajoitettu valintaluettelo hylkää arvot, joita ei ole listalla, myös API:n kautta, ja että yleinen arvojoukko jakaa yhden listan useiden kenttien kesken (enintään 1 000 arvoa). (Ensimmäinen askelma)
• Tiedän, että sivun asettelun pakollisuus suojaa vain kyseistä näkymää, ei tietoja, ja että vahvistussäännöt suoritetaan jokaisessa tallennuksessa. (Käyttöliittymän vahvistus ei ole tietojen vahvistusta, Kolmas askelma)
• Osaan rajata vahvistussäännön ISNEW()- ja ISCHANGED()-funktioilla, mukautetulla käyttöoikeudella tai käyttöönottopäivällä, ja tiedän, mitkä tallennukset (myös ne, joita en hallitse, kuten eräajona tehty omistajan vaihto tai koontikenttä) kukin valinta yhä tarkistaa. (Vanhan tietueen ongelma)
• Tunnen vastaavuussäännöt ja kaksoiskappalesäännöt, moduulin mainitsemat rajat (viisi aktiivista kaksoiskappalesääntöä objektia kohden, kussakin kolme vastaavuussääntöä) ja tiedän, etteivät ne ratkaise tietueiden tunnistamista järjestelmien välillä. (Neljäs askelma: kaksoiskappalesäännöt)
• Tiedän, etteivät kaksoiskappalesäännöt vertaa samalla hetkellä tallennettuja tietueita, että API- ja tuontitallennukset estetään ilman hälytystä ja että tallennus ja kaikki, mitä se käynnistää, perutaan yhtenä transaktiona. (Neljäs askelma, Kaikki tai ei mitään)
• Tiedän, että Workflow Rules ja Process Builder ovat tuen ulkopuolella; automaatio tarkoittaa Flow’ta tai Apexia. (Viides askelma: automaatio)

Kokeen jälkeen

Koe on lattia, ei katto. Nämä ovat tämän luvun tapoja, joita arkkitehti tarvitsee, kysyttiinpä niistä koskaan tai ei.

• Alustalla on muoto. Suunnittele sille alustalle, jolla olet, älä yleiselle tietokannalle.
• Katso emoalukseen. Katso, miten Salesforce mallintaa käsitteen, ennen kuin keksit omasi.
• Jokainen objekti on sitoumus: tallennustila, rajat, jakamismalli, lisenssit ja riippuvuudet.
• Kysy, missä tiedot asuvat, ennen kuin valitset objektin: coressa, viitattuna vai arkistoituna.
• Lue mikä tahansa API-nimi, niin tiedät, kuka sen teki, ja mitä voit muuttaa.
• Jos et arkistoi tänään, aiotko koskaan arkistoida?
• Tee big objecteista prototyyppi ennen kuin ehdotat niitä.
• Eri liiketoimintanimet eivät automaattisesti tarkoita eri objekteja.
• Kysy, mitkä identiteetit tarvitsevat tietoja: ihmiset, asiakkaat, kumppanit, integraatiot ja agentit.
• Jokainen kenttä saa kuvauksen, ja luokittelun siellä, missä sillä on väliä.
• Kuvaa ensin suhteen käyttäytyminen; konfiguraatio toteuttaa sen. Älä vääristä mallia saadaksesi jonkin ominaisuuden.
• Poistokysymys: mitä lapsille pitäisi tapahtua, jos joku poistaa vanhemman?
• Valitse, mikä linkki katkaisee ketjun: tee lookup sinne, missä lapsella todella on oma elämänsä.
• Omistajuus ensisijaiselta, pääsy molemmilta: rajoittavin voittaa.
• Erota passiivinen poistuneesta, ja tee säilytyksestä liiketoimintasääntö.
• Työnnä sääntö niin alas kuin se oikeasti kuuluu, ja anna oikeutetulle historialle ohitus sen sijaan, että kirjoittaisit sen uudelleen.
• Kaavio ei ole arkkitehtuuri. Pysty jäljittämään jokainen rakenne liiketoiminnan syyhyn.

Tärkeät termit

Termi	Yhdellä rivillä
Metatietoihin perustuva (metadata-driven)	Objektit ja kentät ovat määrityksiä, joita alusta lukee ajon aikana, eivät uusia fyysisiä tauluja
Monivuokralaisuus (multitenancy)	Monet orgit jakavat infrastruktuurin, kukin eristettynä, kuin asunnot samassa talossa
Governor limits (alustan rajat)	Rajat, jotka estävät yhtä vuokralaista valtaamasta jaettuja resursseja
Ulkoinen objekti	Tiedot, jotka näytetään Salesforcessa Salesforce Connectin kautta ja haetaan lähteestä joka kosketuksella
Big object	Tallennustila hyvin suurille, harvoin käytetyille tiedoille, kysely indeksin kautta
Henkilötili	Yksityishenkilö esitettynä tilinä kuluttajaliiketoiminnan (B2C) malleissa
Puhdas sopivuus	Liiketoiminnan käsite, joka vastaa vakio-objektin aiottua käyttötarkoitusta
External ID	Kenttä, jossa on toisen järjestelmän tunniste, käytetään upsertissa ja täsmäytyksessä
Upsert	Päivitä tietue, jos se on olemassa, luo se, jos ei ole
Lookup	Suhde, jossa lapsi säilyttää oman omistajansa ja elämänsä
Master-detail	Suhde, jossa lapsi kuuluu vanhemmalle: peritty omistaja ja jakaminen, ketjupoisto, koontikentät
Looginen liitosobjekti	Mallinnuksen idea: objekti, joka yhdistää kaksi muuta monen suhde moneen -suhteessa ja jolla on omat attribuuttinsa, toteutettiinpa se miten tahansa
Salesforcen liitosobjekti (Salesforce Junction Object)	Se, mitä Salesforce tarkoittaa ”liitosobjektilla”: mukautettu objekti, jolla on kaksi master-detail-suhdetta
Ensisijainen ja toissijainen master	Salesforcen liitosobjektin ensin luotu master-detail (omistaja, ulkoasu, divisioona) ja toinen (raporttien laajuus; muuttuu ensisijaiseksi, jos ensimmäinen poistetaan)
Hierarkkinen suhde	Erityinen lookup vain User-objektissa, kuten Manager, joka ei voi kiertää takaisin samaan käyttäjään
Nimiavaruuden etuliite	Toimittajan etuliite hallitun paketin objekteissa ja kentissä, kuten abc__Inspection__c
Jakotaulu	Jako-objekti (AccountShare, Truck__Share), jossa on suurin osa tietueen jakamisesta, yksi rivi käyttäjää tai ryhmää kohden syineen
Koontikenttä (roll-up summary)	Masterin kenttä, joka laskee detail-tietueiden määrän, summan, pienimmän tai suurimman arvon
Data skew	Liian monta tietuetta yhden vanhemman tai yhden omistajan alla, mikä aiheuttaa lukituksia ja pitkiä jakamisen uudelleenlaskentoja
Jäsenpohjainen / kirjautumispohjainen	Maksu ulkoista käyttäjää kohden tai kirjautumista kohden kuukausittain
Johdonmukaisuuden tikkaat	Kerrokset, jotka valvovat tietosääntöjä, kenttätyypistä automaatioon
Rajoitettu valintaluettelo	Valintaluettelo, joka hylkää kaikki arvot, joita sen listalla ei ole, lähteestä riippumatta
Tietojen luokittelu	Kentän metatiedot omistajalle, käytölle, arkaluonteisuudelle ja vaatimustenmukaisuusluokalle

Testaa itsesi

Lyhyitä skenaarioita kurssin tyyliin. Päätä vastauksesi ennen kuin avaat sen.

1. Käyttäjien täytyy nähdä tilaustiedot, jotka ERP omistaa ja joita se päivittää koko päivän. He eivät muokkaa niitä Salesforcessa. Kopioidaanko ne vai ei?

Viittaa niihin: Salesforce Connectin ulkoiset objektit pitävät ERP:n totuuden lähteenä ilman synkronoitavaa kopiota. Hyväksy, että jokainen näkymä tekee kutsun, joten viive ja ERP:n saatavuus ovat tärkeitä, ja että ratkaisu sopii paremmin lukemiseen kuin raskaaseen muokkaamiseen tai raportointiin. Lue uudelleen Viitattu.

2. Liiketoiminta haluaa seurata jakelijoita, toimittajia ja vähittäiskauppakumppaneita. Kolme mukautettua objektia?

Ei. Ne ovat kaikki yrityksiä, joten tili (Account) sopii puhtaasti; eri nimet ovat rooleja, joita kantaa tyyppi, tietuetyyppi tai suhde. Lue uudelleen Puhtaan sopivuuden testi.

3. Suunnitelma käyttää myyntimahdollisuutta (Opportunity), mutta useimmilla tietoja tarvitsevilla on Salesforce Platform- tai Customer Community -lisenssi. Mitä nyt?

Nämä lisenssit eivät voi käyttää myyntimahdollisuuksia, joten lisenssi on arkkitehtuurinen rajoite: osta eri lisenssit, siirrä käyttökokemus muualle tai suunnittele uudelleen, yleensä kohti mukautettua objektia. Lue uudelleen Ja nyt monimutkaistan kaiken: lisensointi.

4. ERP lähettää öisin päivityksiä tileihin. Miten integraation pitäisi löytää oikea tietue ilman, että se kyselee Salesforcen ID:itä?

Tallenna ERP:n asiakasnumero External ID -kenttään ja tee upsert sen perusteella: päivitä, jos löytyy, luo, jos ei. Myös lapsitietueet voivat osoittaa vanhempaansa sen External ID:n avulla. Lue uudelleen External ID:t.

5. Toimitusrivi (Delivery Item) ei voi olla olemassa ilman toimitustaan, ei koskaan siirry eikä tarvitse omaa omistajaa. Toimitus (Delivery) on olemassa ennen kuin se reititetään, ja se voi siirtyä toiselle reitille. Mikä suhde kummallekin?

Toimitusrivistä toimitukseen: master-detail (se kuuluu vanhemmalle koko elämänsä, perii pääsyn ja poistuu ketjupoistossa). Toimituksesta reittiin: lookup (oma elämä, aluksi valinnainen, siirrettävissä, eikä reitin poistaminen saa koskaan poistaa toimituksia). Lue uudelleen Aloita liiketoiminnan suhteesta.

6. Integraatio luo 3 300 toimitusta päivässä, ja ne kaikki omistaa integraatiokäyttäjä, jolla on rooli keskellä hierarkiaa. Mikä on riski, ja mikä korjaus?

Ownership skew: kun tietueita on yli 10 000, käyttäjän siirtäminen tai sen ryhmien muuttaminen käynnistää pitkiä jakamisen uudelleenlaskentoja. Hajauta omistajuus, jos sillä on merkitystä pääsylle; muuten pidä integraatiokäyttäjä poissa roolihierarkiasta tai yksin roolissa huipulla sekä poissa ryhmistä, joita jakamissäännöt käyttävät. Lue uudelleen Omistajuudesta voi tulla mittakaavaongelma.

7. Lisäät vahvistussäännön, ja 20 000 vanhaa tietuetta rikkoo sitä. Käyttäjä muokkaa yhden puhelinnumeroa, ja tallennus epäonnistuu. Mitä säännön olisi pitänyt tehdä?

Kertoa, milloin sääntöä valvotaan, eikä vain sitä, minkä täytyy olla totta: rajaa se ISNEW()- tai ISCHANGED()-funktiolla asiaankuuluviin kenttiin ja anna sääntöä vanhemmille tietueille harkittu ohitus sen sijaan, että kirjoittaisit niiden historian uudelleen. Lue uudelleen Vanhan tietueen ongelma.

8. Liiketoiminta haluaa jokaisen toimituskuvan ”Salesforceen”: neljästä viiteen miljoonaa vuodessa, ja määrä kasvaa 30 prosenttia. Mitä ehdotat?

Erota pääsy tallennuksesta. Pidä tiedostot sellaiselle volyymille rakennetussa tallennustilassa core-orgin ulkopuolella ja säilytä Salesforcessa viite, lukumäärä tai hakemistotietue, jotta käyttäjät löytävät ja näkevät ne. Lue uudelleen Valokuvat.

9. Tiimin osoituksella (Crew Assignment) on master-detail-suhteet tiimiin (Crew, luotu ensin) ja kuorma-autoon (Truck). Ajojärjestelijä näkee tiimin mutta ei kuorma-autoa. Näkeekö hän tiimin osoituksen?

Ei. Tiimi on ensisijainen, joten se antaa osoitukselle omistajan ja ulkoasun, mutta pääsy vaatii molemmat vanhemmat: ajojärjestelijä tarvitsee pääsyn tiimiin ja kuorma-autoon sillä tasolla, jota kunkin master-detail-kentän Sharing Setting edellyttää. Rajoittavin voittaa. Lue uudelleen Kaksi vanhempaa leveä.

10. Kumppani lähettää kuormaluettelotiedoston uudelleen, ja sama asiakas esiintyy siinä kahdesti. Tilillä on kaksoiskappalesääntö, joka on asetettu estämään. Oletko turvassa?

Et pelkän kaksoiskappalesäännön varassa. Samalla hetkellä tallennettuja tietueita ei verrata toisiinsa, vain Salesforcessa jo oleviin tietueisiin, joten molemmat rivit voivat päästä läpi. Työnnä yksilöllisyys alas kenttään: yksilöllinen External ID, jonka alusta tarkistaa jokaisessa tallennuksessa, joten vain yksi voittaa. Lue uudelleen Neljäs askelma: kaksoiskappalesäännöt ja Kaikki tai ei mitään.

Lue lisää

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-09-25): virallinen tavoiteluettelo painotuksineen. Tarkista aina nykyinen versio ennen kuin varaat kokeen.
• Jokaisen moduulin oma Lue lisää -osio luettelee Salesforcen dokumentaation, johon sen alustatiedot perustuvat, sekä päivämäärän, jolloin se tarkistettiin.