Salesforcen jakomalli on olennainen osa organisaatiosi kykyä tarjota suojattu pääsy sovelluksen dataan. Tästä syystä on tärkeää, että rakennat jakomallisi oikein nykyisten ja tulevien datan käyttöoikeusvaatimusten mukaisesti. Tässä asiakirjassa tarkastelemme datan käytettävyyden komponentteja, jakomallin käyttötapoja ja todellisia asiakkaan jakoratkaisuja, ja tarjoamme joitakin ohjeita vianmääritykseen.

Tämä asiakirja on tarkoitettu järjestelmän kehittyneille pääkäyttäjille ja arkkitehdeille. Sinulla täytyy olla toimiva Knowledge Salesforcen suojaus- ja jakomallista ymmärtääksesi ne. Tämän oppaan edellytykset ovat:

• Salesforce-ohje: Jakoasetukset
• Trailhead-moduuli: Tietoturva
• Tietueiden käyttöoikeuksien suunnitteleminen Enterprise Scale -ominaisuutta varten
• Salesforce on hyvin rakennettu - turvallinen

Tämä opas keskittyy tärkeimpiin ominaisuuksiin, joita käytetään vakiomuotoisten ja mukautettujen objektien tietuetason käyttöoikeuksien hallintaan. Aiheisiin, joita tämä opas ei kata, sisältyy:

• Kansion käyttöoikeus
• Sisällön käyttöoikeus
• Chatter
• Knowledge käyttöoikeus
• Ideat, Kysymykset/vastaukset-käyttöoikeus
• Mobiilitietojen käytettävyys

Tietuetason suojaus sallii sinun myöntää käyttäjille pääsyn joihinkin objektien tietueisiin, mutta ei muihin. Kuten useimmissa sovelluksissa, tietojen käyttö alkaa käyttäjältä. Sovelluksen täytyy tietää, kuka käyttäjä on ennen käyttöoikeuden myöntämistä. Salesforcessa on erityyppisiä käyttäjiä, ja joskus käyttöoikeustaso vaihtelee tyypin mukaan. Sen sijaan, että tarkastelisimme jokaisen lisenssityypin jokaisen attribuutin, keskityisimme tässä mielenkiintoisiin attribuutteihin, jotka vaikuttavat merkittävästi tietojen käyttöoikeuksiin. Tietueen omistajuus ja täydet käyttöoikeudet ovat synonyymejä ja vaihdettavissa, ja ne tarjoavat käyttäjille tietueen korkeimman käyttöoikeustason.

Suuren määrän käyttäjät

Raskaan portaalin käyttäjät (mukaan lukien Customer Community-, High Volume Customer Portal- ja Authenticated Website -lisenssityyppien käyttäjät) eivät käytä jakomallia, koska heidän lisenssityyppinsä eivät tue rooleja. Näillä lisensseillä on oma jakomallinsa, joka toimii käyttäjän (lisenssin omistajan) ja Tili- ja Yhteyshenkilö-hakujen tietojen välisen vieraan avaimen täsmäyksen perusteella. Pääkäyttäjät voivat luoda jakojoukkoja tai jakoryhmiä myöntääkseen tehokäyttäjille tietueiden käyttöoikeudet.

Chatter Free- ja Chatter External -lisenssit

Chatter Free- ja Chatter External -lisenssit eivät noudata vakiomuotoista jakomallia. Näillä lisensseillä ei ole käyttöoikeutta CRM-tietueisiin (vakio-objekteihin tai mukautettuihin objekteihin) tai sisältöominaisuuksiin, eivätkä ne tue rooleja, joten jakamista ei ole.

Oletamme tämän asiakirjan lopussa, että Salesforce-käyttäjätyyppi käyttää täyttä jakomallia. Lisätietoja käytettävissä olevista lisenssityypeistä on kohdassa Käyttäjälisenssit.

Profiilit ja käyttöoikeusjoukot

Profiilit ja käyttöoikeusjoukot tarjoavat objektitason suojauksen määrittämällä, millaisia tietoja käyttäjät näkevät ja voivatko he muokata, luoda tai poistaa tietueita. Kunkin objektin kaikkien tietojen tarkastelu- ja muokkausoikeudet eivät huomioi jakosääntöjä ja asetuksia, joten pääkäyttäjät voivat myöntää käyttöoikeuden nopeasti tiettyyn objektiin liittyviin tietueisiin koko organisaatiossa. Nämä käyttöoikeudet ovat usein suositeltuja vaihtoehtoja kaikkien tietojen tarkastelu- ja muokkausoikeuksille, jotka sallivat käyttäjien tarkastella ja muokata kaikkia sovelluksia ja tietoja.

Profiilit ja käyttöoikeusjoukot hallitsevat myös kenttätason suojausta, joka määrittää kunkin objektin kentät, joita käyttäjät voivat käyttää. Objektilla voi esimerkiksi olla 20 kenttää, mutta kenttätason suojaus voidaan määrittää estämään käyttäjiä näkemästä viittä 20 kentästä.

Suosittelemme vahvasti, että käytät käyttäjiesi objektien käyttöoikeuksien hallintaan käyttöoikeusjoukkoja ja käyttöoikeusjoukkoryhmiä profiilien sijaan. Koska voit käyttää pienempiä käyttöoikeusjoukkojen rakennuspalikoita uudelleen, voit välttyä luomasta kymmeniä tai jopa satoja profiileja kullekin käyttäjälle ja työtehtävälle.

Tietueiden omistajuus ja jonot

Jokaisen tietueen omistajan täytyy olla yksi käyttäjä tai jono. Omistajalla on tietueen käyttöoikeus omistajan profiilin objektiasetusten perusteella. Jos esimerkiksi omistajan profiililla on objektin luonti- ja lukuoikeus, mutta ei muokkaus- tai poisto-oikeutta, omistaja voi luoda objektille tietueen ja nähdä uuden tietueen. Omistaja ei voi kuitenkaan muokata tai poistaa tietuetta. Hierarkiassa korkeammalla olevat käyttäjät (roolit tai alueet) perivät samat käyttöoikeudet kuin vakio-objektien alaiset käyttäjät. Jos alaisella on Vain luku -oikeus, myös hänen yläpuolellaan roolihierarkiassa olevat käyttäjät. Tämä käyttöoikeus koskee käyttäjien omistamia tietueita sekä heidän kanssaan jaettuja tietueita.

Jonot auttavat sinua priorisoimaan, jakamaan ja kohdistamaan tietueita tiimeille, jotka jakavat töitä. Jonojen jäsenet ja roolihierarkiassa ylempänä olevat käyttäjät voivat käyttää jonoja luettelonäkymistä ja ottaa jonossa olevien tietueiden omistajuuden.

Jos yksi käyttäjä omistaa yli 10 000 tietuetta, suosittelemme seuraavaa:

• Omistajan käyttäjätietueella ei tulisi olla roolihierarkiassa.

• Jos omistajan käyttäjätietueella täytyy olla rooli, aseta rooli hierarkian ylälaitaan roolihierarkian omassa haarassaan.

Lisätietoja on kohdassa Salesforce Well-Architected - Reliable.

Organisaationlaajuiset oletusasetukset

Organisaationlaajuiset jakoasetukset määrittävät käyttäjien oletusarvoisen käyttöoikeustason toistensa tietueisiin. Käytät organisaationlaajuisia jakoasetuksia lukitaksesi datasi rajoittavimpaan tasoon. Käytä muita tietuetason suojaus- ja jakotyökaluja myöntääksesi käyttöoikeudet valikoidusti muille käyttäjille. Käyttäjillä voi esimerkiksi olla objektitason käyttöoikeudet mahdollisuuksien lukemiseen ja muokkaamiseen, ja organisaationlaajuinen jakoasetus on Vain luku. Nämä käyttäjät voivat lukea oletusarvoisesti kaikki mahdollisuustietueet, mutta he eivät voi muokata niitä, ellei heillä ole tietueen omistajaa tai muita käyttöoikeuksia.

Organisaationlaajuisia oletusasetuksia voidaan muuttaa asetuksesta toiseen (Yksityinen ylätason ohjaamaan ja sitten takaisin Yksityinen). Nämä muutokset vaativat kuitenkin jakamisen uudelleenlaskennan, ja määrä voi johtaa pitkiin käsittelyaikoihin.

Voit määrittää Myönnä käyttöoikeudet hierarkioiden avulla -asetuksen vain mukautetuille objekteille. Jos tämä vaihtoehto ei ole valittuna (oletus on valittuna), roolihierarkiassa korkeammalla olevia käyttäjiä estetään perimästä käyttöoikeutta. Tämä asetus löytyy organisaationlaajuisista oletusasetuksista.

Roolihierarkia

Roolihierarkia edustaa tietojen käyttöoikeustasoa, jonka käyttäjä tai käyttäjäryhmä tarvitsee. Roolihierarkia varmistaa, että esimiehillä on aina pääsy samaan dataan kuin työntekijöillään, riippumatta organisaationlaajuisista oletusasetuksista. Roolihierarkioiden ei tarvitse vastata organisaatiokaaviota tarkalleen. Sen sijaan jokaisen hierarkiassa olevan roolin tulisi edustaa tietojen käyttöoikeustasoa, jonka käyttäjä tai käyttäjäryhmä tarvitsee.

Voit luoda enintään 5 000 roolia Spring ’21 -julkaisun yhteydessä tai sen jälkeen luoduissa Salesforce-organisaatioissa. Ennen Spring ’21 -julkaisua luoduissa organisaatioissa voit luoda enintään 500 roolia ja ottaa yhteyttä Salesforce-asiakastukeen nostaaksesi tätä rajoitusta. Suosittelemme pitämään sisäisten roolien määrän 25 000 ja ulkoisten roolien määrän 100 000.

Suosittelemme pitämään roolihierarkian enintään 10 haaratasolla hierarkiassa.

Kun käyttäjän rooli muuttuu, kaikki asiaankuuluvat jakosäännöt arvioidaan käyttöoikeuksien korjaamiseksi tarvittaessa. Saman roolin työtoverit eivät takaa heille pääsyä toistensa tietoihin.

Roolihierarkian mallinnus alkaa organisaation rakenteen ymmärtämisestä. Tämä perustuu tavallisesti päällikön vaikutusalueen ymmärrykseen, alkaen ylälaidasta. Pääjohtaja valvoo koko yritystä. Pääjohtajalla on tavallisesti suoria raportteja, jotka voidaan segmentoida liiketoimintayksikön (myynti tai tuki) tai maantieteellisen alueen (EMEA, APAC) mukaan. Tällä henkilöllä on sitten suorat raportit, jotka voidaan segmentoida tarkemmin, jne. Vaikka tämä kuulostaa hyvältä HR-organisaatiokaaviolta, kun mallinnat datan käyttöoikeuksia, keskity datan käytettävyyteen ja ota huomioon HR-raportointi.

Päällekkäiset asettelut ovat aina hierarkian hankala osa. Jos he ovat omassa haarassaan, he tarvitsevat joko jakosääntöjä, tiimejä tai aluehallintaa saadakseen tarvitsemansa käyttöoikeudet. Jos ne on taiteltu hierarkiaan, raportointi saattaa vaikuttaa niihin.

On tärkeää käyttää aikaa roolihierarkian määrittämiseen, koska se on yksi jakomallin perusteellisista osa-alueista.

Julkiset ryhmät

Julkinen ryhmä on kokoelma yksittäisiä käyttäjiä, rooleja, alueita jne., joilla kaikilla on yhteinen toiminto. Julkiset ryhmät voivat sisältää:

• Käyttäjät
• Asiakasportaalin käyttäjät
• Kumppanikäyttäjät
• Roolit
• Roolit ja sisäiset aliroolit
• Roolit, sisäiset roolit ja portaalin aliroolit
• Portaaliroolit
• Portaaliroolit ja aliroolit
• Alueet
• Alueet ja aliroolit
• Muut julkiset ryhmät (sisäkkäin)

Ryhmiä voidaan asettaa sisäkkäin (ryhmä A on sisäkkäin ryhmään B), mutta ne eivät sisällä yli viittä tasoa. Sisäkkäinen asettelu vaikuttaa ryhmän ylläpitoon ja suorituskykyyn ryhmäjäsenyyksien laskennan takia. Suosittelemme, että pidät organisaation julkisten ryhmien kokonaismääränä 100 000.

Omistajiin perustuvat jakosäännöt

Omistajiin perustuvat jakosäännöt sallivat organisaationlaajuisten oletusasetusten ja roolihierarkian poikkeukset, jotka antavat ylimääräisille käyttäjille pääsyn tietueisiin, joita he eivät omista. Omistajiin perustuvat jakosäännöt perustuvat vain tietueen omistajaan.

Yhteyshenkilöiden omistajiin perustuvat jakosäännöt eivät koske yksityisiä yhteyshenkilöitä tai yhteyshenkilöitä, jotka eivät liity tiliin.

Jakosääntöjen enimmäismäärä per objekti on 300.

Ehtoihin perustuvat jakosäännöt

Ehtoihin perustuvat jakosäännöt tarjoavat pääsyn tietueisiin tietueen kenttäarvojen (ehtojen) perusteella. Jos ehdot täyttyvät (yksi tai useampi kenttäarvo), säännölle luodaan jakotietue. Tietueen omistajuus ei ole huomioitava asia.

Ehtoihin perustuvien ja vieraskäyttäjien jakosääntöjen rajoitus per objekti on 50.

Vierailukäyttäjien jakosäännöt

Vieraskäyttäjien jakosääntö on erityinen ehtoihin perustuva jakosääntö, jota käytetään tietueiden käyttöoikeuksien myöntämiseksi todentamattomille vieraskäyttäjille. Ehtoihin perustuvien ja vieraskäyttäjien jakosääntöjen rajoitus per objekti on 50.

Varoitus: Vieraskäyttäjien jakosääntötyyppi myöntää käyttöoikeuden vieraskäyttäjille, joilla ei ole kirjautumistunnuksia. Kun luot vieraskäyttäjien jakosäännön, voit myöntää välittömästi rajoittamattoman pääsyn kaikkiin tietueisiin, jotka vastaavat jakosäännön ehtoja. Ota huomioon kaikki tämäntyyppisen jakosäännön luomisen käyttötarkoitukset ja vaikutukset salliaksesi Salesforce-datasi ja tarjotaksesi vieraskäyttäjillesi tarvitsemiesi tietojen käyttöoikeudet. Ota käyttöön tietoturva-asetuksia, jotka sinun mielestäsi sopivat tietojesi luottamuksellisuuteen. Salesforce ei ole vastuussa tietojesi paljastamisesta todentamattomille käyttäjille tämän oletusasetusten muutoksen perusteella.

Manuaalinen jakaminen

Joskus on mahdotonta määrittää yhdenmukaista käyttäjäryhmää, joiden täytyy voida käyttää tiettyjä tietueita. Tietueiden omistajat tai muut käyttäjät, joilla on asianmukaiset käyttöoikeudet, kuten järjestelmänvalvojat, voivat käyttää manuaalista jakamista myöntääkseen luku- ja muokkausoikeuksia käyttäjille, joilla ei ole käyttöoikeutta muilla tavoin. Manuaalista jakamista ei automatisoida, kuten organisaationlaajuisia jakoasetuksia, roolihierarkioita tai jakosääntöjä. Se sallii tietueiden omistajien jakaa tietueita joustavasti käyttäjille, joiden täytyy nähdä ne.

Manuaalinen jakaminen poistetaan, kun tietueen omistaja muuttuu tai kun myönnetty jako-oikeus ei myönnä lisäoikeuksia objektin organisaationlaajuisen oletusarvoisen jako-oikeustason ulkopuolelle. Tämä koskee myös ohjelmallisesti luotuja manuaalisia jakoja.

Manuaaliset jakotietueet määritetään jakotietueiksi, joiden rivin syy on määritetty manuaaliseksi jakamiseksi.

Kaikkia jakotietueita (vakiomuotoisia ja mukautettuja objekteja), joiden rivisyyn on määritetty manuaalinen jakaminen, voidaan muokata ja poistaa objektin sivuasettelun Jaa-painikkeella, vaikka jakotietue luotiin ohjelmallisesti.

Tiimit

Tiimi on käyttäjäryhmä, joka työskentelee yhdessä tilin, myyntimahdollisuuden tai tapauksen parissa. Tietueiden omistajat voivat laatia tiimin jokaiselle omistamalleen tietueelle. Tietueen omistaja lisää tiimin jäseniä ja määrittää käyttöoikeustason, joka jokaisella tiimin jäsenellä on tietueeseen. Joillakin tiimin jäsenillä voi olla Vain luku -oikeus, kun taas toisilla on luku/kirjoitus-oikeus.

Vain omistajat, hierarkiassa ylempänä olevat henkilöt ja pääkäyttäjät voivat lisätä tiimin jäseniä ja myöntää jäsenelle enemmän käyttöoikeuksia. Tiimin jäsen, jolla on luku-/kirjoitusoikeus, voi lisätä toisen jäsenen, jolla on jo käyttöoikeus tiimiin liittyvään tietueeseen. Tiimin jäsen ei voi myöntää heille lisäoikeutta.

Tiimin jäsenen luominen sovelluksessa luo kaksi tietuetta: tietuetietueen ja siihen liittyvän jakotietueen. Jos luot tiimin jäseniä ohjelmallisesti, sinun täytyy hallita sekä tietuetta että siihen liittyvää jakotietuetta. Tietueessa on vain yksi tiimi (Tili, Mahdollisuus tai Tapaus). Jos tarvitset useita tiimejä, harkitse aluehallintaa tai ohjelmallista jakamista, riippuen tarpeistasi.

Aluehierarkia

Kun käytät Enterprise-aluehallintaa, määrität aluehierarkian, joka näyttää mallin aluerakenteen ja toimii sen pääasiallisena vuorovaikutuspisteenä. Jos Enterprise-aluehallinta on käytössä, sinun täytyy hallita roolihierarkiaa ja aluehierarkiaa. Lisätietoja on Salesforce-ohjeen aiheessa Enterprise-aluehallinta.

Apex-hallittu jakaminen

Apex jakaminen (jota kutsutaan myös ohjelmalliseksi jakamiseksi) sallii sinun käyttää koodia laatiaksesi hienostuneita ja dynaamisia jakoasetuksia, kun tietojen käyttöoikeusvaatimuksia ei voida täyttää muilla tavoin.

Jos luot jaustietueen ohjelmallisesti ja käytät käyttövalmista rivin syytä (manuaalista jakamista), voit ylläpitää tätä jakotietuetta sovelluksen Jaa-painikkeella. Jakotietueeseen sovelletaan kaikkia sääntöjä, joilla on manuaalinen jakorivin syy, kuten poisto omistajan siirron yhteydessä.

Voit myös luoda mukautetuille objekteille omia Apex syitä seurataksesi, miksi tietue sisältää käyttäjän tai käyttäjäryhmän, ja yksinkertaistaaksesi tietueiden päivittämiseen ja poistamiseen tarvittavaa koodausta.

Lisätietoja on kohdassa Tietueen jakaminen Apexilla ennen kuin harkitset ohjelmallisen jakamisen käyttöä.

Rajoitussäännöt

Saatat haluta estää käyttäjiä näkemästä tietojen käyttöoikeuskokoonpanossasi tietueita, jotka voivat sisältää luottamuksellisia tietoja tai jotka eivät ole välttämättömiä heidän työhönsä. Voit käyttää rajoitussääntöjä salliaksesi käyttäjien käyttää vain määrittämiäsi ehtoja vastaavia tietueita. Kun käyttäjälle sovelletaan rajoitussääntöä, tietueet, joiden käyttöoikeudet käyttäjälle on myönnetty organisaationlaajuisten oletusasetusten, jakosääntöjen ja muiden jakomekanismien kautta, suodatetaan määrittämiesi ehtojen perusteella. Rajoitussäännöt toimivat vastakkaisella tavalla kuin tässä aiheessa kuvatut jakokomponentit. Sen sijaan, että ne sallisivat käyttöoikeuden käyttäjille, ne rajoittavat sitä entisestään.

Rajoitussäännöt ovat käytettävissä mukautetuille objekteille, ulkoisille objekteille, sopimuksille, tapahtumille, tehtäville, tuntilomakkeille ja tuntilomakemerkinnöille. Voit luoda enintään kaksi aktiivista rajoitussääntöä per objekti Enterprise Edition- ja Developer Edition -versioissa sekä enintään viisi aktiivista rajoitussääntöä per objekti Performance Edition- ja Unlimited Edition -versioissa. Rajoitussääntöjä sovelletaan seuraaviin Salesforce-ominaisuuksiin:

• Luettelonäkymät
• Haut
• Viiteluettelot
• Raportit
• Haku
• SOQL
• SOSL

Epäsuora jakaminen

Epäsuora jakaminen tapahtuu automaattisesti. Et voi poistaa sitä käytöstä tai ottaa sitä käyttöön — se on sovelluksen natiivi. Toisin sanoen epäsuora jakaminen ei ole määritettävä asetus, mutta kaikkien arkkitehtien on tärkeää ymmärtää se. Päätietueiden epäsuora jakaminen tarjoaa päätietueiden käyttöoikeuden (vain tili), kun käyttäjällä on käyttöoikeus tilin alitason mahdollisuuksiin, tapauksiin tai yhteyshenkilöihin. Salesforcessa on tietojen käyttöoikeuskäytäntö, joka määrittää, että jos käyttäjä näkee yhteyshenkilön (tai mahdollisuuden, tapauksen tai tilauksen), hän näkee siihen liittyvän tilin epäsuorasti. Alitason epäsuora jakaminen tarjoaa tilin omistajalle käyttöoikeuden tilin alitason tietueisiin. Tämä käyttöoikeus määritetään omistajan roolissa roolihierarkiassa. Alitason epäsuora jakaminen koskee vain yhteyshenkilö-, mahdollisuus- ja tapausobjekteja (tilin alitason objektit). Käyttöoikeustasot, jotka voidaan myöntää, ovat Tarkastele-, Muokkaa- ja Ei käyttöoikeutta jokaiselle alitason objektille, kun rooli luodaan. Kun tilin omistaja on valinnut Näytä-asetukseksi, hän näkee siihen liittyvät objektitietueet epäsuorasti (yhteyshenkilö, mahdollisuus tai tapaus). Kun tilin omistaja on määrittänyt Muokkaa, hän voi muokata siihen liittyvää objektia (yhteyshenkilö, mahdollisuus tai tapaus) epäsuorasti.

Epäsuora jakaminen ei koske mukautettuja objekteja.

Kaikkia Salesforce-organisaatioita vastaavaa jakomallia ei ole. Jokaisella organisaatiolla on erilaiset vaatimukset ja haasteet, kun yritetään rakentaa parasta jakomallia. On tärkeää käyttää sopivimpia datan käyttöoikeuskomponentteja organisaation jakoasetusten mukaisesti. Seuraavat skenaariot ovat yleisiä haasteita, kun yritetään rakentaa jakomallia.

• Mitä tapahtuu roolihierarkialle?

  • Roolihierarkialle ei tapahdu mitään, jos käytät myös aluehierarkiaa. Jos kuitenkin käytät sekä alueisiin perustuvaa ennustamista että rooleihin perustuvaa ennustamista yhdessä, sinun täytyy hallita kahta hierarkiaa. Tässä tapauksessa suosittelemme, että käytät roolihierarkiaa HR-raportointirakenteen mallinnukseen ja sitten aluhierarkiaa todellisen myyntihierarkian mallinnukseen. Aluehierarkia soveltuu parhaiten matriisiraporttien rakenteen mallinnukseen, jossa joku voi raportoida useille esimiehille.

    Jos et käytä aluepohjaista ennustamista ja rooleihin perustuvaa ennustamista yhdessä, voit käyttää myyntihierarkiana vain aluehierarkiaa. Tässä skenaariossa on parasta yksinkertaistaa hierarkiaa tai litistää sitä mahdollisimman tarkasti.

    Emme suosittele tekemään roolihierarkiaa ja aluehierarkiaa identtisinä, koska se aiheuttaa tarpeettomia jakotoimintoja.

• Voitko yhä käyttää tiimejä?

  • Kyllä. Jos kuitenkin voit täyttää käyttöoikeusvaatimuksesi aluehierarkiassa (kuten peittokuvioissa), on parempi tehdä se siellä kuin käyttää tiimejä. Olet jo ylläpitänyt useita hierarkioita (roolit ja alueet), joten kun yrität pitää asiat mahdollisimman yksinkertaisina, toteuta tiimisi vain, jos mikään muu jakokomponentti ei täytä vaatimusta.

• Uudelleenkohdistus ja uudelleenkohdistus

  • On kahdentyyppisiä muutoksia – roolien, tiimien tai alueiden jäsenyys ja hierarkian rakenne. Jäsenyyksien muutokset voivat tapahtua tavallisesti päivittäin, jopa tunneittain. Hierarkian rakenteiden (uudelleenkohdistusten) muutokset tapahtuvat tavallisesti harvemmin (neljännesvuosittain, puolivuosittain tai vuosittain) ja ne voivat olla resurssien kalliita. Sinun täytyy ottaa huomioon muutosten määrä ja kunkin muutoksen aiheuttamien muutosten määrä. Suosittelemme, että rakenteelliset muutokset tapahtuvat enintään neljännesvuosittain ja että kaikki suuret muutokset (joukko- tai joukkomuutokset) on suunniteltu, testattu ja koordinoitu hyvin.

• Suuri määrä dataa

  • Olitpa mallinnamassa alustavaa julkaisua varten tai suunnittelemassa uudelleenkohdistuksen muutosta, sinun täytyy ottaa datan määrä vakavasti huomioon. On olemassa kynnysarvoja, joissa suorituskyky voi olla tärkeä tekijä, joten on erittäin suositeltavaa testata muutoksesi sandboxissa ennen tuotantoympäristöä. Tämä testaus antaa sinulle myös perustason siitä, kuinka kauan muutos kestää.

    Jos sinulla on yli kaksi miljoonaa tiliä ja olet ottanut käyttöön tiimejä tai Enterprise-aluehallintaa, sinun on kiinnitettävä erityistä huomiota suorituskykyyn. Nämä ovat monimutkaisia jakomallien komponentteja, jotka voivat luoda valtavan määrän jakotietueita ja siten pitkäaikaisia transaktioita.

• Jakolaskentojen lykkääminen

  • Jos sinulla on jakamista hyödyntävä objekti ja sillä on paljon tietueita (kuten yli kaksi miljoonaa tiliä) ja sinun täytyy tehdä joukkomuutos (kuten neljännesvuosittainen uudelleenkohdistus, joka vaatii hierarkian muutoksen), Salesforce-asiakastuki voi ottaa käyttöön ominaisuuden, joka lykkää automaattisten jakojen laskutoimia. Jokainen yksittäinen roolihierarkian, aluehierarkian, ryhmien, jakosääntöjen, käyttäjäroolien, tiimin jäsenyyden tai tietueiden omistajuuden muutos voi käynnistää automaattisia jakotietojen laskutoimia. Kun joukkomuutos tehdään, se käynnistää useita automaattisia jakamisen uudelleenlaskentoja. Jos keskeytät nämä uudelleenlaskennat väliaikaisesti, voit tehdä muutoksen ja tehdä jakolaskutoimet kerralla. Tämä menetelmä on tavallisesti tehokkaampi ja toimii paremmin joukkomuutoksille.

• Datan ja omistajuuden kaaviot

  • Datavirheet määritetään muutamaksi ylätason tietueeksi, joilla on useita alitason tietueita. Nämä vääristymät voivat todella vahingoittaa sinua, kun joillakin tileillä on useita yhteyshenkilöitä, mahdollisuuksia tai tapauksia. Suhde, josta näemme suorituskyvyn heikentymisen, on 1:10 000. Suosittelemme pitämään suhteen mahdollisimman lähellä sitä (pienempi on suositeltavaa).

    Omistajien vääristymät muistuttavat datan vääristymää, paitsi että viittaamme yhteen käyttäjään, rooliin tai ryhmään, joka omistaa useita objektin tietueita. Tietovirheiden tapaan ne voivat myös aiheuttaa pitkäaikaisia transaktioita, mikä heikentää suorituskykyä muutoksen yhteydessä. Myös omistajan ja tietueiden määrän suositeltu suhde on 1:10 000.

    Jos yksi käyttäjä omistaa yli 10 000 tietuetta, suosittelemme seuraavaa:

    • Omistajan käyttäjätietueella ei tulisi olla roolihierarkiassa.

    • Jos omistajan käyttäjätietueella täytyy olla rooli, aseta rooli hierarkian ylälaitaan roolihierarkian omassa haarassaan.

• Tilihierarkian vaikutus tietojen käyttöoikeuksiin

  • Monet ihmiset tekevät huonoja oletuksia toteuttaessaan tilihierarkiaa. He olettavat, että käyttäjät, joilla on päätilin käyttöoikeus, voivat myös käyttää alitason tilejä. Yksinkertainen seikka, että kahden tietueen välillä on vain ylätaso- ja alataso-suhde, ei vaikuta käyttöoikeuksiin. Vaikka roolihierarkia ja aluehierarkia toimivat tällä tavalla, tilihierarkia ei toimi.

Kun olet suorittanut jakomallin arkkitehtuurisi, saatat miettiä, miksi käyttäjä voi tai ei voi nähdä tietuetta. Tavallisesti et kuule, milloin käyttäjät näkevät jotain, mitä heidän ei tulisi nähdä, mutta tarvittaessa voit nähdä kaikki käyttäjät, joilla on tietueen käyttöoikeus ja miksi.

Monimutkaisempi ja todennäköisesti yleisempi ongelma on, miksi käyttäjä ei näe tietuetta. Arkkitehtisi suojauskerrokset määrittävät mistä aloitat. Jos tunnet jakomallin hyvin, tiedät todennäköisesti, mikä komponentti olisi antanut käyttöoikeuden ja voi aloittaa siitä. Jos jakomalli ei kuitenkaan ole sinulle tuttu, aloita roolihierarkiasta ja irrota jokainen kerros määrittääksesi, kumpi niistä tarjoaa käyttöoikeuden. Alla on vianmäärityskulku.

1. Varmista, että käyttäjällä on objektin käyttöoikeudet.
2. Tunnista käyttäjän rooli, joka ei näe tietuetta, ja huomioi se.
3. Tunnista tietueen roolin omistaja ja huomioi se.
4. Tarkasta roolihierarkia ja varmista, että nämä kaksi roolia ovat kahdessa eri haarassa (niiden tulisi olla).
5. Nyt sinun täytyy tarkastaa objektin jakosäännöt ja varmistaa, ettei käyttäjälle myönnä käyttöoikeutta. Hae tarvittaessa myös julkisia ryhmiä. Ehkä käyttäjä jätettiin pois ryhmästä, jossa on jakosääntö, tai onko järkevää luoda uusi jakosääntö myöntääkseen käyttäjälle käyttöoikeuden? Tämä valinta riippuu ylläpidettävästä arkkitehtuurista ja koskee sekä omistajiin perustuvia jakosääntöjä että ehtoihin perustuvia jakosääntöjä.
6. Jos käytät tiimejä, tulisiko tämän käyttäjän kuulua tietueen tiimiin? Miten tiimit ylläpidetään ja miten virhe tapahtui?
7. Jos manuaalista jakamista käytetään, käyttäjä on saattanut menettää käyttöoikeutensa, koska tietueen omistaja on muuttunut. Manuaaliset jaot jätetään pois, kun omistajuus muuttuu. Manuaalinen jako olisi voitu poistaa myös käyttämällä Jaa-painiketta.
8. Jos käytät Enterprise-aluehallintaa, puuttuuko käyttäjä jostakin alueesta? Missä alueiden jäsenyyksiä säilytetään ja miten virhe tapahtui? Tai ehkä tietuetta ei ole kohdistettu alueeseen, jossa käyttäjä on jäsenenä.
9. Jos olet luomassa ohjelmallisia jakoja ja koodissa on ehtoja jakojen luomiseksi, tarkasta koodi ymmärtääksesi, miksi tätä käyttäjää jätettiin pois.