De fleste enterprise integration pipelines mellom Salesforce og eksterne analyseplattformer er avhengig av tilpasset kode. De virker til noe brytes. Skjemaavvik, API-uttømmelse og hull i permanent sletting krever konstant teknisk intervensjon. Etter hvert som firmaer går mot smidige, utvikleraktiverte arkitekturer for borgere, blir denne modellen en flaskehals: Analytics-team venter på tekniske sprinter for å legge til et Salesforce-felt i et nedstrøms skjema, mislykkede nattlige innlastinger forsinker rapportering mandag morgen, og enkle konfigurasjonsendringer krever kodevurderinger og distribusjoner.

CRM Analytics, Salesforces innebygde analyse- og forretningsintelligensplattform, løser dette problemet ved å gi firmaer mulighet til å utforske data, bygge interaktive kontrollpaneler og avdekke AI-drevet innsikt uten å forlate Salesforce-økosystemet. Sentral for denne funksjonen er en deklarativ, datasynkroniseringsfunksjon med lite kode som er innebygd som standard i plattformen: CRM Analytics SyncOut og CRM Analytics SyncIn.

CRM Analytics SyncOut flytter Salesforce-poster til eksterne datalager etter en konfigurert tidsplan ved å bruke Endre datafangst (CDC) for inkrementelle innlastinger og innebygd sporing av permanent sletting til å flagge poster som er fjernet permanent. CRM Analytics SyncIn henter eksterne data tilbake til Salesforce, tilordner kolonner til objektfelt og oppdaterer poster ved bruk av Bulk API 2.0. Begge konfigureres fullstendig via Salesforce-oppsettet. Ingen pipelines, ingen oppstillingsskript, ingen tilpasset overvåking. Administratorer konfigurerer en synkroniseringsjobb i én Oppsett-økt. Plattformen håndterer automatisk utførelse, nytt forsøk, feillogging og skjematilordning.

Denne veiledningen forklarer mønsteret, når det skal brukes, hvordan det skal implementeres med Snowflake som et arbeidende eksempel, og de arkitektoniske vurderingene som bestemmer om det passer til et gitt integrasjonsproblem.

CRM Analytics er Salesforces innebygde analyse- og forretningsinformasjonsplattform som gir brukere mulighet til å utforske data, bygge interaktive kontrollpaneler og avdekke AI-drevne innsikter – alt i Salesforce-økosystemet. Denne plattformen flytter data mellom Salesforce og eksterne systemer via to viktige funksjoner\: CRM Analytics SyncOut og CRM Analytics SyncIn. CRM Analytics SyncOut overfører Salesforce-objektdata til en ekstern dataplattform og støtter både fullstendig og inkrementell (CDC)-synkroniseringsmodus med innebygd sporing av permanent sletting. CRM Analytics SyncIn fullfører den toveisende sløyfen ved å trekke ut data fra en ekstern plattform tilbake til Salesforce-objekter med Bulk API 2.0, slik at store datavolumer håndteres pålitelig og effektivt.

Lisensnotat: CRM Analytics SyncIn og SyncOut er ikke tilgjengelig på basis Salesforce Edition uten et CRM Analytics-lisenstillegg. Bekreft lisensberettigelser før du utformer en synkroniseringsarkitektur som avhenger av disse funksjonene.

Dataintegrering er en av de høyeste friksjonsfeltene i bedriftens arkitektur. En tilpasset ETL pipeline fra Salesforce til en analyseplattform krever vanligvis en tilkoblet app for godkjenning, en planlagt jobb for SOQL-uttrekking, et transformasjonslag for å avstemme felttyper, et oppstillingsområde for masseinnlasting og et overvåkningslag for å fange opp feil. Hver komponent i tilpasset kode representerer et feilpunkt.

Kostnaden for denne friksjonsforbindelsen over tid. Skjemaavvik i Salesforce (et felt med nytt navn, en ny valglisteverdi, et endret API-navn) bryter pipelinen stille. API-uttømming ved høyeste bruk stopper uttrekkingen. Hardslettede poster vises aldri i måltabellen, noe som gir foreldede data som nedstrøms analyser behandler som aktive. Teknisk team blir flaskehals for rutinedataoperasjoner.

CRM Analytics SyncIn og SyncOut endrer operasjonsmodellen. Konfigurasjon erstatter kode. Plattformen tar ansvar for utførelse, feilhåndtering, skjematilordning og observasjon. Administratorer kan definere, endre og overvåke synkroniseringsjobber uten å heve en utviklingsbillett.

Resultatet av denne nye driftsmodellen er redusert tid fra integrasjonsutforming til driftssynkronisering, lavere teknisk overhead og en integrasjonsmodell som skaleres innenfor plattformbegrensninger i stedet for å kreve vedlikehold av tilpasset kode.

SyncIn og SyncOut er de to retningsmodusene for CRM Analytics-datasynkronisering. SyncOut flytter Salesforce-poster til en ekstern plattform. SyncIn henter inn eksterne poster i Salesforce. Begge opererer på en deklarativ konfigurasjonsmodell uten nødvendig tilpasset kode.

Deklarativ konfigurasjon betyr at all synkroniseringsvirkemåte defineres via pek-og-klikk-grensesnittet i Oppsett i Salesforce. Kildeobjekt, måltabell, felttilordninger, synkroniseringsplan, synkroniseringsmodus og filtre angis alle via konfigurasjonsmetadata. Plattformen utleder utførelsesplanen fra disse metadataene og administrerer den fra ende til ende.

Full synkronisering kontra inkrementell synkronisering bestemmer hvilke data som flyttes ved hver kjøring. En fullstendig synkronisering spør alle poster som samsvarer med filterkriteriene for hver utførelse. En inkrementell synkronisering bruker CDC til å spørre bare poster som har blitt endret siden forrige kjøring. Inkrementell synkronisering er den anbefalte modusen for objekter med stor trafikk fordi den reduserer API-forbruk og synkroniseringsvarighet betydelig.

Change Datafangst (CDC) er en Salesforce-plattformfunksjon som registrerer endringer på feltnivå for objekter som hendelsesstrømmer. SyncOut bruker CDC til å oppdage opprettelser, oppdateringer og slettinger uten å utføre fullstendige tabellskanninger. CDC må være aktivert per objekt i Salesforce-oppsettet før det kan refereres til det av en synkroniseringskonfigurasjon.

Hard-delete-sporing løser et av de mest vedvarende problemene i Salesforce-til-ekstern ETL. Når en post slettes permanent i Salesforce, forsvinner den fra standard SOQL-spørringer. Uten eksplisitt sporing får den eksterne plattformen aldri vite at posten ble fjernet. SyncOuts sporing med permanent sletting flagger slettede poster i måltabellen med DEL_FLAG = 'Y', slik at nedstrømsystemer får et pålitelig signal for å filtrere foreldede data.

Synkroniseringsfrekvensen kan konfigureres fra 15 minutter til ukentlig. Valget er en avveining mellom dataoppdatering, API-forbruk og beregningskostnader for Snowflake-lageret. 15-minutters synkroniseringstilnærming i nær sanntid for driftskontrollpaneler. Daglige synkroniseringer er egnet for grupperapporteringsarbeidsbelastninger.

Governor limits restrain synkroniseringsjobb design: Salesforce API-forespørselsgrensen (15 000 samtaler per 24 timer i Unlimited Edition), batchstørrelsen på Bulk API 2.0 på 10 000 poster og SOQL-spørringsradgrensen på 50 000 per transaksjon, alle gir informasjon om hvordan du skal skala og planlegge synkroniseringsjobber. Plattformen håndterer automatisk fordeling og sideinndeling, men arkitekter må ta hensyn til begrenset arbeidsplass på tvers av alle synkroniseringsjobber som kjører i organisasjonen.

Snowflake er et primært mål og kilde for datasynkronisering med Salesforce CRM Analytics. Den tjener som et konkret eksempel på hvordan batch- og inkrementell databevegelse fungerer fra ende til ende.

Denne delen gir en oversikt over implementering av CRM Analytics SyncOut og SyncIn med Snowflake som ekstern analyseplattform. Den dekker hver metode, de delte godkjenningsmodellene, sikkerhetsrammeverk, viktige plattformvurderinger og observerbarhetsrutiner.

I denne SyncOut-konfigurasjonen bruker Salesforce CRM Analytics SyncOut til å pushe poster til Snowflake. Plattformen trekker ut data via SOQL, håndterer typekonverteringer automatisk og laster dem inn i Snowflake-tabeller etter en konfigurert tidsplan (fra 15 minutter til ukentlig). Se gjeldende Salesforce- og Snowflake-dokumentasjon for å finne spesifikk semantikk for innlasting.

I denne SyncIn-konfigurasjonen bruker Salesforce CRM Analytics SyncIn til å hente data tilbake til Salesforce. Plattformen spør Snowflake via Statements API og setter inn resultater i Salesforce med Bulk API 2.0. Store resultatsett blir automatisk sideinndelt for å holde seg innenfor API-grenser. Synkroniseringen utføres etter en konfigurert tidsplan, fra 15 minutter til ukentlig.

Salesforce-synkronisering støtter flere godkjenningsmetoder for å koble seg sikkert til Snowflake. De to primære løsningene for enterprise-integrasjoner er Nøkkelpar (Privat nøkkel) og Delegert OAuth 2.0.

Metode 1: Nøkkelpar (privat nøkkel) godkjenning: Nøkkelpargodkjenning er den anbefalte tilnærmingen for automatisert dataflytting fra system til system, som CRM Analytics SyncIn og SyncOut. Godkjenning er avhengig av JSON-netttokener (JWT) i stedet for passord eller oppdaterbare tokener, noe som gjør det egnet for ikke-overvåkede, planlagte jobber som ikke krever tokenoppdatering.

• Salesforce-sertifikat: Generer en privat nøkkel og lagre den sikkert i Salesforce-sertifikat og nøkkelbehandling.
• Ekstern/navngitt legitimasjon: Konfigurert til å bruke en JWT-bytte. Salesforce bruker den lagrede private nøkkelen til å signere utgående tilkoblingsforespørsler.
• Snowflake bruker fellesnøkkel: Den samsvarende fellesnøkkelen tildeles direkte til den dedikerte Snowflake-tjenestekontoen (for eksempel ALTER USER CRM_ANALYTICS_SYNC_USER SET RSA_PUBLIC_KEY = '...'). Snowflake bruker deretter denne nøkkelen til å bekrefte den innkommende JWT-signaturen. Ingen sikkerhetsintegrering kreves for denne metoden.

Metode 2: Delegert OAuth 2.0-godkjenning: Alternativt kan Salesforce bruke et OAuth-håndtrykk til å godkjenne. Nøkkelkomponentene er:

• Auth-leverandør: Behandler OAuth-håndtaket med Snowflake ved å bruke klientlegitimasjonen hentet fra Snowflakes sikkerhetsintegrering.
• Ekstern legitimasjon: Oppbevarer OAuth-tokenene sikkert i Salesforce og injiserer dem automatisk i synkroniseringskallene.
• Navngitt legitimasjon: Definerer Snowflake-sluttpunkt-URL-adressen (for eksempel https://<konto>.snowflakecomputing.com) og refererer til den eksterne legitimasjonen.
• Snowflake-sikkerhetsintegrering: Registrerer Salesforce som en klarert OAuth-klient i Snowflake (OAUTH_CLIENT = CUSTOM). Definerer den tillatte URI-en for omdirigering og aktiverer oppdateringstokener.

Konfigurasjonsavhengighet: Uavhengig av den valgte metoden danner disse komponentene en avhengighetskjede som kobler synkroniseringskonfigurasjonen til endepunktet. Det kreves å gi de relevante Salesforce-profilene tilgang til den navngitte legitimasjonen. Uten denne tilgangen mislykkes synkroniseringsjobber på grunn av godkjenningsfeil uavhengig av alle andre konfigurasjoner.

Bakgrunnssynkronisering er avhengig av en enkelt integrasjonsidentitet.

• Dedikert tjenestekonto: Opprett en dedikert Snowflake-tjenestekonto med en rolle med minst rettigheter som omfatter bare databasene, skjemaene og tabellene som kreves for synkroniseringen.
• Granular Permissions: For SyncOut krever denne rollen INSERT, UPDATE og SELECT i måltabeller. Bruk aldri roller med høye rettigheter som ACCOUNTADMIN, SECURITYADMIN eller SYSADMIN.

• Governors grenser og brudd: Under SyncOut-uttrekking brytes store resultatsett automatisk sammen for å respektere Salesforce SOQL-styringsgrenser. SyncIn henter store resultatsett fra Snowflake-setnings-APIen via automatisk sideinndeling for å behandle datavolumer effektivt.
• Change Datafangst (CDC): Inkrementell synkronisering er avhengig av Salesforce CDC-hendelsesstrømmen for å identifisere poster som er opprettet, oppdatert eller slettet. Hvis sporing av permanent sletting er aktivert, utelates ikke slettede Salesforce-poster, men flagges med DEL_FLAG = 'Y' i Snowflake.
• Upsert-begrensninger: SyncIn baserer seg på Bulk API 2.0 for å laste data tilbake til Salesforce. Dette krever at et utpekt felt for ekstern ID er konfigurert på Salesforce-målobjektet for å fungere som oppdateringsnøkkelen.
• Designveiledning: Synkroniser alltid fra kuraterte Snowflake-visninger i stedet for rådata. Visninger tillater forhåndsfiltrering av rader, kolonnevalg og bruk av forretningslogikk, noe som reduserer datavolum, synkroniseringsvarighet og beregningskostnader for Snowflake-lageret i forhold til forhåndsfiltreringen som brukes.

Hver synkroniseringskjøring genererer omfattende revisjonsspor for å validere dataflyt. Kontrollpanelet Synkroniseringsjobbovervåking gir sanntidsstatus, antall behandlede poster, utførelsesvarigheter og detaljerte feillogger for både SyncIn og SyncOut. På Snowflake-siden logges hver spørring som sendes av Salesforce, i Snowflake-spørringshistorikk, som gir full oversikt over utførelseslatens, skannede rader og bruk av lagerbeholdning. I tillegg definerer arkitekter dedikerte Snowflake-revisjonstabeller for å fange opp synkroniseringskjøringsmetadata – tidsstempel, antall poster og feil. Disse genereres ikke automatisk av plattformen. For slutt-til-slutt-validering sammenligner du antall poster på tvers av begge plattformene: bekrefte aktive poster i Snowflake (WHERE DEL_FLAG = 'N') for SyncOut-kjøringer, og sammenligne Salesforce-målobjektantall direkte mot den opprinnelige Snowflake-kildevisningen for SyncIn-kjøringer.

Bruk CRM Analytics SyncIn og SyncOut når:

• Bidireksjonell synkronisering er et krav: Data flyter både til Salesforce via SyncIn og ut til en ekstern plattform via SyncOut.
• Hard-delete-sporing er avgjørende: SyncOuts innebygde flagging løser et historisk komplekst ETL-problem uten tilpasset avstemmingslogikk.
• CDC-basert inkrementell synkronisering er mulig: For Salesforce-objekter med stor trafikk reduserer CDC API-forbruket og synkroniseringsvarigheten betydelig sammenlignet med fullstendige skanninger.
• Planlagt gruppesynkronisering oppfyller latenskrav: Minste synkroniseringsfrekvens er 15 minutter, egnet for operasjonelle kontrollpaneler og rapportering av analyser i nær sanntid.
• Lave driftsutgifter er en prioritet: Innebygde kontrollpaneler gir full synkroniseringssynlighet uten tilpasset logging eller varslingsinfrastruktur, og det deklarative oppsettgrensesnittet lar administratorer definere, endre og overvåke synkroniseringsjobber uten å heve en utviklingsbillett.

Ikke bruk dette mønsteret hvis:

• Komplekse transformasjoner kreves: Flertabellkoblinger, JSON-analyser eller håndtering av avansert forretningslogikk i Snowflake-visninger eller et dedikert transformasjonslag før eller etter synkronisering.
• Under 15 minutters latens kreves: Til sanntids brukstilfeller bruker du plattformhendelser eller strømmede API-er.
• Veldig store strømmingsarbeidsbelastninger er i omfang: Objekter med millioner av transaksjoner per time betjenes bedre av dedikerte streaming under arbeid (Kafka, Plattformhendelser).
• Tilpasset feilhåndteringslogikk er nødvendig: Plattformen tilbyr standard ny prøve- og feillogging. Komplekse prøvingsmønstre eller tilpassede varsler krever Apex eller ekstern orkestrering.
• Multi-organisasjons- eller skysynkronisering: CRM Analytics SyncIn og SyncOut opererer i én enkelt Salesforce-organisasjon. MuleSoft eller et tilpasset integrasjonslag kreves for scenarier for flere organisasjoner.

Et team kjørte komplekse ETL pipelines for å laste opp Snowflake-analysedata til CRM Analytics-datasett. Pipelinene var trege, sårbare og krevde konstant teknisk vedlikehold.

CRM Analytics SyncIn ble konfigurert til å synkronisere kuraterte Snowflake-aggregerte visninger direkte til tilpassede Salesforce-objekter. Teamet omkonfigurerte CRM Analytics-kontrollpaneler for å lese fra disse objektene i stedet for CRM Analytics-datasett. Resultatet: to ETL pipelines eliminert, synkroniseringsvarighet redusert fra fire timer til 30 minutter, og administratorer kan endre synkroniseringskonfigurasjoner uten å heve en teknisk billett.

Et datateam trenger å spore permanent slettede Salesforce-poster i sitt operasjonelle Snowflake-datalager. Tradisjonelle tilnærminger krevde oppdelingsjobber og kompleks ID-sammenlikningslogikk som tok timer å kjøre og var sprø på tvers av skjemaendringer.

Teamet konfigurerte CRM Analytics SyncOut med CDC og sporing av permanent sletting aktivert. Slettede poster flagges nå automatisk med DEL_FLAG = 'Y' i tabellen over Snowflake-forbruk. Nedstrøms analysespørringer bruker WHERE DEL_FLAG = 'N' for å se bare aktive poster. Avstemmingslogikk ble helt eliminert, og synkroniseringsvarigheten falt fra åtte timer til trinnvise kjøringer på 15 minutter.

Under et oppkjøp synkroniserte det anskaffende firmaet seks Salesforce-objekter med stor trafikk til Snowflake for rapportering på tvers av organisasjoner og etterlevelse av forskrifter innenfor en fast tidslinje.

Teamet konfigurerte CRM Analytics SyncOut for alle seks objekter med CDC-baserte inkrementelle synkroniseringer. Revisjonsmetadatatabeller sporet skjemaendringer og antall poster i hele integreringsperioden. De skrev ikke noen tilpasset kode. Dataoppdateringen ble forbedret fra daglige til 15-minutters intervaller, og metadatatabellene for revisjon ga sporbarheten som kreves for samsvarsrapportering.

Synkroniseringsjobber deler organisasjonens API-budsjett. En organisasjon som kjører mange høyfrekvente synkroniseringsjobber mot store objekter, risikerer å utnytte grensen på 15 000 API-kall per 24 timer. Lager alle synkroniseringsjobber, beregne API-forbruk per kjøring, og overfør tidsplaner for å fordele belastningen. For objekter med lave til moderate endringsfrekvenser kan CDC-basert inkrementell modus redusere API-forbruk per kjøring betydelig sammenlignet med full synkronisering.

SyncIn og SyncOut utfører spørringer og datalastinger mot en Snowflake-lager, og bruker beregningskreditter. For enkle SELECT-spørringer er en X-Small- eller Small-lager vanligvis tilstrekkelig. For store SyncOut-innlastinger kan det være nødvendig med Middels eller Stor. Konfigurer automatisk suspensjon (5 minutter med inaktivitet) og automatisk gjenopptagelse i lagerbygningen. Bruk en dedikert lagerbygning til produksjonssynkroniseringsjobber for å isolere kostnader og hindre konflikt med brukerspørringer.

Hvis et Salesforce-felt endres navn, fjernes eller endres API-navn, mislykkes den tilhørende SyncOut-felttilordningen stille eller logger feil. Opprett en endringsbehandlingsproces, der inkluderer gennemgang af aktive synkroniseringskonfigurationer som en del af enhver Salesforce-metadataændring. Snowflake-revisjonstabellene inneholder en endringshistorikk som bidrar til å identifisere når en avvikshendelse oppstod.

Sporing av permanent sletting i SyncOut krever at CDC er aktivert for Salesforce-objektet. Hvis CDC ikke er aktivert, har ikke alternativet Spore permanent sletting noen effekt. Valider CDC-aktivering som en del av sjekklisten for synkroniseringskonfigurasjon, spesielt under første oppsett eller etter organisasjonsoverføringer.

Den vanligste feilklassen er legitimasjonsutløp eller tap av tillatelse. Navngivne legitimationsoplysninger skal forblive gyldige, og Snowflake-tjenestekontoen skal beholde sine tilladelser til brug af lager og tabel. For OAuth-baserte oppsett kan tokenoppdateringsfeil stille stanse synkroniseringsjobber. Overvåk kontrollpanelet Synkroniseringsjobbovervåking for godkjenningsfeilmønstre, og konfigurer Chatter eller e-postvarsler for jobbfeil.

SyncIn bruker et Salesforce External ID-felt som oppdateringsnøkkel. Hvis kilde Snowflake-visningen inneholder duplikatverdier i nøkkelfeltet, mislykkes oppdateringen for berørte poster. Håndhev unikhet for nøkkelfeltet i Snowflake-visningslaget før det når synkroniseringskonfigurasjonen.

Når synkroniseringsjobber mislykkes, logger plattformen detaljerte feilmeldinger per post i Synkroniseringsjobbovervåking. Vanlige feilscenarier og deres løsninger:

• Godkjenningsfeil: bekrefte status for navngitt legitimasjon og Snowflake-kontoens utløp. Godkjenn OAuth på nytt hvis tokenoppdatering mislyktes.
• Feltilordning-feil: kontrollere typekompatibilitet mellom Snowflake-kolonner og Salesforce-felt. Se gjennom feltnivåsikkerhet for den kjørende brukeren.
• Governor grense overskredet: redusere synkroniseringsfrekvensen eller gå til inkrementell CDC-modus for å spre API-forbruket.
• Snowflake lager suspendert: konfigurere automatisk gjenopptagelse i lagerbygningen eller utløse en manuell gjenopptagelse før neste planlagte synkronisering.
• Hard-slete-sporing fungerer ikke: kontroller at CDC er aktivert for objektet, og flagget "Spore permanent sletting" er angitt i synkroniseringskonfigurasjonen.

CRM Analytics-datasynkronisering er i samsvar med flere søyler i det velbygde Salesforce-rammeverket.

• Pålitelighet (feiltoleranse): Plattformen administrerer automatisk utførelse, prøvingslogikk på nytt og håndtering av delvise feil. Mislykkede poster logges individuelt i Synkroniseringsjobbovervåking. Implementer avstemming av antall poster etter feil for å bekrefte konsistens, supplere med feilmeldinger og overvåke Synkroniseringsjobbovervåking for gjentagende feilmønstre. CDC-basert inkrementell synkronisering reduserer blastradiusen for en mislykket kjøring ved å begrense datavinduet i omfang.
• Trust: Legitimasjonsmodellen (Navngitt legitimasjon, Ekstern legitimasjon, Godkjenningsleverandør) håndhever kryptert lagring, automatisk tokenoppdatering og sentralisert behandling. Tilgang med minst privilegium på Snowflake-siden begrenser blastradiusen til en kompromittert legitimasjon. Feltnivåsikkerhet håndheves under synkronisering. Brukere kan ikke synkronisere felt som de ikke er autorisert til å få tilgang til.
• Ressurs- og kostnadsoptimalisering: Inkrementell CDC-modus er den primære spaken for ytelsesoptimalisering. Det reduserer API-forbruk, synkroniseringsvarighet og Snowflake-datakostnader sammenliknet med full synkronisering. Forhåndsfiltrering av Snowflake-visninger reduserer ytterligere datavolum under overføring. Automatisk oppheng i lagerbygning hindrer uvirksomme beregningsutgifter.
• Operational Excellence: Den deklarative konfigurasjonsmodellen betyr at synkroniseringsjobber er definert i metadata, ikke kode. Det gjør dem reviderbare, reproduserbare og administrerbare uten ingeniørengasjement. Innebygde kontrollpaneler for overvåking gir full observasjon uten tilpasset loggingsinfrastruktur.
• Pålitelighet (skalering): Plattformen håndterer automatisk fordeling, sideinndeling og Bulk API-batching. For objekter med svært høye postvolumer er inkrementell CDC-modus og planlegging utenfor toppnivå de primære arkitektoniske spakene for å opprettholde gjennomløp innenfor styringsgrensebegrensninger.

Denne sjekklisten dekker minimumstrinnene for å konfigurere og validere en synkroniseringskonfigurasjon.

Sjekkliste for forhåndskonfigurasjon:

• Aktiver Endre datafangst for alle Salesforce-objekter beregnet for synkroniseringsmodus (Oppsett → Endre datafangst).
• Opprett en dedikert Snowflake-tjenestekonto med en rolle med færrest rettigheter. Gi bare nødvendige tabell- og lagerbeholdningstillatelser.
• Opprett en Snowflake-sikkerhetsintegrering hvis du bruker OAuth-godkjenning.
• Identifiser feltet Ekstern ID i hvert Salesforce-objekt som SyncIn vil bruke som oppdateringsnøkkel. Bekreft unikhet i kildedataene.

Kobling:

• Opprett godkjenningsleverandør i Salesforce (Oppsett → Godkjenningsleverandører).
• Opprett eksterne legitimasjoner og koble til godkjenningsleverandør (Oppsett → Navngitte legitimasjoner → Eksterne legitimasjoner).
• Opprett navngitt legitimasjon og koble til Ekstern legitimasjon (Oppsett → Navngitte legitimasjoner).
• Gi navngitt legitimasjon-tilgang til relevante Salesforce-profiler.

SyncOut-konfigurasjon:

• Opprett Snowflake-tilkobling (Oppsett → Analytics Studio → Databehandling → Tilkoblinger → Snowflake-tilkoblinger).
• Opprette SyncOut-konfigurasjon: kildeobjekt, måltabell, synkroniseringsmodus, felttilordninger, CDC, sporing av permanent sletting, tidsplan.
• Start med daglig synkronisering. Valider datakvaliteten og ytelsen før du øker frekvensen.

SyncIn-konfigurasjon:

• Opprett ekstern datakilde (Oppsett → Analytics Studio → Databehandling → Tilkoblinger → Snowflake-tilkoblinger).
• Opprett SyncIn-konfigurasjon: kildevisning, målobjekt, Ekstern ID-felt, felttilordninger, tidsplan.
• Synkroniser fra Snowflake-visninger, ikke rådata.

Validering:

• Se gjennom Synkroniseringsjobbovervåking etter første utførelse (Oppsett → Analytics Studio → Databehandling → Synkroniseringsjobbovervåking).
• Spørring i Snowflake-revisjonstabellen for å bekrefte at synkroniseringsmetadata ble skrevet.
• Valider permanent sletting av flagging ved å bekrefte at DEL_FLAG-kolonnen er til stede og fylt ut.
• Sammenlign antall poster mellom kilde og mål.
• Konfigurer feilmeldinger via Chatter eller e-post.

Bruk dette mønsteret når planlagt gruppesynkronisering oppfyller latenskravene, toveis dataflyt er nødvendig, og det er en prioritet å redusere teknisk avhengighet av integrasjonsoperasjoner.

Snowflake-arbeidseksempelet i denne veiledningen illustrerer hele livssyklusen: tilkoblingsoppsett, konfigurasjon, utførelsesflyt og validering. De samme prinsippene gjelder for alle støttede eksterne dataplattformer.

Når latens under 15 minutter, komplekse transformasjoner eller scenarioer for flere organisasjoner er i omfang, evaluerer du plattformhendelser, strømmede API-er eller MuleSoft som komplementære eller alternative tilnærminger.

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