Omistajuus ja elinkaari

🌐 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 8/10 luvussa Salesforcen tietoarkkitehtuuri, Data Architect -kurssin luku 3. Jokainen moduuli on itsenäinen. Edellinen: Suhteilla on seurauksia · Seuraava: Tietojen pitäminen johdonmukaisina

Kysymys, johon tämä moduuli vastaa: Kuka omistaa tietueen, ja mitä sille tapahtuu sen koko elämän aikana?

Kun katson tietomallia, en halua tietää vain, mitä objektit ovat ja miten ne liittyvät toisiinsa. Haluan tietää, mitä tietueille tapahtuu ajan myötä. Kuka ne luo? Kuka ne omistaa? Kuka voi siirtää ne toiselle? Mitä tapahtuu, kun liiketoimintasuhde muuttuu, kun ne eivät ole enää aktiivisia? Pitäisikö ne koskaan poistaa, ja kuinka kauan niitä säilytetään? Mikään tästä ei näy ER-kaaviossa, eli entiteetti-relaatiokaaviossa: luvun 2 tietomallin laatikoissa ja viivoissa. Kaikki se on tietoarkkitehtuuria. Ja Salesforcessa omistajuus on kohta, jossa tietomalli ja suojausmalli törmäävät toisiinsa.

Omistajuus on enemmän kuin nimi kentässä

Ylläpitäjät näkevät tietueessa Owner-kentän ja lukevat sen nimilappuna: Bart omistaa tämän tilin, Lisa omistaa tuon tapauksen. Sitä se voi tarkoittaa. Mutta Salesforcessa omistajuus on myös alustan mekanismi. Objekteissa, joilla on omistaja, omistaja ohjaa sitä, kuka näkee tietueen, roolihierarkian, jakamissääntöjen, jonojen ja uudelleenosoituksen kautta. Joten kun kysyn ”kuka omistaa tämän tietueen?”, en kysy, kenen nimi tulee sivulle. Kysyn, mitä suojaus- ja elinkaaritoimintaa siihen liitämme. Omistaja voi olla käyttäjä tai joissakin objekteissa, muun muassa mukautetuissa objekteissa, tapauksissa ja liideissä, jono, ja kummassakin tapauksessa omistaja saa täyden pääsyn tietueeseen (Understanding Sharing (opens in a new tab)).

Siksi erotan liiketoimintavastuun tietueen omistajuudesta. Joskus ne ovat sama henkilö. Joskus eivät. Jos liiketoiminta sanoo, että ajojärjestelijä on vastuussa toimituksesta, se ei automaattisesti tee ajojärjestelijästä omistajaa. Vastuu voi asua omassa kentässään, kun taas omistajuus asetetaan tukemaan suojausta ja mittakaavaa. Älä anna niiden sekoittua vain siksi, että molemmissa käytetään sanaa ”omistaja”.

Jakotaulu: missä omistajuudesta tulee pääsy

Jotkut eivät edes tiedä, mikä jakotaulu (share table) on. Jokaisen tietoarkkitehdin pitäisi tietää.

Suurin osa tietueen jakamisesta säilytetään siihen liittyvässä jako-objektissa (share object), joka on Salesforcen versio pääsynvalvontaluettelosta (Understanding Sharing (opens in a new tab)). Tilillä on AccountShare, yhteyshenkilöllä ContactShare, ja mukautettu objekti saa omansa: Truck__c-objektilla on Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Jokainen sen rivi kertoo neljä asiaa:

• Mikä tietue: vanhemman ID.
• Kuka: käyttäjä tai ryhmä (julkinen ryhmä, roolin ryhmä, alue).
• Kuinka paljon: Read, Edit tai All (täysi pääsy).
• Miksi: rivin syy (row cause). Owner omistajalle, Rule jakamissäännölle, Manual manuaaliselle jaolle, Team, implisiittiset syyt, jotka Salesforce lisää tilin ja sen lasten välille, sekä syyt, jotka kehittäjä määrittää Apex-jakamiselle.

Kurssilla avaan Workbenchin ja kyselen jakotaulua samalla kun jaan tietueen, ja näet rivien ilmestyvän ja katoavan. Kun joku kysyy ”miksi tämä henkilö näkee tuon?”, vastaus on usein rivissä syineen.

Mutta kaikki ei ole siinä. Organisaationlaajuinen oletus (organization-wide default) ei ole rivi. Roolihierarkiaakaan ei tallenneta sinne: omistajan yläpuolella olevien ihmisten pääsy selvitetään silloin, kun sitä tarvitaan. Ja View All, Modify All, View All Data ja Modify All Data ohittavat jakotaulun kokonaan (Sharing a Record Using Apex (opens in a new tab)). Kuten sanon kurssilla: rastita View All, niin olet ohittanut jakotaulun.

Salesforce myös jakaa joitakin tietueita puolestasi niiden suhteiden vuoksi. Tämä on implisiittistä jakamista (implicit sharing), ja se toimii tilin ja sen lasten välillä. Jos näet yhteyshenkilön, tapauksen tai myyntimahdollisuuden, voit myös lukea tilin, jolle se kuuluu. Ja tilin omistaja saa pääsyn tilin yhteyshenkilöihin, tapauksiin ja myyntimahdollisuuksiin tasolla, jonka omistajan rooli määrää (Implicit Sharing (opens in a new tab)). Uusimmissa julkaisuissa Salesforce selvittää osan tuosta lasten pääsystä silloin, kun sitä tarvitaan, sen sijaan että tallentaisi sen riveinä, joten älä ylläty, jos jakotaulun kysely ei näytä sitä. Annan tässä vain vihjeen; yksityiskohdat ovat luvussa Suhteet ja sisäänrakennettu jakaminen.

Vielä yksi poikkeus siltä varalta, että sinulla on paljon ulkoisia käyttäjiä. Suurivolyymiset yhteisökäyttäjät (high-volume community users), eli Customer Community -lisenssit, jotka on tehty tuhansille tai miljoonille asiakkaille, eivät saa roolia, eivät voi kuulua julkisiin ryhmiin, eikä heille voi antaa tietueita jakamissäännöillä tai manuaalisella jakamisella (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). Heille jakotaulu ei ole vastaus: he pääsevät tietueisiin jakojoukkojen (sharing sets) kautta, jotka täsmäävät tietueen tilin tai yhteyshenkilön käyttäjän omaan. Se on yksi syy siihen, miksi nuo lisenssit skaalautuvat. Sharing and Visibility -kurssi käsittelee sitä luvussa Jakaminen ulkoisille käyttäjille.

Ja muista moduuli 7: detail-objektilla ei ole jako-objektia lainkaan. Sen pääsy tulee masterin jako-objektista ja master-detail-kentän Sharing Setting -asetuksesta.

Miksi tietoarkkitehti välittää? Koska omistajuus kirjoitetaan tähän tauluun. Jokainen omistajan vaihdos, jokainen uusi jakamissääntö, jokainen käyttäjä, joka siirtyy roolista tai ryhmästä toiseen, tarkoittaa, että Salesforce lisää ja poistaa rivejä. Muutamalla tuhannella tietueella kukaan ei huomaa. Kymmenellä miljoonalla, kun yksi käyttäjä omistaa suurimman osan, se on uudelleenlaskenta, jonka kohtaamme hetken päästä.

Koetieto. Mukautetun objektin jako-objektin nimi on Object__Share, kuten Truck__Share. Detail-objektilla ei ole jako-objektia: sen pääsy tulee masterilta. Ja kun tietueen omistaja vaihtuu, sen manuaaliset jaot poistetaan, kun taas Apex-jakaminen kehittäjän omalla syyllä säilyy.

Tässä tietomalli antaa vastuun suojausmallille, ja opetan loput Sharing and Visibility Architect -kurssilla: Steven 22 tapaa jakaa tietue, Org-Wide Defaults, omistajuus, jonot ja roolihierarkia, Suhteet ja sisäänrakennettu jakaminen implisiittisille jaoille ja Ohjelmallinen jakaminen ja turvallinen koodi Apex-jakamisen syille. Tällä kurssilla luku 12 kokoaa sen yhteen ihmisille, sovelluksille ja agenteille.

Joskus omistajuus peritään

Edellisessä moduulissa näimme, että master-detail-lapsella ei ole omaa omistajaa; se seuraa vanhempaansa. Se on usein juuri oikein. Tarvitseeko liiketoiminta eri omistajan toimituksen jokaiselle riville? Ei. Toimitus omistaa elinkaaren, ja rivi kuuluu sille. Siksi suhteiden suunnittelu ja omistajuuden suunnittelu tapahtuvat yhdessä: kun valitsit master-detailin, olit jo tehnyt osan omistajuuspäätöksestä.

Kuka omistaa tietueet, jotka järjestelmät luovat?

Nyt siitä tulee kiinnostavaa. Ihminen luo tilin, ja ehkä hänestä tulee omistaja. Mutta ERP lähettää yön aikana 100 000 tapahtumaa. Kuka ne omistaa? Integraatiokäyttäjä? Jono? Tietojen perusteella päätelty alueellinen omistaja? Järjestelmätili, jota kukaan ei ole ajatellut viiteen vuoteen? Ja nyt myös agentit luovat tietueita.

Kantani: se riippuu siitä, onko omistajuudella merkitystä jakamiselle. Integraatiokäyttäjä tai agenttikäyttäjä on kelvollinen käyttäjä, ja se voi omistaa tietueet. Jos omistajuus ohjaa pääsyä kyseisessä objektissa (roolihierarkian tai jakamissääntöjen kautta), osoita tietueet oikealle omistajalle: oikealle käyttäjälle, jonolle tai erilliselle omistajakäyttäjälle. Jos ei ohjaa, järjestelmäkäyttäjän pitäminen omistajana voi olla parempi valinta, koska silloin kirjausketju johtaa suoraan takaisin siihen, mikä tietueen loi.

Kummassakin tapauksessa päätä se tarkoituksella. Integraatiotili, joka omistaa kaiken, on hiljaa muuttunut osaksi suojausarkkitehtuuriasi, ja jonkun on tiedettävä, mitä tapahtuu, jos se joskus poistetaan käytöstä.

Omistajuudesta voi tulla mittakaavaongelma

Myös jakaumalla on väliä. Kymmenen miljoonaa tietuetta tuhansien omistajien kesken on yksi muoto. Kymmenen miljoonaa tietuetta yhden käyttäjän omistuksessa on aivan toinen. Salesforce kutsuu sitä omistajuuden data skew’ksi (ownership data skew), kun yksi käyttäjä omistaa yli 10 000 tietuetta objektista (Ownership Data Skew (opens in a new tab)). Se tapahtuu yleensä, kun joku parkkeeraa kaiken yhdelle käyttäjälle tai jonolle: kaikki osoittamattomat liidit paikkamerkkikäyttäjälle, jokainen integraatiotietue integraatiokäyttäjälle. Se on harmitonta, kunnes tuo käyttäjä siirtyy roolihierarkiassa tai ryhmään tai ryhmästä, josta jakamissääntö riippuu. Silloin Salesforcen on säädettävä valtava määrä jakomerkintöjä, ja saat pitkään kestäviä uudelleenlaskentoja.

Ohjeet ovat käytännöllisiä. Jaa omistajuus useammalle käyttäjälle, missä voit. Jos yhden käyttäjän on omistettava paljon, pidä hänet roolihierarkian ulkopuolella; jos hän tarvitsee roolin, laita hänet omaan rooliinsa huipulle äläkä siirrä häntä, ja pidä hänet poissa julkisista ryhmistä, joita jakamissäännöt käyttävät (Ownership Data Skew (opens in a new tab)). Sama ajattelu pätee edellisen moduulin vanhempaan, jolla on liikaa lapsia, eli vanhempi–lapsi-skew’hun (parent-child skew).

Jakauma on siis osa fyysistä mallia. Älä kysy vain, kuinka monta tietuetta; kysy, miten ne jakautuvat. Se on taas yksi versio nollien määrästä: ei vain kuinka monta nollaa, vaan mihin nollat keskittyvät. Osa 2 menee syvälle skew’hun; tässä haluan sinun näkevän sen tulevan. Sharing and Visibility -kurssi palaa siihen luvussa Jakaminen suuressa mittakaavassa.

”Oletusomistajasta” tulee arkkitehtuuria

Tässä malli, jonka näen koko ajan. Kukaan ei tiedä, kenen pitäisi omistaa jokin, joten joku sanoo: ”Osoita ne kaikki integraatiokäyttäjälle” tai ”luo yleiskäyttäjä nimeltä System”. Ehkä se on oikein. Mutta älä tee sitä vahingossa. Väliaikaisella oletuksella on tapana muuttua pysyväksi: kaksi vuotta myöhemmin jokainen tietue kuuluu käyttäjälle integration@company.com, kukaan ei muista miksi, ja sen muuttaminen on projekti. Se on luvun 1 peruttavuustesti: ennen kuin annat miljoona tietuetta yhdelle omistajalle, kysy, mitä sen muuttaminen myöhemmin vaatii.

Uudelleenosoitus on elinkaaritapahtuma

Omistajat vaihtuvat. Myyjät lähtevät, alueet siirtyvät, tiimit organisoituvat uudelleen, alueita tasapainotetaan. Mikä riippuu omistajasta: jakaminen, automaatio, raportit, jonot, eskalaatiot, integraatiot? Jos omistajan vaihtaminen muuttaa sitä, kuka näkee tietueen, uudelleenosoitus ei ole ylläpitäjän siivousta. Se on suojaustapahtuma, ja miljoonalla tietueella myös operatiivinen tapahtuma. Seuraa jakotaulua, kun se tapahtuu: manuaaliset jaot poistetaan, kun omistaja vaihtuu, kun taas Apex-jakaminen kehittäjän omalla syyllä selviää muutoksesta (Understanding Sharing (opens in a new tab)). Kurssilla jaan tietueen jonkun kanssa, vaihdan omistajan, ja henkilö menettää pääsyn. Ryhmä yllättyy aina.

Ja muista, että omistajuus ei ole sama asia kuin pääsy. Omistaja ei ole ainoa, jonka pitää nähdä tietue, ja Salesforcessa on monta tapaa antaa pääsy: roolihierarkia, jakamissäännöt, tiimit, alueet, manuaalinen ja ohjelmallinen jakaminen. Sharing and Visibility -kurssi menee niihin syvälle alkaen luvusta Steven 22 tapaa jakaa tietue. Arkkitehdin pointti on yksinkertaisempi: älä käytä omistajuutta jokaisen pääsyongelman ratkaisemiseen. Jos siirtelet omistajia vain, jotta joku näkisi tietueen, ratkaiset luultavasti väärää ongelmaa.

Luominen on vasta alku

Paljon tietomallinnusta pysähtyy luomiseen: kentät, objekti, suhde, valmis. Mutta tietue voi elää kymmenen vuotta. Sitä päivitetään, sen omistaja vaihtuu, sen tila ja suhteet vaihtuvat, se muuttuu passiiviseksi, siitä tulee historiaa, se voi tarvita arkistointia ja joskus ehkä poistamista. Arkkitehtuuri ei ole vain sitä, miten tietue syntyy. Se on sitä, mitä tapahtuu syntymästä kuolemaan.

Click to enlarge

Älä poista vain siksi, että jokin on vanha

Vähittäiskauppakumppani lakkaa lähettämästä töitä. Poistetaanko tili? Ei automaattisesti: sen toimituksilla, reklamaatioilla ja laskutushistorialla on yhä merkitystä. Kuorma-auto poistetaan liikenteestä. Poistetaanko se toimitushistorioineen ja vahinkoilmoituksineen? Asia ei ehkä ole enää aktiivinen, mutta sen tiedot ovat. Joten erotan passiivisen ja poissa olevan. Käytöstä poistettu kuorma-auto voi jäädä malliin; entinen työntekijä voi yhä näkyä kirjaushistoriassa. Arkkitehtuurin on säilytettävä tosiasiat, joilla on merkitystä operatiivisen suhteen päätyttyä.

Säilytys on liiketoimintavaatimus

Toinen puoli: kaiken säilyttäminen ikuisesti ei myöskään ole arkkitehtuuria. Tallennustila kasvaa, raportit hidastuvat, haku muuttuu kohinaisemmaksi, ja tietosuojalaki voi vaatia joidenkin tietojen poistamista. Joten haluan nimenomaisen vastauksen kysymykseen kuinka kauan säilytämme tätä? ”Salesforce säilyttää sen” ei ole säilytyskäytäntö.

Ja enimmäkseen tämä on kysymys tapahtumatiedoista. Viitetiedot, tuotteet, palvelutyypit, jakelukeskukset, eivät kasva valtaviksi, ja muut tietueet osoittavat niihin, joten ne yleensä jäävät. Asiakastiedot ovat siltä väliltä: voi tulla päivä, jolloin asiakkaan elinkaari päätetään, erityisesti kun säilytät henkilötietoja ja niiden säilyttämisen peruste päättyy. Mutta volyymi on tapahtumissa: toimituksissa, tilauksissa, tapauksissa, ajanvarauksissa, joita luodaan joka päivä, ikuisesti. Ne kasvavat satoihin miljooniin riveihin, ja siellä säilytyksen on oltava nimenomaista: ehkä kahden vuoden operatiiviset tiedot orgissa, seitsemän vuoden taloustiedot jossain, yhdeksänkymmentä päivää joillekin valokuville. Ne ovat liiketoimintasääntöjä, ja jos kukaan ei ole kysynyt, arkkitehdin pitäisi.

Olen sanonut sen kurssilla vuosia: jos et arkistoi tänään, arkistoitko koskaan? ”Hoidetaan se myöhemmin” muuttuu helposti hätäprojektiksi kolmensadan miljoonan tietueen kohdalla. Osassa 2 on kokonainen moduuli arkistoinnista ja tyhjentämisestä, ja se rakentuu saman kysymyksen varaan.

Steve Trucking: kuka omistaa toimituksen?

Toimitus luodaan vähittäiskauppakumppanin kuormaluettelosta (manifest) integraation avulla noin 3 300 kertaa päivässä. Kuka sen omistaa? Ei vähittäiskauppakumppani; se on liiketoimintasuhde. Ei vastaanottaja (Recipient). Tiimi toteuttaa sen, mutta pitäisikö tietueen vaihtaa omistajaa aina, kun tiimit vaihtavat kuorma-autoja? Ajojärjestelijä? Jakelukeskus? Jono? Integraatiokäyttäjä, joka sen loi?

Sovelletaan nyt tätä moduulia, alkaen kysymyksestä, joka ratkaisee asian: ohjaako omistajuus kenenkään pääsyä toimituksiin? Steve Truckingissa ei ohjaa. Ajojärjestelijät näkevät oman jakelukeskuksensa toimitukset, tiimit näkevät reiteillään olevat, ja kukin vähittäiskauppias näkee omansa kumppaniportaalissa. Mikään siitä ei riipu siitä, kuka omistaa tietueen; se tulee jakelukeskuksesta, reitistä ja kumppanista.

Joten vastaukseni: integraatiokäyttäjä omistaa toimitukset. Se on hyvä esimerkki järjestelmäkäyttäjästä, joka omistaa tietueita tarkoituksella:

• Kirjausketju on rehellinen. Jokaisen toimituksen omistaja kertoo, mistä se tuli: kuormaluetteloiden integraatiosta.
• Pääsy tulee jakamisesta, ei omistajuudesta. Jakelukeskukseen perustuvat kriteeripohjaiset jakamissäännöt antavat kunkin jakelukeskuksen tiimille sen toimitukset; kumppanit pääsevät omiinsa portaalin kautta.
• Skew suunnitellaan pois. 3 300 toimituksella päivässä integraatiokäyttäjä ylittää 10 000 toimitusta kolmessa päivässä, joten se on omistajuuden skew’ta ensimmäisestä päivästä lähtien, ja se on kunnossa, jos varaudumme siihen. Integraatiokäyttäjällä ei ole roolia, joten mitään sen yläpuolella hierarkiassa ei tarvitse laskea uudelleen, ja se pysyy poissa julkisista ryhmistä, joita jakamissääntömme käyttävät.
• Kukaan ei osoita toimituksia uudelleen. Tiimit vaihtavat kuorma-autoja ja ajojärjestelijät vaihtavat vuoroja, eikä omistaja koskaan vaihdu, joten uudelleenosoitusten myrskyä ei tule eikä manuaalisia jakoja menetetä.

Ja kirjoita muistiin, mitä tapahtuu, jos tuo käyttäjä joskus poistetaan käytöstä tai korvataan, koska se omistaa nyt miljoonia tietueita. Sitä päätöstä seuraava tiimi tulee etsimään.

Kokeen jälkeen: mitä tekoäly muuttaa. Agentit luovat ja muuttavat tietueita koneen nopeudella. Jos agentti luo 100 000 tietuetta oman käyttäjänsä alle, ”korjataan omistaja myöhemmin” muuttuu skew’ksi, jakamisen uudelleenlaskennaksi ja siivousprojektiksi. Päätä agentin omistajuussääntö ennen kuin se otetaan käyttöön, samalla kysymyksellä: onko omistajuudella tässä merkitystä jakamiselle?

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

• Edustaako omistajuus liiketoimintavastuuta, suojausmekanismia vai molempia, ja missä vastuu asuu, jos ei Owner-kentässä.
• Tarvitsevatko tietueet oman omistajan, vai pitäisikö niiden periä se vanhemmalta.
• Kuka omistaa tietueet, jotka integraatiot ja agentit luovat, sen mukaan, ohjaako omistajuus jakamista.
• Miten omistajuus jakautuu, ja miten omistajuuden skew vältetään, kun yhden käyttäjän on omistettava paljon.
• Milloin tietueet muuttuvat passiivisiksi, milloin ne arkistoidaan, kuinka kauan niitä säilytetään ja milloin poistaminen on oikein.

Kun katsot fyysistä mallia, älä kysy vain, mihin tiedot on tallennettu. Kysy, kuka ne omistaa tänään, kuka voi omistaa ne huomenna ja mitä tapahtuu, kun emme enää tarvitse niitä. Seuraavaksi: oikeallakin objektilla, kentillä, suhteilla ja omistajalla tietojen on silti pysyttävä luotettavina.

Lue lisää

• Apex Developer Guide, Understanding Sharing (opens in a new tab), englanniksi, tarkistettu 2026-10-13: omistajat (käyttäjä tai mukautetuissa objekteissa, tapauksissa ja liideissä jono) saavat täyden pääsyn; suurin osa jakamisesta asuu siihen liittyvässä jako-objektissa; roolihierarkia johdetaan ajon aikana; manuaaliset jaot poistetaan, kun omistaja vaihtuu, Apex managed sharing säilyy; rivin syyn arvot.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab), englanniksi, tarkistettu 2026-10-13: AccountShare, MyCustomObject__Share; detail-objekteilla ei ole jako-objektia; mitä jako-objekti ei seuraa (OWD, roolihierarkia, View All ja Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab), englanniksi, tarkistettu 2026-10-13: pääsy tilin ja sen yhteyshenkilöiden, tapausten ja myyntimahdollisuuksien välillä.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) ja Sharing Rule Considerations (opens in a new tab), englanniksi, tarkistettu 2026-10-13: ei rooleja, ei jakamissääntöjä tai manuaalisia jakoja; niiden sijaan jakojoukot.
• Sharing and Visibility Architect -kurssi: Steven 22 tapaa jakaa tietue, Org-Wide Defaults, omistajuus, jonot ja roolihierarkia, Suhteet ja sisäänrakennettu jakaminen, Ohjelmallinen jakaminen ja turvallinen koodi, Jakaminen ulkoisille käyttäjille, Jakaminen suuressa mittakaavassa.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) ja Parent-Child Data Skew (opens in a new tab), englanniksi, tarkistettu 2026-10-02.