Valitse oikea objekti

🌐 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 5/10 luvussa Salesforcen tietoarkkitehtuuri, Data Architect -kurssin luku 3. Jokainen moduuli on itsenäinen. Edellinen: Missä nämä tiedot asuvat? · Seuraava: Kentätkin ovat arkkitehtuuria

Kysymys, johon tämä moduuli vastaa: Millaiseksi Salesforce-objektiksi tämän liiketoimintakäsitteen pitäisi tulla, ja mitä lisenssit sallivat?

Yksi Salesforcen helpoimmista asioista on mukautetun objektin luominen. Juuri siksi luulen, että luomme niitä liikaa.

Olet vaatimuspalaverissa, ja joku sanoo: ”Meidän pitää seurata jakelijoitamme.” Uusi mukautettu objekti: Distributor. Valmis. Paitsi että haluan arkkitehdin kysyvän ensin toisen kysymyksen: mikä jakelija on? Se on yritys. Salesforcessa on jo aika hyvä tapa kuvata yritys. Sen nimi on tili (Account). Se ei tarkoita, että vastaus on aina tili. Mutta jos minun pitää selittää, miksi yritys ei ole tili, haluan paremman syyn kuin ”liiketoiminta kutsuu niitä jakelijoiksi”.

Tässä luvun 2 looginen malli kohtaa alustan, ja lähtökohtani on yksinkertainen: jos liiketoimintakäsite sopii puhtaasti vakio-objektin käyttötarkoitukseen, aloita siitä.

Aloita merkityksestä

Vaikka jokin ansaitsisi olla objekti, se ei automaattisesti ansaitse olla mukautettu objekti. Kysy, mitä asia oikeasti edustaa. Minkä tahansa muotoista yritystä tai organisaatiota? Aloita tilistä. Henkilöä, joka työskentelee sen organisaation kanssa? Yhteyshenkilö (Contact). Jotain, minkä asiakas omistaa tai on ostanut? Omaisuuserä (Asset). Jotain, mitä yrität myydä? Nyt myyntimahdollisuus (Opportunity) kuuluu keskusteluun.

Siksi katsoimme ensin emoalukseen, moduulissa 2. Nuo mallit eivät sovi jokaiseen liiketoimintaan, mutta meidän ei pitäisi sivuuttaa niitä vain siksi, että oman rakentaminen tuntuu siistimmältä. Ennen New Custom Objectia kysy, miten Salesforce mallintaa tämän käsitteen, mitä sen mallin ympärille on rakennettu ja mistä luopuisit korvaamalla sen.

Puhtaan sopivuuden testi

Testini on yksi kysymys: sopiiko tämä liiketoimintakäsite puhtaasti vakio-objektin käyttötarkoitukseen? Jos sopii, kallistun vakio-objektiin.

Jakelija on yritys, jonka kanssa meillä on suhde, joten tili sopii puhtaasti. Minua ei haittaa, että käyttäjät kutsuvat yhtä yritystä jakelijaksi, toista toimittajaksi, kolmatta vähittäiskauppakumppaniksi ja neljättä asiakkaaksi. Ne ovat liiketoimintarooleja, eivätkä ne tarvitse neljää fyysistä objektia. Eri liiketoimintanimet eivät automaattisesti tarkoita eri tietorakenteita. Tyyppi, tietuetyyppi tai suhde voi kantaa eron.

Testi toimii myös toiseen suuntaan. Luvussa 1 jätin sinulle kysymyksen: asiakkaan liiketoiminnalla on monta toimituspaikkaa. Pitäisikö jokaisen toimipaikan olla tili vai mukautettu objekti?

Tili antaa paljon. Saat osoitekentät ja kaiken, mikä jo odottaa tilin osoitetta: raportit, kartat, integraatiot. Mutta saat myös kuorman: paljon kenttiä, jakamisen, hierarkian, omistajuuden, kaiken, mikä tiliin kiinnittyy, ja suurin osa siitä ei ole olennaista erilliselle osoitteelle. Kantaisit paljon raskaita asioita, joita et käytä, vain vaihtoehtoisen osoitteen takia.

Mukautettu objekti, tilin lapsi, voi olla kevyt: vain osoitekentät, paikka, johon toimitamme, omalla elinkaarellaan, jota voin hallita itsenäisesti.

Se on siis tasapainoilua: kuorma, jonka otat kannettavaksi, vastaan arvo, jonka saat. Jos tarvitsen vain osoitteen omalla elinkaarellaan, silloin valitsen mukautetun.

Sama pätee tapauksen alaongelmiin. Jos jokainen alaongelma todella on tapaus, jota agentti työstää ja jolla on oma tilansa ja palvelutasonsa, sijoita ne sisäkkäin moduulin 2 Parent Case -kentän avulla. Mutta jos se on vain tarkistuslistan kohta, jota kukaan ei työstä tapauksena, täysi tapaus kantaa paljon sellaista, mitä se ei koskaan käytä, ja yksinkertainen mukautettu lapsiobjekti voi painaa vähemmän. Ei siksi, että mukautettu olisi siistimpi. Vaan koska merkitys on eri, tai paino on väärä.

Vakio-objekteilla on matkatavaransa

Kun valitset vakio-objektin, valitset enemmän kuin sen kentät. Valitset jotain, minkä Salesforcen tuotteet jo ymmärtävät: raportoinnin, automaation, sisäänrakennetut suhteet, tuoteominaisuudet, AppExchange-paketit ja kaiken, mitä Salesforce seuraavaksi rakentaa. Se voi olla valtavan arvokasta.

Vakio-objekteilla on myös mielipiteensä: olemassa oleva toiminta, suhteet, suojausnäkökohdat, joskus lisenssivaatimukset ja ominaisuudet, joita et tarvitse. Joten ”käytä aina vakio-objekteja” ei ole sääntöni. Minulla ei ole ”aina”-sääntöä. Minulla on taipumus: käytä vakio-objektia, kun merkitys sopii puhtaasti ja sen ympärillä oleva alustan toiminta auttaa suunnitelmaa eikä taistele sitä vastaan. Jos käytän viisi vuotta saadakseni myyntimahdollisuuden käyttäytymään kuin jokin, mikä ei ole myyntimahdollisuus, en ole hyötynyt mitään pysymällä vakio-objektissa. Olen vain tehnyt väärän kompromissin toiseen suuntaan.

Omaisuuserä on hyvä esimerkki

Omaisuuserä (Asset) on yksi vakio-objekteista, jotka ihmiset unohtavat. Yksinkertaisimmin sanottuna: se on asia, joka asiakkaalla on. Ehkä he ostivat sen meiltä, ehkä eivät. Välitän silti kilpailijan tuotteesta, joka on asiakkaani tiloissa, koska huollan sitä tai yritän korvata sen tai minun on ymmärrettävä heidän asennettu laitekantansa. Jos luon Customer_Product__c-objektin katsomatta ensin omaisuuserää, olen ohittanut arkkitehtuurikysymyksen. Omaisuuserä ei automaattisesti voita, mutta se ansaitsee tulla arvioiduksi.

Henkilötilit: milloin henkilö on tili?

Moduulissa 2 tutustuimme henkilötileihin: tili ja yhteyshenkilö yhdessä tietueessa asiakkaille, jotka ovat yksityishenkilöitä. Nyt päätös.

Kantani: B2C:ssä niitä ilman on vaikea pärjätä. Tilien ja yhteyshenkilöiden mukana tulee valmiina niin paljon, että kustannus ja kuorma ovat sen arvoisia. Ja kustannus on olemassa: noin kaksinkertainen tallennustila yritystiliin verrattuna, kytkin, jota ei voi kääntää pois, ja jotkin ulkoiset lisenssit eivät voi käyttää niitä. Partner Communitya ei voi käyttää henkilötilien kanssa (Experience Cloud User Licenses (opens in a new tab)). Kysymys ei siis ole ”onko tietokannassamme ihmisiä?” Jokaisessa orgissa on ihmisiä. Kysymys on ”onko henkilö todella tili tässä liiketoiminnassa?” Se, että yhteyshenkilö on ihminen, ei tee siitä henkilötiliä. Liiketoimintasuhde tekee.

Click to enlarge

Ja nyt monimutkaistan kaiken: lisensointi

Tähän asti: löydä käsite, etsi puhtain vakio-objektivastine, valitse mukautettu, kun merkitys ei sovi. Nyt arkkitehdin jatkokysymys: kenen pitää käyttää sitä? Voit suunnitella kauniin mallin ja sitten huomata, että puolella tietoja tarvitsevista ihmisistä ei ole lisenssiä valitsemiisi objekteihin. Lisenssit ovat osa tietomallia.

Kolme sisäistä lisenssiä

Aloita omista ihmisistäsi. Yrityksen sisällä on kolme lisenssityyppiä, jotka haluan jokaisen arkkitehdin osaavan ulkoa, koska ne määräävät, mitä kukin käyttäjä voi nähdä ja tehdä, ja siten sen, mihin tietomallisi voi luottaa.

Sales Cloud (nykyään Agentforce Sales). Näillä käyttäjillä on täysi Salesforce-käyttäjälisenssi: CRM:n vakio-objektit ja mikä tahansa vakio- tai mukautettu sovellus. Se tarkoittaa liidejä, myyntimahdollisuuksia ja ennusteita tilien ja yhteyshenkilöiden lisäksi, ja jopa tapauksia: myyjä voi nähdä asiakkaan avoimet tapaukset ennen puhelua. Kampanjoiden luominen ja ajaminen vaatii yhden palan lisää, Marketing User -ominaisuuslisenssin.

Service Cloud (nykyään Agentforce Service). Sama Salesforce-käyttäjälisenssi palvelua varten määritettynä. Tapaukset ovat keskiössä, ja niitä työstetään Service Consolessa: Service Cloud User -ominaisuuslisenssi avaa Salesforce Console for Servicen. Täällä asuvat palvelutasosopimukset (SLA) oikeutusten hallinnan (entitlement management) ja virstanpylväiden (milestones) kautta, ja tänne tulee Knowledge, jonka useimmat versiot ostavat lisäosana.

Platform (Salesforce Platform). Ihmisille, jotka tarvitsevat mukautettuja sovelluksiasi, eivät CRM:ää. He saavat tilit, yhteyshenkilöt, raportit, koontinäytöt, asiakirjat ja jokaisen orgin mukautetun sovelluksen. Mitä he eivät saa: ennusteet, liidit, kampanjat ja myyntimahdollisuudet. Se maksaa vähemmän, ja juuri siksi niin monet suuret mukautetut sovellukset pyörivät sillä, ja juuri siksi se voi yllättää tietomallisi.

	Sales Cloud	Service Cloud	Platform
Käyttäjälisenssi	Salesforce	Salesforce	Salesforce Platform
Tehty	Myyntiin	Asiakkaiden tukemiseen	Mukautettuihin sovelluksiin
Tilit, yhteyshenkilöt	Kyllä	Kyllä	Kyllä
Liidit, myyntimahdollisuudet, ennusteet	Kyllä	Kyllä	Ei
Tapaukset	Kyllä, asiakkaan tapausten näkemiseen	Keskiössä, Service Consolessa	Ei
Palvelutasosopimukset	Ei	Kyllä, oikeutukset ja virstanpylväät	Ei
Mukautetut objektit ja sovellukset	Kyllä	Kyllä	Kyllä

Lue taulukko niin kuin arkkitehti lukee. Jos suuri käyttäjäryhmä on Platform-lisenssillä, jokainen suunnitelma, joka sijoittaa heidän työnsä myyntimahdollisuuteen, on rikki jo ennen kuin se alkaa. Jos johtajat tarvitsevat SLA-lukuja, heidän lisenssinsä ratkaisee, näkevätkö he ne. Nämä kolme tyyppiä ohjaavat toimintaa.

Click to enlarge

Kun lisenssi päättää objektin

Myyntimahdollisuus on uhri, johon olen törmännyt useimmin. Näit sen taulukossa: Platform-käyttäjät eivät saa sitä (Standard User Licenses (opens in a new tab)), eivätkä Customer Community -käyttäjätkään voi käsitellä sitä. Vaatimus siis näyttää myyntimahdollisuudelta, joku sanoo ”käytetään myyntimahdollisuutta”, ja sitten kysyn, kuka tarvitsee pääsyn. Jos suuri joukko on Platform- tai Customer Community -lisensseillä, lisenssi ei ole enää hankintayksityiskohta. Se on arkkitehtuurinen rajoite, ja se yleensä työntää suunnitelman kohti mukautettua objektia.

Se toimii myös ylöspäin. Kysyn kurssilla: toimitusjohtaja haluaa nättejä koontinäyttöjä; Sales-lisenssi vai Service? Sales-käyttäjä näkee myyntiobjektit ja jopa tapaukset, joten myynnin koontinäyttöihin ja avointen tapausten määriin Sales riittää. Mutta heti kun johtaja haluaa SLA-mittareita (kuinka kauan siihen, että tapaus rikkoo palvelutasonsa), ne tiedot ovat oikeutuksissa ja virstanpylväissä, ja oikeutusten hallinta vaatii Agentforce Servicen, entisen Service Cloudin (Supported Editions for Service Features (opens in a new tab)). Nyt päivität johtajien lisenssejä. Kuuntele liiketoiminnan vaatimusta ja tiedä, mikä lisenssi on sen tarvitsemien tietojen alla.

Stadion

Ajattelen lisenssejä stadionin istumapaikkoina. Kaikki katsovat samaa peliä. Jos ostan kalliit paikat keskeltä, näen molemmat joukkueet läheltä. Jos olen ylhäällä nurkan katsomossa, istuimet eivät ole pehmustettuja ja katson peliä kiikareilla.

Ne ovat ulkoisia lisenssejä yrityksen ulkopuolisille ihmisille: asiakkaille ja kumppaneille, jotka kirjautuvat Experience Cloud -sivustolle. Haluan sinun tuntevan kolme.

Customer Community: nurkkakatsomo. Tehty suurille määrille ulkoisia käyttäjiä, jotka tarvitsevat tapauksia ja tietämystä: asiakas, joka tarkistaa tukitapauksensa tilanteen. Paikat maksavat noin puolet ja voivat mennä valtaville käyttäjämäärille. Mitä siellä ylhäällä menetät? Raportit, koontinäytöt ja jakotaulun (share table): roolipohjaisen jakamisen, jonka ylemmät tasot saavat. Se toimii henkilötilien kanssa.

Customer Community Plus: noin puolivälissä alaspäin. Salesforce kuvaa sitä lisenssiksi ulkoisille käyttäjille, jotka tarvitsevat raportteja ja koontinäyttöjä sekä vakiojakamista: asiakas, joka hallitsee muiden ihmisten pääsyä tai jonka pitää nähdä omat lukunsa.

Partner Community: vielä lähempänä, yritysten väliseen (B2B) toimintaan, pääsy myyntitietoihin. Kumppanit työstävät liidejä ja myyntimahdollisuuksia: he rekisteröivät kauppoja ja ajavat kampanjoita kanssasi. Se on ulkoinen paikka, joka ylettyy myyntiobjekteihin. Yksi koukku: sitä ei voi käyttää henkilötilien kanssa (Experience Cloud User Licenses (opens in a new tab)).

Click to enlarge

Virhe on suunnitella ikään kuin kaikilla olisi kallis lippu ja huomata toteutuksessa, että suurin osa käyttäjistäsi ei pääse siihen katsomon osaan, johon sijoitit heidän tietonsa. Silloin sinulla on kolme vaihtoehtoa: osta eri paikat, siirrä käyttökokemus tai suunnittele malli uudelleen. Kaikki kolme ovat arkkitehtuuria.

Maksutapa muuttaa suunnitelmaa

On toinenkin kysymys, jonka ihmiset unohtavat: miten nämä käyttäjät kirjautuvat? Ulkoisia lisenssejä on kahta muotoa. Jäsenpohjainen (member-based): maksat käyttäjää kohden, mikä sopii 500 kumppanille, jotka kirjautuvat joka päivä. Kirjautumispohjainen (login-based): ostat tietyn määrän kirjautumisia kuukaudessa, mikä sopii viidelle miljoonalle asiakkaalle, jotka kirjautuvat muutaman kerran vuodessa. Useampi kirjautuminen samana päivänä lasketaan silti yhdeksi kirjautumiseksi (Experience Cloud User Licenses (opens in a new tab)).

Joten kun joku sanoo ”rakennamme asiakasportaalia”, seuraava kysymykseni ei ole, mikä pohja. Se on: keitä asiakkaat ovat, kuinka monta heitä on, kuinka usein he tulevat, mitä tietoja he tarvitsevat ja mitä he saavat niillä tehdä?

Kun lisenssi muovaa mallia

Joskus lisenssi ei vain valitse objektia; se taivuttaa koko mallin. Jotkin Platform-lisenssit rajoittavat käyttäjät yhteen mukautettuun sovellukseen, jossa on enintään kymmenen mukautettua objektia (esimerkiksi Lightning Platform – One App; Standard User Licenses (opens in a new tab)).

Eräässä varhaisessa projektissa suurelle asiantuntijapalvelu- ja rakennusyritykselle meidän piti rakentaa jotain LinkedInin kaltaista koko henkilöstölle: jokaisen työtehtävät, taidot, sertifikaatit, kielet ja projektit, jotta he löytäisivät sillanrakentajan, jolla on sertifikaatti tietyssä maassa. Ilman rajaa olisin rakentanut käyttäjä–työtehtävä-, käyttäjä–taito-, käyttäjä–sertifikaatti-, käyttäjä–kieli- ja käyttäjä–projekti-objektit sekä viiteluettelot sertifikaateista ja projekteista. Kymmenen objektin lisenssillä, ja kun oli käsketty olemaan käyttämättä niitä kaikkia, se ei ollut mahdollista. Siitä tuli arvaa sävelmä -peli: kuinka vähillä objekteilla voin rakentaa tämän? Vastaus oli kaksi. Yksi viiteobjekti (reference object), jossa on tietuetyyppi kullekin luettelolajille (työtehtävä, taito, sertifikaatti, kieli, projekti), ja yksi käyttäjäattribuutti-objekti vastaavine tietuetyyppeineen, joka osoittaa siihen.

Se ei ollut optimaalinen malli. Siitä oli tuskallista raportoida, ja olisin halunnut sen siistimmäksi. Mutta sen lisenssi salli. Kutsun näitä linkkuveitsiobjekteiksi (Swiss army knife objects): pidä malli takataskussasi, ja kun rajat eivät jätä tilaa, riko lasi hätätilanteessa ja turvaudu tietuetyyppien erotteluun. Tiedä vain, mitä vaihdat. Eri käyttöoikeudet eri tietuetyypeille voivat pakottaa sinut jakamaan objektin joka tapauksessa.

Ihmiset eivät ole enää ainoita käyttäjiä

Yksi lisensointikysymys lisää on noussut tärkeäksi: entä asiat, jotka eivät ole ihmisiä? Integraatioilla on identiteetit. Agenteilla on identiteetit. Salesforcella on nyt Salesforce Integration -lisenssi järjestelmien välisille integraatioille: pelkkä API, ei ihmisille, ja viisi sisältyy jokaiseen Enterprise-, Unlimited- ja Performance Edition -orgiin (Standard User Licenses (opens in a new tab)). Älä siis kysy vain, mitkä käyttäjät tarvitsevat pääsyn. Kysy, mitkä identiteetit tarvitsevat pääsyn: henkilö, asiakas, kumppani, integraatio, agentti. Ja sitten, mitä kunkin pitää nähdä ja tehdä.

Kokeen jälkeen: mitä tekoäly muuttaa. Kun agenteista tulee yksi tietojen kuluttaja ja luoja lisää, objektin valinta ja lisensointi eivät koske vain ihmisten näkymiä. Tiedä, minkä identiteetin alla agentti toimii, mihin se identiteetti ylettyy ja sijoittaako malli agentin tarvitsemat tiedot objektin tai käyttöoikeuden taakse, jota se ei voi käyttää.

Steve Trucking: yksi helppo ja yksi vaikea

Steve Trucking tekee yhteistyötä vähittäiskauppakumppanien (Retail Partner) kanssa. Mikä vähittäiskauppakumppani on? Yritys. Helppoa: tili. En luo Retail_Partner__c-objektia sen takia, että joku käytti sanaa ”kumppani”.

Sitten vastaanottaja (Recipient), henkilö, joka vastaanottaa jääkaapin. Yhteyshenkilö? Henkilötili? Jotain muuta? Miljoona uutta vastaanottajaa vuodessa, ja he ovat vähittäiskauppakumppanien asiakkaita, eivät meidän. Juuri tällaisessa kysymyksessä en halua hypätä objektiin ennen kuin ymmärrän suhteen, pääsyn ja mittakaavan. Päätämme sen osan 1 tarkistuspisteessä.

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

• Sopiiko liiketoimintakäsite puhtaasti vakio-objektin käyttötarkoitukseen, vai onko sen merkitys tai paino eri.
• Ovatko eri liiketoimintanimet eri entiteettejä vai vain saman entiteetin eri rooleja.
• Pääseekö jokainen tietoja tarvitseva henkilö, ulkoinen käyttäjä, integraatio ja agentti valittuun objektiin suunnitelluilla lisensseillä.
• Miten käyttäjäjoukko ja kirjautumistapa (jäsenpohjainen tai kirjautumispohjainen) muovaavat lisenssiä ja mallia.
• Milloin lisenssiraja oikeuttaa vähemmän kuin optimaalisen mallin, ja mitä se vaihtokauppa maksaa raportoinnissa ja käyttöoikeuksissa.

Pointti ei ole se, että vakio-objektit ovat hyviä ja mukautetut objektit huonoja. Pointti on, että valinnalla on seurauksia, eikä sitä joskus ratkaise substantiivi lainkaan, vaan ihmiset ja koneet, joiden pitää käyttää sitä.

Lue lisää

• Salesforce Help, Standard User Licenses (opens in a new tab), englanniksi, tarkistettu 2026-10-02, tarkistettu uudelleen 2026-10-12: Platform-käyttäjät eivät ole oikeutettuja ennusteisiin, liideihin, kampanjoihin ja myyntimahdollisuuksiin; yksi mukautettu sovellus, jossa on enintään 10 mukautettua objektia; viisi Salesforce Integration -lisenssiä jokaisessa Enterprise Edition -orgissa.
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab), englanniksi, tarkistettu 2026-10-02, tarkistettu uudelleen 2026-10-12: Partner Communitya ei voi käyttää henkilötilien kanssa; Customer Community Plus raportteja, koontinäyttöjä ja vakiojakamista varten; useampi kirjautuminen päivässä lasketaan yhdeksi.
• Salesforce Help, Supported Editions for Service Features (opens in a new tab), englanniksi, tarkistettu 2026-10-02, tarkistettu uudelleen 2026-10-12: palvelutasosopimukset (oikeutusten hallinta) Agentforce Servicen kanssa; Knowledge on lisäkustannus useimmissa versioissa.
• Salesforce Help, Available Feature Licenses (opens in a new tab), englanniksi, tarkistettu 2026-10-12: Service Cloud User, pääsy Salesforce Console for Serviceen (”Access the Salesforce Console for Service”); Marketing User kampanjoiden luomiseen ja hallintaan.