Data 360-klargjøring

Salesforce Data 360 er en dataplattform bygget på Hyperforce som forener Salesforce-data og eksterne data til en klar, fullstendig og klar 360-graders visning av hver kunde eller konto.

Virksomheter driver ofte flere Salesforce-organisasjoner på grunn av flettinger og oppkjøp, regionale operasjoner, funksjonell separasjon eller av historiske årsaker. Arkitekter har flere beslutninger om Data 360 å ta, som alle påvirker styring, samsvar, kostnader, latens og organisasjonens mulighet til å skalere AI og plattformfunksjoner for flere organisasjoner.

Denne veiledningen gir et rammeverk for å ta klargjøringsbeslutninger med Data 360. Disse beslutningene inkluderer følgende:

• Velge en enkelt hjemmeorganisasjon kontra en konfigurasjon for flere organisasjoner

• Klargjøring av flere uavhengige Data 360-forekomster

  • Bruke Data Cloud One til å forene organisasjoner under én enkelt forekomst

  • Samarbeide mellom uavhengige Data 360-forekomster som bruker datadeling mellom Data 360-organisasjoner

Data 360 klargjøres automatisk i alle produksjonsorganisasjoner som mottar en Data 360-lisens. Data Cloud One er Salesforces tilkoblingsarkitektur for flere organisasjoner som tillater at en enkelt hjemmeorganisasjon er vert for Data 360-forekomsten, mens andre Salesforce-organisasjoner kobler til som tilhørende organisasjoner. Valget av hvilken organisasjon som skal inneholde Data 360-lisensen og dermed bli en Data 360-hjemmeorganisasjon, er en viktig arkitektonisk beslutning med langsiktige konsekvenser.

Hvordan du klargjør Salesforce Data 360 er en grunnleggende arkitektonisk beslutning. Det bestemmer hvordan virksomheten forener kundedata, håndhever styring og aktiverer viktige plattformfunksjoner, spesielt AI, Agentforce og analyse i hele organisasjonen. Ankering av en klynge av organisasjoner til en enkelt Data 360 gir en forent datamodell, sentralisert styring og muliggjør foretaksomfattende AI-klargjøring. Samleorganisasjoner kan få tilgang til delte metadata og funksjoner som om dataene var lokale. Til forskjell er flere uavhengige Data 360-forekomster passende når krav til forskrifter, samsvar eller autonomi hindrer sentralisering. Datadeling mellom Data 360-organisasjoner aktiverer selektiv, null-kopi-samarbeid mellom disse forekomstene.

Denne beslutningen påvirker hvem som styrer datastyringen, hvor data befinner seg, hvordan plattformfunksjoner aktiveres, og hvor problemfrit fremtidige integrasjoner og AI-initiativer kan skaleres. Selv for organisasjoner som for øyeblikket ikke har Data 360, kan det være viktig å sikre fremtidssikre arkitekturer ved å utvikle en strategi for å legge til Data 360-tilgang fremover. I økende grad bygger Salesforce-funksjoner på tvers av salg, service, markedsføring, handel, bransjer og Agentforce på Data 360. Organisasjoner som ønsker å bruke disse plattformfunksjonene, må klargjøre sine egne Data 360-funksjoner eller koble til en delt Data 360-organisasjon som medfølgende organisasjoner.

Denne veiledningen hjelper arkitekter med å utforme en klargjøringsstrategi som balanserer enkelhet, konsistens for hele virksomheten, samsvar og skalerbarhet, slik at organisasjonen trygt kan utnytte Data 360 for Customer 360, AI og innovasjon på tvers av plattformer. Bruk denne veiledningen til å finne ut hvilke organisasjoner som krever Data 360, og om du skal bruke Data Cloud One eller datadeling mellom Data 360-organisasjoner. Denne strategien etablerer et solid grunnlag for en Data 360-sentrert fremtid.

Salesforce Data 360 er Salesforces sanntids, hyperskalerte dataplattform som harmoniserer og forener data fra hvilken som helst kilde (CRM, nett, mobile eller eksterne datasjøer) til en enkelt kundeprofil som kan handles. Som en viktig del av Customer 360-plattformen gir den AI, analyse og tilpassede opplevelser på tvers av salg, service og markedsføring.

• Alle organisasjoner bør planlegge tilgang til en Data 360-forekomst. Hver organisasjon må være vert for en Data 360-hjemmeorganisasjon eller være en tilhørende organisasjon tilkoblet via Data Cloud One.

• Tenk i hele virksomheten, ikke organisasjon for organisasjon. Unngå ensidige forretningsbeslutninger som tas isolert. Ideelt sett bør en virksomhetens arkitektur eller datastyringsråd kollektivt bestemme klargjøringsstrategien. Forutse alltid fremtidige behov for AI og analyse, som avhenger av brede, forente datasett.

• Planlegg styring og eierskap tidlig. Bestem om du vil behandle Data 360 sentralt (Center of Excellence-modellen) eller delegert til forretningsområder. Definer roller for administratorer, sikkerhetsteam og samsvarssalgsemner. Unngå tvetydighet fordi uklar eierskap kan være problematisk.

• Husk at klargjøring er knyttet til lisensiering. Organisasjonen der Data 360-lisensen kjøpes, bestemmer hvor Data 360 klargjøres, og organisasjonens plassering bestemmer området.

• Forstå viktige punkter om støtte for datakilder. Vær oppmerksom på hvilke områder som støttes for ulike offentlige skyer og datakilder med null kopiering. Finn også ut om privat tilkobling kreves for at sikkerhetstilstanden skal kunne koble til disse datakildene, og om tilkoblinger i områder eller på tvers av områder støttes.

• Klargjøring basert på om du har en enkeltorganisasjon eller en flerorganisasjon. For enkeltorganisasjonskunder klargjør du Data 360 i din eksisterende produksjonsorganisasjon for å få raskest tid til verdi. For kunder med flere organisasjoner minimerer du kompleksiteten ved å opprette et minimum av Data 360-forekomster, ideelt sett ved å bruke Data Cloud One-konfigurasjon.

• Bruk flere Data 360-forekomster bare når det er nødvendig. Flere forekomster bør brukes bare når det kreves av samsvar, opphold eller organisasjonsavhengighet. I disse tilfellene bruker du datadeling mellom Data 360-organisasjoner for å aktivere sikkert samarbeid.

• Konfigurer datadeling mellom Data 360-organisasjoner for samarbeid, ikke for tilpassede ETL pipelines. Del bestemte objekter (DMO-er, beregnede innsikter, segmenter) via datadeling. Husk at koder ikke deles, og forbruk faktureres til kildeorganisasjonen.

• Unngå kortsiktige snarveier. Ikke roter opp flere Data 360-organisasjoner for å få bevis på konsepter (POC-er) uten en langsiktig plan. Juster pilotprogrammer og tidlige distribusjoner til den bedriftsomfattende klargjøringsstrategien.

Evaluer alle klargjøringsvalg (valg mellom Data Cloud One, datadeling mellom Data 360-organisasjoner eller hjemmeorganisasjonsutpekning) mot disse overordnede punktene.

Det finnes tre hovedbrukstilfeller som krever beslutninger for Data 360-klargjøringg:

• Velge Hjem-organisasjonen
• Bruke en strategi for flere organisasjoner
• Dele data mellom Data 360-organisasjoner

Når du kjøper en Data 360-lisens, klargjøres Data 360-forekomsten i Salesforce-organisasjonen som er knyttet til den lisensen. Denne organisasjonen kalles Data 360-hjemmeorganisasjonen. Hjemmeorganisasjonen er ankeret for Data 360-forekomsten. Dette inkluderer følgende:

• Behandle Data 360-lagring og databehandling (i området som ble valgt ved klargjøring).

• Bruk av administrasjons-, styrings- og sikkerhetspolicyer

• Ytelse for datainntak, harmonisering, identitetsløsning, segmentering og aktivering

I scenarier for flere organisasjoner behandler hjemorganisasjonen den sentrale Data 360-forekomsten for andre Salesforce-"fellesorganisasjoner".

Hjemmeorganisasjonen:

• Bestemmer den geografiske plasseringen av Data 360-forekomsten.

• Bestemmer hvem som eier og administrerer Data 360-forekomsten. Administratorer i Data 360-startsorganisasjonen din har tilgang til alle data som hentes inn i Data 360.

• Bestemmer organisasjonstilkoblinger i en Data Cloud One-konfigurasjon.

• Angir grunnlaget for virksomhetens datastrategi – senere endring er vanskelig og forstyrrende.

Hvis du vil ha mer informasjon om Data 360-hjemmeorganisasjoner, kan du se Data 360-integrasjonsmønstre og -rutiner.

Den første store avgjørelsen er om du vil klargjøre Data 360 i en eksisterende produksjonsorganisasjon eller opprette en ny, dedikert organisasjon som skal fungere som hjemmeorganisasjonen.

Alternativ A: Klargjøre data 360 i en eksisterende organisasjon

Fungerer best for: Kunder med en enkelt Salesforce-organisasjon, eller kunder med flere organisasjoner som allerede har en stor sentralisert organisasjon der de fleste forretningsprosesser kjøres.

• Forside:

  • Enkleste bane: Data 360 klargjøres der CRM-dataene befinner seg.

  • Umiddelbar tilgang til lokale salgs-, tjeneste- og markedsføringsdata.

  • Ingen tilleggsintegrering kreves.

  • Færre lisenser og miljøer å behandle.

  • Øker hastigheten på tidlig tilpassing, pilot- og produksjonsbrukstilfeller.

• Koner:

  • Kan arve en eksisterende organisasjons styring eller teknisk gjeld.

  • Hvis det ikke finnes en enkelt "hovedorganisasjon", kan valg av én føre til eierskapsdiskusjoner.

  • Ytelsen er knyttet til organisasjonens plassering. Det kan hende at den ikke er i samsvar med de foretaksomfattende behovene for opphold.

  • Hvis flere forretningsenheter bruker forskjellige organisasjoner, kan lokal klargjøring føre til fragmentering hvis den ikke pares med Data Cloud One.

Eksempel:

Et SaaS-firma med én Salesforce-organisasjon klargjør Data 360 i denne organisasjonen for å forene kundeabonnement- og kundestøttedata.

Alternativ B: Klargjøring av data 360 i en ny, dedikert organisasjon

Fungerer best for: Kunder med flere Salesforce-organisasjoner som ikke kan justere på én enkelt hovedorganisasjon, eller virksomheter med en sterk Center of Excellence-modell (CoE).

• Forside:

  • Ryddeark for styring uten arvet organisasjonskompleksitet.

  • Sentralisert kontroll på tvers av flere forretningsområder.

  • Fleksibilitet for å velge et område basert på samsvarsbehov.

  • Handler som en nøytral delt tjenesteorganisasjon, ikke knyttet til én forretningsenhet.

  • Konfigurer for fremtidig Data Cloud One-arkitektur (hjemmeorganisasjon med flere tilhørende organisasjoner).

• Koner:

  • Kunder må lisensiere en ny Salesforce-organisasjon for å klargjøre Data 360.

  • Tilleggsintegrering kreves for å koble organisasjonen til en Data 360-enhet via en Data Cloud One-tilkobling.

  • Kan legge til administrative overhead (brukerbehandling, sikkerhet, identitet).

  • Tregere tid-til-verdi sammenlignet med klargjøring i en eksisterende produksjonsorganisasjon.

Eksempel:

Et multinasjonalt finanstjenestefirma oppretter en dedikert hjem-organisasjon for å klargjøre Data 360. Alle forretningsenhetsorganisasjoner (Retail, Wealth, Commercial Banking) kobler til som tilhørende organisasjoner via Data Cloud One.

Beslutningskriterier

Som et generelt prinsipp bruker du en eksisterende hovedorganisasjon som hjemorganisasjon for å minimere innledende innsats og øke hastigheten på tilpassingen. Opprett en ny, dedikert hjem-organisasjon bare hvis langsiktig styring eller samsvarsstrategi krever det. Opprettelse av en ny, dedikert hjemmebehandlingsorganisasjon er et vanlig valg for større virksomheter med et COE (Center of Excellence).

Enkel organisasjonsmiljø

Klargjør data 360 i din eksisterende produksjonsorganisasjon. Dette gir maksimal enkelhet og umiddelbar verdi. Det unngår unødvendige integrasjonsoverhead.

Multiple Org Miljø

Velg gjerne en av de viktigste organisasjonene – vanligvis den der det meste av virksomheten kjører, eller organisasjonen som fungerer som det sentraliserte CRM-et – for å fungere som hjemmen organisasjonen. Dette reduserer kompleksiteten, minimerer oppsettarbeid og lar deg raskt realisere Data 360-verdien. Bruk av en eksisterende hovedorganisasjon unngår også kostnader og integrasjonsinnsats ved behandling av et nytt miljø.

Når bør du vurdere en ny, dedikert hjemmeorganisasjon?

Opprettelse av en hjemmeorganisasjon gir fleksibilitet og nøytralitet, men med langsommere tid til verdi i disse tilfellene.

• Hvis organisasjonen har et sterkt Senter for ekspertise (CoE) og ønsker styring atskilt fra forretningsenhetsorganisasjoner.
• Hvis ingen enkelt eksisterende organisasjon er egnet på grunn av samsvars- eller organisasjonsbegrensninger.

Virksomheter driver ofte flere Salesforce-organisasjoner – og dette er ikke en kantside, men normen. Per februar 2024 kjørte omtrent 19 000 Salesforce-kunder allerede flere enn én Salesforce-organisasjon.

Hvorfor skjer dette?

• Oppkjøp og sammenslåinger: Nylig anskaffede firmaer har sine egne Salesforce-forekomster.
• Regionale operasjoner: Separate organisasjoner for EU, Nord-Amerika, Asia-Stillehavet og så videre, ofte for å oppfylle dataoppbevaringsforskrifter.
• Funksjonell separasjon: Forskjellige forretningsenheter (for eksempel Retail Banking, Wealth Management, Insurance) opprettholder sine egne organisasjoner for autonomi.
• Regulatorisk eller sikkerhetsisolasjon: Enkelte bransjer krever logisk forskjellige organisasjoner av hensyn til samsvar.
• Historiske eller tekniske årsaker: Over tid akkumulerer kunder organisk flere organisasjoner.

Hver årsak gir mening individuelt, men sammen skaper de fragmentering av data. Uten et forente lag har hver organisasjon bare en delvis visning av kunden.

Den arkitektoniske utfordringen: Hvordan forener du data på tvers av organisasjoner til en enkelt sannhetskilde samtidig som kravene til samsvar, styring og autonomi respekteres?

Data Cloud One er Salesforces tilkoblingsarkitektur for flere organisasjoner som tillater at flere Salesforce-organisasjoner deler én enkelt Data 360-forekomst. Det er det anbefalte mønsteret for virksomheter med flere Salesforce-organisasjoner.

I alle Data Cloud One-klynger er én Salesforce-organisasjon utpekt som hjemmeorganisasjonen som er vert for Data 360-forekomsten. Andre Salesforce-organisasjoner kobler sammen som medfølgende organisasjoner og bruker de forente dataene og metadataene fra startorganisasjonens Data 360.

Hvordan Data Cloud One fungerer

• Datainntak og forening (hjemmeorganisasjon)

  • All datainntakskonfigurasjon (Salesforce CRM, eksterne kilder, strømming, batch) skjer bare fra startorganisasjonen.

  • Data 360-leietageren knyttet til hjemorganisasjonen utfører identitetsløsning, harmonisering, modellering og forening i klarerte kundeprofiler.

  • Data 360-administrasjon, styringspolicyer, koding og maskering brukes sentralt fra startorganisasjonen.

• Data Space Architecture

  • Fra startorganisasjonen organiseres data i dataområder, som fungerer som logiske beholdere for data, metadata og prosesser.

  • Virksomheter kan opprette dataområder for merker, regioner eller forretningsområder.

  • Deling av dataområde: Fra startorganisasjonen deles spesifikke dataområder selektivt med tilhørende organisasjoner. Dette sikrer at bare de relevante dataene (og tilknyttede metadata) flyter til de riktige organisasjonene.

• Metadatadeling

  Samleorganisasjoner mottar metadatadefinisjoner fra hjemorganisasjonen, inkludert datamodellobjekter (DMO-er), forent profilskjema, beregnet innsikt, segmenter og mer. Disse vises som standard i den tilhørende organisasjonen som om de var lokale aktiva, men de er knyttet til hjemmen organisasjonen.

• Funksjoner i Hjem-organisasjon kontra partnerorganisasjoner Funksjonstilgang varierer mellom hjem- og partnerorganisasjoner. Samleorganisasjoner kan ikke hente inn eller forene data, og baserer seg på hjemmeorganisasjonen for inntak, modellering og forening. Samleorganisasjoner kan få tilgang til Data 360-data for å levere Data 360-drevne plattformfunksjoner, og de kan opprette lokal innsikt, segmenter og flyter på toppen av de delte, klarerte dataene. I den fremtidige visjonen kan de også få tilgang til aktiveringsfunksjoner.

• Plattformfunksjonsparitet Når metadataene er delt, er det noen funksjonelle forskjeller mellom hjemmebaseorganisasjoner og tilhørende organisasjoner når det gjelder bruk av Salesforce Platform-funksjoner. Liste over støttede funksjoner finnes i Data 360-funksjoner i medfølgende organisasjoner.

  • Salesforce-plattformfunksjoner – som Flyter, Rapporter, Ledetekstbygger, kontrollpaneler og andre plattformbaserte verktøy – fungerer i både hjem- og ledsagerorganisasjoner når metadata er tilgjengelig.

  • Data 360-drevne funksjoner, som Agentforce, Prospecting Center, Sales Cloud Einstein og Service Cloud AI-funksjoner, fungerer også sømløst i både hjemme- og partnerorganisasjoner. Enkelte funksjoner er kanskje på vei til fullstendig kompatibilitet, men det generelle målet er å ha funksjonsparitet mellom hjemmebaseorganisasjoner og tilhørende organisasjoner for alle funksjoner på tvers av skyer som er avhengige av Data 360.

• Forbruksmodell All organisasjonsaktivitet (spørringer, segmentkjøringer, Data 360-utløste flyter, bruk av AI, Einstein Trust Layer-logging og så videre) bruker Data 360-kreditter fra hjemmen. Forbruk flyter én vei: kreditter sentraliseres, faktureres og spores mot hjemmenes kredittildeling. Du kan imidlertid se nærmere på hvor mange kreditter hver enkelt organisasjon brukte i Digital Wallet.

• Design Princip: Horisontal konstruksjon Den horisontale konstruksjonen i Data 360 er et grunnleggende utformingsprinsipp, primært implementert via Data Cloud One, som tillater at en enkelt Data Cloud-forekomst spenner over flere distinkte Salesforce CRM-organisasjoner. Målet er at alle nye utgitte funksjoner fungerer i både hjem- og partnerorganisasjoner uten ekstra oppsett. Denne funksjonaliteten sikrer at Data Cloud One ikke bare er et datarkitektursvalg, men et grunnleggende element i Salesforce-plattformen fremover.

Virksomheter som har flere organisasjoner, må velge hvordan og hvor Data 360 skal finnes i sitt økosystem. Ønsker de å klargjøre uavhengige Data 360-organisasjoner i hver organisasjon, eller bruker de Data Cloud One til å forene organisasjoner under én enkelt hjemmeorganisasjon?

Alternativ A: Flere uavhengige Data 360-organisasjoner

Hver Salesforce-organisasjon klargjør sin egen Data 360-forekomst.

Forside:

• Autonomi: Hver forretningsenhet eller -region kontrollerer sin egen Data 360.

• Enkelhet i hver organisasjon: Governance, security og tilpassinger lokaliseres.

• Samsvar med forskrifter: Nyttig når streng regulatorisk adskillelse kreves (data må for eksempel ikke krysse grenser).

Koner:

• Data-silos: Forente profiler kan ikke oppnås på tvers av organisasjoner.

• Høyere kostnad: Hver forekomst krever lisens, administrasjon og integrering. Kunder slutter å hente inn de samme kildedataene flere ganger på tvers av flere forskjellige organisasjoner.

• Duplikatarbeid: Identitetsløsning, segmentering og anriking må gjentas i hver Data 360-forekomst.

Alternativ B: Én delt Data 360 (Data Cloud One-klynge)

En enkelt Data 360 klargjøres i en hjemmeorganisasjon, med andre Salesforce-organisasjoner koblet til som tilhørende organisasjoner.

Forside:

• Enkel sannhetskilde (SSOT): Alle organisasjoner deler en forent datamodell.

• Kosteneffektivitet: Behandle bare én Data 360-lisens og -infrastruktur.

• Forent styring: Centralt brukte policyer, sikkerhet og samsvarskontroller.

• Forbedring på tvers av organisasjoner: Få tilgang til harmoniserte profiler, innsikt og segmenter på tvers av tilhørende organisasjoner.

• AI-klargjøring: Et foretaksomfattende datasett muliggjør bedre opplæring og aktivering av AI-modeller.

• Fremtidig bevis: Å legge til nye organisasjoner er enkelt fordi det ikke er behov for nye Data 360-organisasjoner.

Koner:

• Tilleggsforberedelse: Én Data 360 krever planlegging for organisasjon-til-hjem-organisasjonstilkobling.

• Vurderinger angående forsinkelse: Medfølgende organisasjoner i forskjellige områder kan se tregere spørringer.

• Komplekse styringer: Hvis hver organisasjon har forskjellige tilpassingsbehov, kan detaljert styring være komplekst.

Alternativ C: Flere Data Cloud One-klynger

Noen ganger kan styring, samsvar eller andre forretningskrav gjøre det upraktisk å gruppere alle organisasjoner sammen. Dette kan føre til at det er nødvendig å implementere en hybridløsning der virksomheten driver flere Data 360-organisasjoner, som hver er hjemmen organisasjonen for en annen klynge av tilhørende organisasjoner.

Eksempel:

Et multinasjonalt selskap har Salesforce-organisasjoner i ulike regioner, inkludert Europa, USA og Asia. For å overholde bestemmelser om regional dataoppbevaring klargjør de én Data 360 for hvert separate område.

Beslutningskriterier

Foretrukket mønster: Data Cloud One

Hvis du vil forenkle styringen og optimalisere kostnader på tvers av flere organisasjoner, bruker du én enkelt hjemmeorganisasjon med tilkoblede tilhørende organisasjoner.

Når skal du bruke flere Data 360-organisasjoner: Bruk bare flere Data 360-organisasjoner hvis samsvar, opphold eller organisasjonsautonomi krever det strengt (for eksempel hvis europeiske operasjoner må forbli fullstendig atskilt fra amerikanske operasjoner på grunn av forskrifter).

Hvordan velger du Hjem-organisasjonen i Data Cloud One: Start med å vurdere en av de viktigste organisasjonene, vanligvis der det meste av virksomheten kjører. Klargjøring av Data 360 der kan redusere kompleksiteten og maksimere tidligverdien.

Vurder å opprette en dedikert hjemmeorganisasjon som administreres av et COE-team, bare hvis ingen eksisterende organisasjon er egnet.

Generell prinsipp:

I miljøer for flere organisasjoner minimerer du antall Data 360-organisasjoner. Favorere Data Cloud One som standardmønster for å redusere duplisering, aktivere AI-klargjøring og forenkle styring.

Data Cloud One er den anbefalte løsningen for de fleste virksomheter, men det finnes scenarier der kunder må klargjøre flere Data 360-forekomster, inkludert:

• Regional overholdelse. En multinasjonal forhandler klargjør én Data 360 i EU og en annen i USA. Data 360-til-Data 360-datadeling gir firmaet mulighet til å opprette innsikt fra lokale data og fremdeles dele innsikten med hovedkontoret i USA.
• Forretningsenhetssamarbeid. Et konglomerat kjører separate Data 360-organisasjoner for Detaljhandel og Forsikring. Datadeling mellom Data 360-organisasjoner gir brukere tilgang til en enkelt, autorisert datakilde uten å flytte eller kopiere. Med datadeling mellom Data 360-organisasjoner mottar Forsikring-organisasjonen Detaljhandel-segmentet "High-Value Customer" for målrettede kryssalgskampanjer.
• Fusjoner og oppkjøp. Et overordnet firma anskaffer et datterselskap med sitt eget Data 360. Når det er to forekomster å behandle, beholder bevaring av kortsiktige datasalonger datasikkerhet og SSOT-integritet. Samtidig deling av data mellom to Data 360-forekomster tillater nødvendig samarbeid under overgangen.
• Federate Executive Dashboards. En multinasjonal spredning på tvers av kontinenter klargjør individuelle Data 360-organisasjoner per region. Ledere ønsker en samlet kvartalsvis ytelsesvisning. Hver regionale Data 360-enhet deler aggregerte beregnede innsikter med en "lederorganisasjon" som aktiverer foretaksomfattende rapportering.

Når det finnes flere Data 360-organisasjoner, er ikke forening på tvers av dem automatisk. Deling av Data 360-til-Data 360-data gir kunder mulighet til å dele bestemte objekter mellom Data 360-forekomster uten duplikater eller tilpassede under arbeid. Det er en delingsmekanisme for metadata med null kopiering utformet for samarbeid på tvers av Data 360-organisasjoner.

• Hver Data 360 klargjøres i sin egen hjemmeorganisasjon.

• Administratorer kan opprette en datadeling – en gruppering av bestemte objekter de vil dele.

• Tilgang til de valgte dataene deles med målorganisasjonens Data 360, der objektene vises som om de var definert lokalt. Bare tilgang deles, de underliggende dataene forblir i kildedata 360.

• Koder deles ikke. Bare råobjektene blir gjort tilgjengelig. Målorganisasjonen må bruke eventuelle koder for styring, drift eller AI på nytt etter behov.

• I Data Cloud One deler flere medfølgende organisasjoner én enkelt Data 360-forekomst. For å sikre konsistens kjører plattformfunksjoner som Agentforce, Prospecting Center og Tableau Neste på de samme underliggende dataene.

• Når du bruker datadeling mellom Data 360-organisasjoner, har hver organisasjon sin egen Data 360. Funksjoner som Agentforce i organisasjon A og organisasjon B opererer hver uavhengig på sin lokale forekomst. Ingen deling skjer automatisk – hensiktsmessige datadeling må opprettes for å samarbeide bare om bestemte objekter.

Hvis virksomheten har flere Data 360-organisasjoner

• Bruk datadeling mellom Data 360-organisasjoner til å samarbeide på tvers av dem i stedet for å bygge tilpassede pipelines eller duplisere data.

• Del bestemte objekter (DMO-er, beregnede innsikter, segmenter) ved å opprette datadeling og gi dem til målorganisasjoner.

• Koder deles ikke – mottakerorganisasjonen må bruke koder på nytt for styring, klassifisering eller AI-forbedring.

Bruk datadeling mellom Data 360-organisasjoner

• For å oppfylle lovpålagte krav som hindrer sentralisering.

• For å opprettholde forretningsenhetens autonomi samtidig som selektivt samarbeid aktiveres.

• For å tilby kontrollpaneler for forente ledere på tvers av flere områder.

• For å bygge bro mellom M&A-scenarier der konsolidering ikke er umiddelbart mulig.

Design nøye

Behandle deling av Data 360-til-Data 360-data som en forbundsstrategi, ikke som en erstatning for Data Cloud One.

• Bruk objektspesifikk deling.
• Unngå overdeling.
• Juster datadeling med forretnings- og samsvarsbehov.

Planlegging av datastrategien for Data 360-klargjøring er en viktig, langsiktig arkitektonisk beslutning som må tas i hele bedriften, ikke organisasjon for organisasjon. Dette tidlige strategiske valget bestemmer hvordan kundedata forenes, hvordan styring håndheves og hvordan viktige plattformfunksjoner, spesielt AI og analyse, skaleres på tvers av organisasjonen. Planlegg styrings- og eierskapsmodeller på forhånd, og unngå kortsiktige snarveier som fører til fragmentering og økt kompleksitet senere.

Hva er Customer 360?

Data 360-integrasjonsmønstre og -rutiner

Data 360-arkitektur

Data 360 sikkerhetsarkitektur

Om forfatterne

Kunal Goyal er direktør for produktbehandling i Salesforce, fokusert på å fremme flerorganisasjonsarkitektur og skalerbarhet i Data 360. Siden 2017 har han ledet flere initiativer og produkter som fokuserer på samarbeid på tvers av organisasjoner og systemutforming for flere leietagere. Kunal er en av salgsemnene i Data 360-arkitektur med gode fremgangsmåter og produkteieren for Data Cloud One, oppsett, klargjøring og administratoropplevelser.

Erin Wagner Tidwell er hovedteknisk forfatter og innholdsdesigner for Data 360. Hun har vært i Salesforce siden 2013. Hun er dedikert til å gjøre det enklere å forstå og bruke Data 360 gjennom tydelig, konsistent og nøyaktig teknisk dokumentasjon og kommunikasjon i appen.

Yugandhar Bora er Software Engineering Architect på Salesforce, spesialisert seg på dataarkitektur i plattformen Data and Intelligence-programmer. Han leder EARB-initiativer (Enterprise Architecture Review Board) fokusert på datastyring og forente datamodeller, samtidig som han bidrar til automatiserte plattformklargjøringsløsninger.

Samarpan Jain er hovedarkitekt hos Salesforce og spesialiserer seg på Commerce Cloud, plattformintegrering og arkitektur for flere organisasjoner. En av Salesforces lengste ansatte leder viktige initiativer, inkludert overholdelse av krav om dataoppbevaring for myndighetskunder og tilskrivingssystemer for bruk av Data 360.