Suunnittele Salesforcen fyysinen malli

🌐 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 10/10 luvussa Salesforcen tietoarkkitehtuuri, Data Architect -kurssin luku 3. Jokainen moduuli on itsenäinen. Edellinen: Tietojen pitäminen johdonmukaisina · Seuraava: luvun opiskeluopas ja sen jälkeen seuraava luku, Yrityksen tietojen ymmärtäminen

Kysymys, johon tämä moduuli vastaa: Miten muutamme loogisen mallimme Salesforce-arkkitehtuuriksi?

Tämä luku on ollut yksi pitkä perustelu sille, että alustalla on muoto: vakio-objektit ja mukautetut objektit, paikat, joissa tiedot voivat asua, kenttätyypit, suhteet, omistajuus, lisenssit, johdonmukaisuussäännöt, tallennustila ja mittakaava. Jokainen niistä voi muuttaa sitä, miten luvun 2 looginen malli rakennetaan. Kootaan nyt kaikki yhteen yhdessä Steve Truckingin siivussa.

Yksi siivu, ei koko yritystä. Näen arkkitehtien usein yrittävän ratkaista koko yrityksen yhdellä kaaviolla. Haluan jotain, mistä voimme oikeasti päätellä: vähittäiskauppakumppani (Retail Partner) lähettää kuormaluettelon (manifest), Steve Trucking toimittaa sen, mitä siinä on, ja säilytämme jokaisesta toimituksesta sen, mitä tarvitsemme. Sitten teemme fyysiset päätökset yksi kerrallaan. Koko suunnitelma on osan 1 tarkistuspiste.

Aloita siitä, mitä jo tiedämme

Luku 2 teki käsitteellisen työn: vähittäiskauppakumppani, vastaanottaja (Recipient), kuormaluettelo, toimitus (Delivery), toimitusrivi (Delivery Item), pysähdyksen laji, tiimi (Crew), kuorma-auto (Truck), jakelukeskus (DC) ja valokuvat. Nimesimme suhteet ja kysyimme, mitä ne tarkoittavat. En toista sitä. Kysymys on nyt, miten nuo käsitteet elävät Salesforcessa. Yksi tieto taustakuvauksesta on heti tärkeä: Steve Truckingilla on jo käytössä Field Service käynteihin, tiimeihin ja mobiilisovellukseen.

Vähittäiskauppakumppani: älä keksi tiliä uudelleen

Vähittäiskauppakumppani on yritys, jolle Steve Trucking tekee töitä. Salesforcessa on jo yrityksiä varten suunniteltu objekti: tili (Account). Puhdas sopivuus. Ei siis Retail_Partner__c-objektia vain siksi, että liiketoiminta sanoo ”kumppani”. Se on tili, jolla on Retail Partner -tietuetyyppi erottamaan sen muista organisaatioista, ja sen mukana tulevat sopimukset, tapaukset, yhteyshenkilöt (Contact) jakelukeskusten esihenkilöille ja portaalipääsy noille yhteyshenkilöille. Helppo päätös. Kaikki eivät ole.

Kumppanin tilausnumero ei ole meidän tunnisteemme

Jokainen vähittäiskauppakumppani lähettää omat viitteensä. Yhden kumppanin tilaus näyttää tältä: 8843119, toisen tältä: A-984732. Noilla numeroilla on merkitystä, mutta keiden ne ovat? Kumppanin. Salesforcella on oma tietueen ID:nsä, ja kumppanilla on viite, jota se käyttää puhuessaan meille. Molemmat voivat olla olemassa; se on luvun 2 ”yksi asia, useita tunnisteita”.

Kumppanin viitteestä tulee siis External ID, jonka avulla integraatio täsmäyttää päivitykset. Ja koska kaksi kumppania voi käyttää samaa numeroa, yksilöllinen tunniste on kumppani ja viite yhdessä, ei pelkkä viite. Älä tee kumppanin numerosta toimituksen yleistä tunnistetta siksi, että se saapui ensin, äläkä pakota integraatiota hakemaan tekstikentästä joka kerta, kun sen pitää löytää tietue.

Toimitus: katso emoalukseen

Tässä kohdassa houkuttaa luoda Delivery__c. Liiketoiminta sanoi ”toimitus”, joten tarvitsemme Delivery-objektin. Juuri sitä en halua sinun tekevän ensimmäiseksi. Katso emoalukseen, kuten teimme moduulissa 2. Mitä Salesforcessa on jo valmiina työlle, joka tehdään jossakin paikassa ja jolla on elinkaari, rivit, aikataulutus ja tiimi kentällä? Field Servicen työtilaus (Work Order): Salesforce kuvaa sen asiakkaalle tehtäväksi kenttähuoltotyöksi (WorkOrder (opens in a new tab)). Aikataulutettu käynti ja sen aikaikkuna on huoltokäynti (Service Appointment), ja juuri sen ajojärjestely aikatauluttaa ja tiimin sovellus näyttää.

Siis toimitus → työtilaus. Ei siksi, että sanat täsmäävät; ne eivät täsmää. Vaan siksi, että käyttäytyminen vastaa alustan ominaisuutta, josta jo maksamme ja jota aiomme käyttää. Vakio-objektin ei tarvitse puhua liiketoiminnan sanastoa. Sen täytyy esittää käsite oikein.

Click to enlarge

Vaihe 1/4: emoalus. Jokaisessa kortissa on liiketoiminnan käsite ja sen alla Salesforce-objekti.

Mutta vakio-objekteilla on matkatavaransa

Toinen puoli: työtilaus ei ole ilmainen. Sen mukana tulevat Field Servicen lisensointi, omat suhteet, suojauskäyttäytyminen, pakolliset kentät, automaatio ja elinkaari, ja alustan muut osat odottavat sen käyttäytyvän tietyllä tavalla. Valitsemme sen, koska sopivuus on puhdas ja käytämme sitä, mitä sen ympärille on rakennettu. Jos Steve Trucking ei haluaisi Field Servicestä mitään ja malli taistelisi prosessia vastaan joka käänteessä, harkitsisin uudelleen. Arkkitehtuuri on sopivuus, ei nimilappu.

Toimitusrivit: seuraa mallia

Kun toimitus on työtilaus, katso mallin loppuosa ennen kuin keksit mitään. Työtilauksen rivi (Work Order Line Item) on työtilauksen alitehtävä (WorkOrderLineItem (opens in a new tab)): jääkaappi, asennus, vanhan laitteen poisvienti. Siis toimitusrivi → työtilauksen rivi. Huomaa, että ensimmäinen päätös muovasi toista. Emme valitse objektia jokaiselle entiteetille erikseen. Ota malli käyttöön ja ymmärrä sen loppuosa ennen kuin rakennat sen ympärille omia rakenteita.

Millainen pysähdys tämä on?

Steve Truckingissa pysähdys on pelkkä toimitus, toimitus ja asennus tai toimitus ja poisvienti, ja jokaisella lajilla on oma kestonsa, tiimin taitonsa ja asennuksen tarkistuslistansa. Luvussa 2 päätimme, että se on entiteetti, ei nimilappu. Field Servicessä sellainen on jo: työn tyyppi (Work Type), malli työn tyypille, jonka voi soveltaa työtilauksiin ja niiden riveihin (WorkType (opens in a new tab)). Siis pysähdyksen laji → työn tyyppi. Taaskaan ei siksi, että jotain nimeltä Work Type on olemassa, vaan siksi, että käsite ja käyttäytyminen osuvat yhteen.

Click to enlarge

Vaihe 2/4: seuraa mallia. Rivit ja työn tyyppi tulevat työtilauksen mukana.

Kuormaluettelo: nyt haluan mukautetun objektin

Onko olemassa vakio-objektia ”kumppanin tiistain listalle Phoenixin jakelukeskuksessa”? Ei oikeastaan, enkä pakota sitä johonkin asiaan liittymättömään objektiin vain voidakseni sanoa, että pysyimme vakio-objekteissa. Kuormaluettelo → Manifest__c. Se on vastaanoton yksikkö: mistä se tuli (tiedosto, API-erä), milloin, sen tila ja summat, ja kun kumppani lähettää sen samana päivänä uudelleen, mitä verrataan. Jokaisesta kuormaluettelon rivistä tulee työtilaus, joka linkitetään takaisin siihen.

Mukautettu ei ole epäonnistuminen. Sen alusta antaa meille, kun käsitteellä ei ole puhdasta vakiokotia. Virhe ei ole mukautetun objektin luominen; virhe on luoda sellainen tarkistamatta, onko käsite jo alustalla.

Click to enlarge

Vaihe 3/4: se yksi mukautettu objekti, kun mikään vakio-objekti ei sovi.

Valokuvat: se, että Salesforce voi tallentaa ne, ei tarkoita, että sen pitäisi

”Tarvitsemme toimitusten valokuvat Salesforceen.” Mitä ”Salesforceen” tarkoittaa? Käyttäjien täytyy nähdä ne Salesforcesta, kyllä. Tarkoittaako se, että kuvatiedostojen pitää asua coren tallennustilassa? Ei välttämättä. Laske nollat: noin neljä kuvaa toimitusta kohden, asennuksissa enemmän, ja miljoona toimitusta vuodessa tekee neljästä viiteen miljoonaa kuvaa vuodessa, ja toimitukset kasvavat 30 % vuodessa.

Lähtökohtani on siis: älä tee core-orgista jättimäistä kuva-arkistoa siksi, että käyttäjät tarvitsevat pääsyn kuviin. Tiedostot kuuluvat tallennustilaan, joka on rakennettu sellaiselle volyymille, coren ulkopuolelle, ja Salesforce säilyttää sen, mitä se tarvitsee niiden löytämiseen ja näyttämiseen: viitteen, lukumäärän tai pienen hakemistotietueen kuvaa kohden sekä merkinnän siitä, että pakolliset asennuskuvat ovat valmiina. Pääsy tietoihin ja se, missä tiedot fyysisesti asuvat, ovat kaksi eri kysymystä. Siinä moduuli 4 palaa.

Kentät: tee merkitys näkyväksi

Työtilaus tarvitsee kenttiä: kumppanin viitteen, toimitusikkunan, todellisen toimitusajan, tilan ja muistiinpanoja kuten ”portin koodi” tai ”koira pihalla”. En tee tästä kenttäluetteloa; moduuli 6 teki sen. Käy kysymykset läpi jokaiselle: mitä se tarkoittaa, kuka sen omistaa, muuttuuko se, onko se tunniste, hallittu sanasto, tallennettu vai johdettu, arkaluonteinen. Kumppanin viite on External ID, joten sen yksilöllisyys on osa integraation sopimusta, ei pelkkä valintaruutu. Todellinen toimitusaika on hetki, siis Date/Time. Tila ohjaa käyttäytymistä, joten se on hallittu lista, ei koskaan vapaata tekstiä. Ja ihmisen kotia koskevat toimitusmuistiinpanot ovat henkilötietoja, joten ne luokitellaan. Jokainen kenttä palautuu merkitykseen.

Suhteet: älä vain yhdistä laatikoita

Tili työtilaukseen, työtilaus riveihinsä, kuormaluettelo työtilaukseen ja työn tyyppi kuvaamaan pysähdystä. Sitten moduulin 7 kysymykset jokaiselle viivalle: voiko lapsi olla olemassa yksin, kuka sen omistaa, periytyykö pääsy, voiko se siirtyä, mitä poistossa tapahtuu, kuinka monta lasta voi kasautua? Kun jokainen työtilaus on kourallisen vähittäiskauppakumppanien tilien alla, se tarkoittaa satojatuhansia lapsia vanhempaa kohden: skew-kysymys, johon vastaamme osassa 2. Ja Field Servicen vakiosuhteiden kohdalla tarkista, miten Salesforce on ne jo rakentanut, äläkä oleta niiden vastaavan sitä, minkä olisimme itse suunnitelleet. Kun otat käyttöön vakiomallin, otat käyttöön Salesforcen sen sisällä tekemät päätökset. Ymmärrä ne ennen kuin rakennat niiden päälle.

Omistajuus ja vastaanottaja: älä anna oletuksen päättää

Kaksi päätöstä, jotka oletus tekisi mielellään puolestamme.

Kuka omistaa toimituksen? Vastasimme tähän moduulissa 8, ja vastaus siirtyy suoraan työtilaukseen: omistajuus ei täällä ohjaa kenenkään pääsyä, joten integraatiokäyttäjä omistaa luomansa työtilaukset. Ajojärjestelijät näkevät oman jakelukeskuksensa työtilaukset, tiimit omien reittiensä ja kukin vähittäiskauppakumppani omansa portaalin kautta, kaikki jakamisen kautta, ei omistajuuden. Integraatiokäyttäjällä ei ole roolia, ja se pidetään poissa julkisista ryhmistä, joita jakamissääntömme käyttävät, koska 3 300 tietueella päivässä se ylittää 10 000 tietueen rajan kolmessa päivässä. Ja kirjaamme ylös, mitä tapahtuu, jos käyttäjä joskus vaihdetaan.

Mikä vastaanottaja on? Yhteyshenkilö? Henkilötili? Jotain, mikä säilytetään vain toimituksella? Se riippuu siitä, onko Steve Truckingilla ylipäätään suhdetta näihin ihmisiin (he ovat vähittäiskauppakumppanien asiakkaita), saako yksi kumppani koskaan nähdä toisen kumppanin vastaanottajia, kuinka kauan heidän henkilötietojaan saa säilyttää, ja mittakaavasta: noin miljoona uutta vastaanottajaa vuodessa. Kaikkea tätä meillä ei vielä ole, ja se on ihan hyvä. Joskus oikea vastaus on emme vielä tiedä tarpeeksi. Kirjoita kysymys ylös ja hanki tieto; älä hautaa epävarmuutta mukautettuun objektiin. Vastaamme siihen osan 1 tarkistuspisteessä, kun luvut 4–6 ovat antaneet meille kuvan yrityksestä ja perustiedoista.

Johdonmukaisuus: suojaa malli oikealla kerroksella

Moduulin 9 tikkaat pätevät: kumppanin viite on External ID ja yksilöllinen, joten uudelleen lähetetty kuormaluettelo tekee upsertin eikä luo kaksoiskappaleita; tila on rajoitettu lista; todellinen toimitusaika on pakollinen vasta, kun tila on Delivered; asennuspysähdystä ei voi sulkea ilman tarkistuslistaa ja kuvia. Ei yhtä jättimäistä flow’ta. Jokainen sääntö omalla askelmallaan.

Missä kukin osa asuu

Vielä yksi kierros siivun yli moduulin 4 kysymyksellä: missä kukin tieto asuu? Kurssini diaesityksessä se on yksi dia, looginen fyysistä vastaan: luvun 2 loogiset entiteetit ja se, minne kukin fyysisesti päätyy: coreen sObjectina (__c, jos se on mukautettu) tai big objectina (__b), tai coren ulkopuolelle ulkoisena objektina (__x) tai tietoina, jotka eivät koskaan tule Salesforceen.

• Coressa, päivittäisessä käytössä: tili, työtilaukset ja niiden rivit, huoltokäynnit, työn tyypit, Manifest__c.
• Coressa, arkistoituna: yli kolme vuotta vanhat toimitukset siirtyvät Delivery Historyyn, big objectiin, yhä tallessa korvausvaatimuksia varten, takapihan vajassa.
• Viitattu: vähittäiskauppakumppanin omat tilaustiedot pysyvät kumppanin järjestelmässä; säilytämme kumppanin viitteen External ID:nä ja tavoitamme loput ulkoisen objektin tai integraation kautta, kun joku niitä tarvitsee.
• Coren ulkopuolella: valokuvat, miljoonille kuville rakennetussa tallennustilassa, ja työtilauksesta linkki niihin.

Se on fyysinen malli: ei pelkästään mikä objekti, vaan mikä koti.

Katso nyt koko poikkileikkausta

• Vähittäiskauppakumppani → tili, jolla on Retail Partner -tietuetyyppi; jakelukeskusten esihenkilöt yhteyshenkilöinä.
• Toimitus → Field Servicen työtilaus, aikataulutettuna huoltokäynnin kautta.
• Toimitusrivi → työtilauksen rivi.
• Pysähdyksen laji → työn tyyppi.
• Kuormaluettelo → mukautettu Manifest__c.
• Kumppanin viite → External ID työtilauksella, yksilöllinen kumppania kohden.
• Valokuvat → tallennettu coren ulkopuolelle; Salesforce säilyttää viitteen ja valmiusmerkinnän.
• Toimitushistoria → arkistoidaan big objectiin kolmen vuoden jälkeen.
• Omistajuus → integraatiokäyttäjä, pääsy jakamisen kautta (moduuli 8).
• Vastaanottaja → auki, osan 1 tarkistuspistettä varten.

Click to enlarge

Vaihe 4/4: koko siivu, coressa, arkistoituna ja coren ulkopuolella. Jokainen viiva on lookup-suhde: Salesforce rakensi Field Servicen lookup-suhteiden varaan, ja otamme sen päätökset käyttöön sen mukana.

Kaavio ei ole arkkitehtuuri

Voin ojentaa sinulle tuon kaavion, eikä se riitä. Arkkitehtuuri on sen takana oleva päättely. Miksi tili? Puhtaasti sopiva yritys. Miksi työtilaus eikä Delivery__c? Toimitus käyttäytyy kuin kenttätyö, ja Field Service on jo käytössä. Miksi mukautettu kuormaluettelo? Ei puhdasta vakiokotia. Miksi valokuvat eivät ole vain Files-tiedostoja? Volyymi ja tallennuksen talous. Miksi External ID? Toinen järjestelmä tarvitsee vakaan tunnisteen rajan yli. Miksi integraatiokäyttäjä omistaa työtilaukset? Omistajuus ei täällä ohjaa pääsyä, ja se pitää kirjausketjun rehellisenä. Miksi vastaanottaja on yhä auki? Emme ole vielä vastanneet tarpeeksi moneen kysymykseen. Viivat ovat lopputulos; päätökset tuottivat ne.

Tässä siis tapa, jonka haluan sinun vievän mukanasi luvusta 3. Osoita mitä tahansa fyysisessä mallissa ja kysy miksi? Miksi tämä objekti, tämä tyyppi, tämä suhde, tämä omistaja, tämä paikka, tämä sääntö? Sinun pitäisi pystyä jäljittämään vastaus taaksepäin: konfiguraatiosta fyysiseen malliin, loogiseen malliin ja liiketoiminnan vaatimukseen. Jos et pysty, joku suunnitteli Setupista käsin.

Ja olet varmasti huomannut luvut, joita emme ole vielä kunnolla käyneet läpi: toimitukset kumppania kohden, rivit, kuvat, säilytys, arkistointi. Hyvä. Kysy nollien määrää ennen kuin lukitset suunnitelman: malli, joka toimii kauniisti viidelläkymmenellätuhannella tietueella, voi käyttäytyä aivan eri tavalla viidelläsadalla miljoonalla. Se on osa 2.

Kokeen jälkeen: mitä tekoäly muuttaa. Anna tekoälylle Steve Truckingin taustakuvaus, ja se tuottaa skeeman sekunneissa: tilin, työtilauksen, mukautetut objektit, kentät, jopa käyttöönoton metatiedot. Se on loistava kiihdytin, mutta se ei ole arviointi. Arkkitehdin työ siirtyy vastaavuuksien ja niiden seurausten tarkistamiseen: sopivuus, lisenssit, omistajuus, elinkaari, mittakaava, tunnisteet, tietoturva ja se, mikä jää alustan ulkopuolelle. Tekoäly on rakettibuusteri; se ei kerro, osoitatko oikeaan suuntaan.

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

• Miten kukin liiketoiminnan käsite vastaa Salesforcea: vakio-objekti, mukautettu objekti vai jokin coren ulkopuolella.
• Mitkä tunnisteet, kentät ja suhteet toteuttavat liiketoiminnan merkityksen muuttamatta sitä huomaamatta.
• Mitä alustan käyttäytymistä ja lisensointia käyttöön otetun vakiomallin mukana tulee.
• Mitkä omistajuuteen, elinkaareen, johdonmukaisuuteen, tallennukseen ja mittakaavaan liittyvät päätökset täytyy tehdä ennen kuin suunnitelma on valmis.
• Mitkä kysymykset jäävät tietoisesti auki sen sijaan, että ne piilotettaisiin satunnaisen toteutusvalinnan taakse.

Luvun alussa kysyimme, miten mallin pitäisi elää Salesforcessa. Se on Salesforcen tietoarkkitehtuuria: ei objektien luomista, ei Setupin ulkoa opettelua, ei kauniimpien laatikoiden piirtämistä, vaan liiketoimintamallin harkittua sovittamista alustan muotoon. Jokainen rakenne on sitoumus. Tee niitä, jotka osaat perustella.

Lue lisää

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) ja WorkType (opens in a new tab) (englanniksi, tarkistettu 2026-10-02).
• Steve Truckingin taustakuvaus.