Un venditore aggiorna l'indirizzo di un cliente. Più tardi, l'ufficio finanziario apre lo stesso record e vede ancora culo vecchio. Quindi, quale indirizzo è corretto? Per anni, risolvere la situazione significava esportare dati, modificare un foglio di calcolo, inviarlo via email e digitare lo stesso aggiornamento due volte in una seconda. La doppia scrittura dual write di Dynamics Tre Cose Collega le app di finanza e operatività con le app per i clienti basate su Dataverse, così i record condivisi come clienti e ordini restano sincronizzati automaticamente. Si è decommesso un'omilco peters di M365FM e questa pillola di conoscenza spiega la doppia scrittura in modo semplice. Vedremo cosa si sposta, come si sposta, dove si adatta alla doppia scrittura e dove invece non è adatta. Per prima cosa iniziamo con il problema aziendale che ha creato la necessità di tutto ciò. Il problema che la doppia scrittura risolgo Immaginate un'azienda in cui due gruppi lavorano sullo stesso cliente ma usano app completamente diverse ogni giorno.

Le app di finanza e operatività gestiscono il lavoro di back-off. Si tratta di denaro, scorte, prodotti, ordini, acquisti e catena di distribuzione. È qui che un'azienda tiene traccia di ciò che vende, di ciò che può consegnare, di ciò che deve e di ciò che un cliente deve pagare. Le app per i clienti si concentrano sul lavoro a stretto contatto. I team di vendita seguono i lead e creano opportunità. Il servizio clienti gestisce domande e casi. L'assistenza sul campo pianifica interventi e invia personale l'ho. I team di progetto seguono il lavoro promesso a un cliente. Lavori diversi richiedono schermate diverse. Un venditore non dovrebbe dover cercare una schermata finanziaria solo per aggiornare un contatto dopo una chiamata. Ma un utente dell'area finanziaria ha bisogno di dettagli su clienti e ordini che corrispondano a quelli delle vendite, perché fatture e consegne dipendono da quelle informazioni.

Senza una connessione, un cliente diventa silenziosamente due record. Le vendite potrebbero elencare Northwind Bikes e l'amministrazione potrebbe elencare Northwind Bicycle Company. Un record al nuovo indirizzo, l'altro invia ancora fatture al vecchio ufficio, al vecchio fine. Entrambi i record sembrano ragionevoli singolarmente, ma non descrivono più lo stesso rapporto commerciale. Piccoli problemi emergono per primo. Qualcuno non riesce a trovare un cliente perché il nome è diverso in un'altra app. Un venditore promette un prezzo controllo e scorte, ma le informazioni non corrispondono al lato operativo. L'ufficio finanziario deve elaborare un ordine, ma i dettagli dei clienti richiedono un controllo, un'email e un altro aggiornamento manuale. Poi quei piccoli problemi si accumulano. Qualcuno esporta i dati dei clienti in un foglio di calcolo. Un'altra persona correggere alcune righe e le importa da qualche altra parte.

Qualcun altro inserisce un nuovo cliente in entrambe le app perché nessuno sa quale record apparirà per primo. Presto ci sono duplicati, indirizzi diversi e più tempo speso a controllare i dati che a usarli. Tutto questo non accade perché le persone sono negligenti. Accade perché i sistemi chiedono alle persone di fare da collegamento. Le persone gapino i dati. Le persone devono ricordare quale app usare per primo. Le persone notano gli errori solo dopo che hanno raggiunto un altro team. Quell'approccio funzionava quando i sistemi aziendali restavano separati e i team accettavano i ritardi. Ma quando vendita, assistenza, finanze e operazioni necessitano delle stesse informazioni sul cliente durante il giorno, un foglio di calco diventa un pessimo strumento di passaggio. Pensiamo a una semplice conversazione riguardante o no. Il cliente chiama l'ufficio vendita e chiede come potete consegnare la prossima settimana.

Quanto costerà? Il team di vendita ha bisogno dei dettagli su prodotto, prezzo e disponibilità per rispondere. Una volta che il cliente accetta, finanze e operazioni hanno bisogno delle corrette informazioni su cliente e ordine per elaborare la vendita. Entrambe le parti hanno bisogno di stessità. Le vendite necessitano di quei dati nell'app in cui lavorano i venditori. Finanze e operazioni ne hanno bisogno nell'app in cui gestiscono ordini, denaro e consegne. L'obiettivo non è costringere ogni team, ma usare un'unica schermata gigante. L'obiettivo è far sì che i record condivisi seguano un percorso chiaro e concordato. È qui che entra in gioco il DualWrite. Cos'è esattamente il DualWrite? Ecco la definizione più semplice. Il DualWrite è la connessione integrata di Microsoft che mantiene sincronizzati i dati selezionati tra le app di Dynamics 365, Finance & Operations e Dataverse. Dataverse è la base dati condivisa che supporta molte app aziendali Microsoft.

Dynamics 365 Sales, Customer Service, Field Service e parti di Project Operations la utilizzano. Anche Power Apps e Power Automate possono usare. Non è necessario sapere come data verso archivi ogni singolo record per comprendere il DualWrite. Basta pensarlo come l'area dati comune sul lato delle app per i clienti di Dynamics 365. Immaginiamo un edificio per uffici con un front office e un back office. Front office gestisce le conversazioni con i clienti. Venditore, agenti di assistenza, persone sul campo. Tutti hanno bisogno di schermate che le aiutino a parlare con le persone, tracciare le richieste e gestire le app. Il back office gestisce il lavoro che mantiene l'azienda operativa. I nostri registri finanziari, le scorte, gli ordini, gli acquisti, le consegne. Entrambi gli uffici lavorano per la stessa azienda, ma senza una connessione adeguata tra loro qualcuno deve portare le informazioni da una parte all'altra.

Portano un modulo stampato, invierono un email o copiano i dati in un altro sistema. Il lavoro viene comunque completato, ma richiede più tempo e i dettagli possono cambiare lungo il percorso. Il DualWrite è come una porta interna presidiata tra cui due uffici. Quando un record supportato cambia da una parte, DualWrite trasmette la modifica correlata attraverso quella porta all'altra parte. Non combina ogni app in un'unica enorme applicazione. Le vendite possono continuare a lavorare, la finanza può continuare a lavorare nella finanza. Ogni team mantiene schermate create per il proprio lavoro, mentre le informazioni condivise e selezionate rimangono collegate dietro le qui. Quel termine supportato è importante. DualWrite non copia ciecamente ogni dato in entrambi i sistemi. Funziona tramite connessioni definite tra record che appartengono l'uno all'altro. Microsoft chiama queste connessioni mappe di tabella.

Una tabella è semplicemente un luogo in cui un'app conserva un tipo di record. Una tabella clienti conserva i record dei clienti. Una tabella prodotti conserva i record dei clienti. Una tabella indirizzi conserva i dettagli indirizzi. Una mappa di tabella indica a DualWrite quale tabella sul lato Finance and Operations si collega a quale tabella in Dataverse. Pensa a una mappa di tabella come un foglio di traduzione concordata. Una colonna identifica un record su un lato. Un'altra colonna identifica il suo record corrispondente sull'altro lato. Il resto del foglio spiega quali campi appartengono l'uno all'altro. Nome e numero di telefono rigade all'indirizzo. Quell'accordo fornisce le regole di connessione. Senza di esso, due app potrebbero usare etichette diverse o archiviare lo stesso dettaglio in posti diversi. Una mappa indica a DualWrite come si relazionano quei dettagli. Quindi le app non hanno bisogno di persone che le interpreti ogni volta.

Ora, spesso le persone sentono il nome DualWrite e presumono che significhi che ogni modifica si sposta sempre in entrambe le direzioni. A volte è così. Per una mappa bidirezionale supportata, una modifica in Dataverse può aggiornare il record correlato in Finance and Operations. Una modifica supportata in Finance and Operations può anche aggiornare il record correlato in Dataverse. Entrambi i lati possono partecipare allo stesso record con di. Questa è la parte Dual. L'aggiornamento avviene quasi in tempo reale. Si muove rapidamente mentre le persone lavorano invece di attendere un processo programmato che viene eseguito durante l'anno. Un utente aggiorna un record supportato e la connessione invia quell'aggiornamento mentre il lavoro è ancora in corso. Quasi in tempo reale non significa magia o ritardo zero. Significa che la connessione è creata per il lavoro aziendale dal vivo, non per uno scambio di file una volta al giorno.

Se qualcuno modifica un dettaglio, il team correlato non deve aspettare domani mattina per vederlo. Ciò cambia il modo in cui i team possono lavorare. Il front office può utilizzare i dati provenienti dal back office. Può ricevere aggiornamenti supportati dalle app rivolte al cliente. Dataverse diventa la base dati da un lato, Finance and Operations rimane la base operativa dall'altro e DualWrite mantiene collegati i record condivisi e approvati. Tuttavia, una porta interna attiva ha bisogno di regole. Prima di lasciare che un record viaggi in entrambe le direzioni, devi sapere dove dovrebbe iniziare, chi può modificarlo e quale lato dovrebbe prevalere quando le due app non sono d'accordo. Quali dati possono essere trasferiti e quale sistema ne ha le proprietà. Quindi, quali record può mantenere connessi DualWrite? Gli esempi comuni iniziano con i record che molti reparti condividono ogni giorno.

Record dei clienti, indirizzi, contatti e prodotti, fornitori, dettagli aziendali e informazioni di riferimento utilizzate per finanza e tasse. Pensiamo per un momento al record di un cliente. Le vendite necessitano del nome del cliente, contatto principale, del numero di telefono e dell'indirizzo di consegno. La finanza necessita del record legale del cliente, dei dettagli di fatturazione e delle informazioni per ordine fatture. Se ogni reparto mantiene il proprio elenco clienti separato, l'azienda perde tempo a confrontare i record invece di servire il cliente. Con le giuste mappe DualWrite, quei team possono lavorare su dettagli cliente connessi. Ciò non significa che gli utenti delle vendite debbano improvvisamente imparare l'app fan. Significa che possono lavorare con le informazioni del cliente Dynamics 365 e Sales. Mentre gli utenti Finance lavorano con le relative informazioni in Finance.

Il cliente rimane riconoscibile come lo stesso cliente in entrambi i luoghi. Anche gli indirizzi sono importanti. Un cliente può avere un indirizzo di fatturazione o uno di consegna, magari una sede in cui deve recarsi un tecnico dell'assistente. Questi dettagli non possono essere trattati come semplice testo copiato in una casella perché ogni indirizzo ha una funzione diversa. DualWrite supporta la struttura di record condivisa necessaria per tale rettore. I contatti seguono lo stesso scato. Un'azienda cliente può avere un acquirente o un contatto per la contabilità fornitori o un responsabile dell'assistente. Le vendite devono sapere chi prende le decisioni. La finanza deve sapere a chi indirizzare le domande sulla fatturazione. L'assistenza deve sapere chi sta aspettando il sede. I record connessi aiutano ogni team a vedere le persone collegate al cliente senza dover ricreare tale informazione in ogni app.

I prodotti sono un altro esempio comune. Un commerciale deve sapere cosa vende l'azienda, quanto costa il prodotto e se è disponibile a magazzino. Quelle risposte arrivano solitamente dal lato operativo dell'azienda perché è lì che si gestiscono prodotti, stock, acquisti e ordini. Ecco perché le informazioni di prodotto iniziano spesso in Finance and Operations. Un team operativo crea e prepara un prodotto in quella sede. Una volta che il prodotto è pronto per il lavoro con i clienti, DualWrite può inviare i relativi dettagli di prodotto in Dataverse. Gli utenti delle vendite possono quindi selezionare e discutere il prodotto nella propria app senza dover inserire l'elenco prodotti una seconda volta. Questo aiuta a mantenere le conversazioni di vendita basate su ciò che l'azienda può effettivamente fornire. Anche i dettagli di prezzo inventario possono raggiungere le vendite tramite le app connesse.

Invece di indovinare se un articolo esiste, se il prezzo è cambiato o se lo stock supporta una promessa, il team di vendita lavora su informazioni legate al lato operativo. Ciò non elimina la necessità di un buon giudizio nelle vendite. Elimina un motivo evitabile per cui un rappresentante commerciale deve telefonare al magazzino solo per confermare dettagli di base. Anche le informazioni sui fornitori possono connettersi dove un processo aziendale richiede. Dettagli aziendali, strutture organizzative, dati di riferimento finanziari e fiscali possono essere rilevanti sia per il lato cliente che per quello operativo. I record esatti dipendono dalle app e dai processi utilizzati dall'azienda, ma lo schema rimane lo stesso. Condividi i record che devono significare la stessa cosa in entrambi i luoghi. Non dare per scontato che ogni record debba viaggiare in entrambe le direzioni. Cune app supportano aggiornamenti bidirezioni.

Una modifica può iniziare in Dataverse e passare a Finance and Operations o iniziare in Finance and Operations e passare a Dataverse. Questo approccio si adatta ai record in cui entrambe le parti hanno una valida ragione aziendale per aggiornare i dettagli approvati. Altre mappe sono in ogni direzione. I prodotti ci offrono un esempio utile. In molte aziende, Finance and Operations gestisce la creazione del prodotto perché le operazioni controllano l'anagrafica, le scorte, le unità e altri dettagli necessari per la vendita e la consegna. Il prodotto fluisce poi verso Dataverse dove i team di vendita e assistenza possono utilizzarlo. Questa è una regola chiara. Il prodotto non necessita di due team che creano versioni in competizione. Una parte crea e gestisce il prodotto, l'altra lo riceve e lo utilizza come parte del proprio lavoro. Ogni record condiviso richiede questo tipo di decisione.

Dove ha origine questo record? Chi può modificare? Se un nome, un indirizzo, un prezzo o una classificazione sembrano errati, quale team interviene? Queste domande sembrano semplici ma prevengono molta confusione in futuro. Una connessione può propagare una modifica molto rapidamente. Se nessuno ha stabilito chi sia responsabile della modifica può propagare un errore adattività. Scegni un proprietario per il record e, quando necessario, per i singoli dettagli al suo interno. Ad esempio, le vendite potrebbero gestire i dettagli della relazione con il cliente e le informazioni di contatto privato. L'amministrazione potrebbe gestire i dettagli dei tipi ai vagamenti. L'operazione potrebbe gestire i dettagli dei prodotti. La ripartizione esatta dipende da come opera la tua azienda, ma deve essere documentata e compresa da chi utilizza le app. Ci sono anche due termini che potresti incontrare dopo che la scrittura doppia, expande Dataverse Party e Company.

Un Party è il modo in cui Microsoft gestisce una persona o un'organizzazione in modo coerente. Aiuta a collegare persone, organizzazioni, contatti e indirizzi senza trattare ogni relazione come un record separato e non correlato. Una company aiuta Dataverse a comprendere il contesto aziendale utilizzato da Finance and Operations. Non è necessario diventare esperti in nessuno dei due termini fin dal primo. Sappi solo che esistono, perché Finance and Operations gestisce strutture aziendali che le app per i clienti devono riconoscere quando i record passano da una parte all'altra. Una volta che i record possono viaggiare in entrambe le direzioni, il processo che li circonda è importante tanto quanto i dati stessi. Come viaggio la modifica tra le app? Seguiamo una modifica nel sistema e vediamo cosa succede realmente. Un addetto alle vendite è il telefono con un cliente che si è appena trasferito in un nuovo ufficio.

Durante la conversazione, l'addetto apre il record del cliente in Dynamics 365 Sales e aggiorna l'indirizzo stradale. Abbastanza semplice, vero? Poi salva il record. È qui che inizia la parte interessante. Sales memorizza quella modifica in Dataverse, ovvero il lato dati per le app rivolte ai clienti. Quindi il DualWrite controlla la mappa che collega le informazioni sul cliente e sull'indirizzo tra questo sito e Finance & Operations. Invia automaticamente la modifica corrispondente. Nessun file di esportazione fermo in una cartella condivisa in attesa che qualcuno lo prende. Nessuno deve inviare un'email a Finance con una nota del tipo Ehi, per favore, aggiorna questo indirizzo. La mappa sa già quali campi sono collegati. Invia la modifica supportata direttamente al record cliente correlato in Finance & Operations. Quindi un utente Finance può aprire quel record cliente in seguito, vedere l'indirizzo aggiornato ed elaborare un ordine o preparare una fattura senza perdere tempo.

Questo è il risultato pratico, semplice e chiaro. Due persone continuano a lavorare in app diverse, ma nessuna deve riscrivere gli stessi dettagli del cliente. L'addetto alle vendite lavora su una schermata progettata per le conversazioni con i clienti. L'utente Finance lavora su una schermata creata per il lavoro finanziario. Ogni persona vede le informazioni sul cliente di cui ha effettivamente bisogno, esattamente dove le serve. E il viaggio funziona anche nella direzione opposta. Immagina che Finance aggiorna le informazioni supportate del cliente in Finance & Operations. Supponiamo che un utente Finance corregga un dettaglio che appartiene al record cliente operativo. I DualWrite utilizza la mappa corrispondente al contrario e invia tale aggiornamento correlato a Dataverse. Poi Sales, Customer o qualsiasi altra app basata su Dataverse può riprenderlo. Questa connessione è sincrona per il normale lavoro quotidiano.

Sincrono significa che le app cercano di completare l'aggiornamento correlato nello stesso momento lavorativo invece di inserirlo in un processo in background che potrebbe essere eseguito 20 minuti dopo. Se la connessione non riesce a completare l'aggiornamento, il problema richiede attenzione immediata, non deve nascondersi silenziosamente affinché qualcuno nota una discrepanza. Questo comportamento ha senso per i record aziendali condivisi. Non vuoi che un indirizzo cliente, un dettaglio prodotto o altre informazioni condivise divergano per ore perché un processo bacio non è ancora stato avviato. Le persone prendono decisioni basandosi su ciò che vedono sullo schermo in questo momento. Quindi la connessione mantiene entrambi i lati allineati mentre il lavoro è in corso. Il lavoro attivo a volte richiede una pausa controllata. DualWrite include opzioni di riproduzione, pausa e recupera.

Riproduzione significa che la mappa è attiva e le modifiche supportate vengono trasferite normalmente. La pausa interrompe temporaneamente la mappa quando un team deve eseguire interventi pianificati, indagare su un problema o gestire una modifica in sicurezza. Ma la pausa non è uno spazio di permanente. Mentre una mappa è in pausa, le modifiche possono accodarsi per un tempo o uno spazio limitato. Quando la mappa riprende, recupera o elabora le modifiche in attesa, ciò aiuta il team a riprendersi dopo un'interruzione pianificata. Tuttavia, qualcuno deve gestire tale pausa e sapere quando la mappa deve riprendere a funzionare. Prima che tutto ciò inizi nel lavoro quotidiano, c'è un altro passaggio, la sincronizzazione iniziale. La sincronizzazione iniziale porta i record esistenti da entrambi i lati a un punto di partenza condiviso. Pensa a un'azienda che ha già clienti in Finance and Operations e Record Client in Dataverse.

La connessione non può semplicemente attivarsi e presumere che ogni record esistente corrisponda già perfettamente. Serve una linea di partenza. La sincronizzazione iniziale aiuta a trasferire i dati esistenti prima che le persone si affidino agli aggiornamenti in tempo reale. Questo lavoro richiede attenzione, perché record duplicati, indirizzi incompleti e vecchi dati di test non si puliscono magicamente solo perché si avvia una sincronizzazione. Possono effettivamente creare problemi più velocemente se i record non seguono le regole concordate. Una volta che le mappe sono in esecuzione, le persone che gestiscono DualWrite hanno bisogno di luogo chiaro per verificarne lo stato di salute. DualWrite fornisce log combinati di attività ed errori così gli amministratori possono vedere cosa ha elaborato la connessione e dove ha riscontrato problemi. Possono anche impostare avvisi e soglie. Il che significa che le persone giuste vengono a conoscenza dei problemi prima che gli utenti riscoprano a causa di un aggiornamento mancato o fallito.

Quella visione di supporto è importante perché ogni errore ha una causa. Forse manca un campo obbligatorio. Forse un record correlato non è ancora arrivato. Forse qualcuno ha modificato i dati in un modo non compatibile con la mappa. Riprovare un record fallito senza correggere la causa di solito porta solo allo stesso errore. Una configurazione DualWrite ben gestita monitora la connessione, correggere la causa degli errori e mantiene le mappe focalizzate sui record che devono restare connessi. Dove dual rights e adattamenti. DualWrite è ideale quando la tua azienda utilizza Dynamics 365 Finance Supply Chain Management insieme ad app rivolte ai clienti come Sales, Customer Service, Field Service, Field Service o Project Operations. Queste app supportano diverse parti della stessa conversazione aziendale. Un team parla con il cliente, un altro pianifica la consegna, gestisce lo stock, traccia i costi o invia la fattura.

Quando entrambi i gruppi devono lavorare su record correlati durante il giorno la scrittura doppia DualWrite o collegare quel lavoro senza costringere tutti ad usare la stessa app. Prendiamo come esempio il processo da prospecto in caso. Un addetto alle vendite lavora con potenziale cliente in Dynamics 365 6. Traccia il contatto, discute i prodotti, crea un preventivo e procede verso un ordine. Durante quella conversazione il venditore ha bisogno di dettagli sul cliente, informazioni sui prodotti, prezzi e dati sull'ordine relative al settore finanziario dell'azienda. Una volta che la vendita diventa concreta, la gestione finanziaria e della catena di distribuzione assume il lavoro che segue la promessa. Si occupa dell'evasione dell'ordine e della fatturazione delle scorte e delle scorte finanziarie. La scrittura doppia aiuta queste due parti a rimanere connesse. I venditori possono lavorare nell'app cliente adatta al loro ruolo, mentre finanze e operazioni gestiscono la transazione nell'app creata per il loro lavoro.

Il cliente non diventa due storie separate, una raccontata dalle vendite e l'altra dalla finanza. Feel Service offre un altro buon esempio. Immagina un'azienda che invia tecnici per installare, riparare o mantenere apparecchiature presso le sedi dei clienti. Il tecnico sul campo ha bisogno di dettagli sul cliente, dettagli sul lavoro e informazioni sull'asse del cliente relativo all'articolo installato supportato dall'azienda. Dietro le quinte l'azienda deve anche tracciare pezzi, costi, acquisti e il denaro legato a quel lavoro. Feel Service si concentra sulla pianificazione e sul compito della visita. Finanze e operazioni si concentrano sul record operativo e finanziario ad essa correlato. Quando quei record sono collegati correttamente, il lavoro di un tecnico non rimane separato dai pezzi utilizzati, dal costo del lavoro, dal record cliente a esso connesso. Project Operations segue lo stesso schema, specialmente per le aziende che vendono un lavoro basato su progetti.

Un team di progetto potrebbe gestire il lavoro del cliente, il tempo delle persone, i costi pianificati e le tappe fondamentali del progetto. La finanza deve vedere il lato finanziario di acquisti, i costi, fatturazione e reportistica. Senza una connessione, i project manager possono perdere troppo tempo a inseguire la finanza per gli aggiornamenti, mentre la finanza attende che i team di progetto confermino quanto accaduto. I record di progetto connessi offrono a entrambi i gruppi una visione più chiara del lavoro, mentre passa da promessa del cliente ad attività finanziarie. C'è anche un vantaggio più ampio della Power Platform, perché il lato dell'app cliente utilizza Dataverse, quindi i dati approvati in Dataverse possono supportare Power Apps e Power Automate. Un'azienda potrebbe costruire una piccola app per un team interno o creare un flusso che risponde quando un record aziendale raggiunge un certo punto.

Ciò non significa che ogni record di finanza e operazioni appartenga improvvisamente a ogni Power App. Significa che i record collegati possono far parte di un insieme più ampio di strumenti aziendali, a patto che l'azienda scelga tale scopo con cura e protegga i dati in modo adeguato. Un confine deve rimanere ben chiaro. DualWrite non supporta Dynamics 365 e Business Central. Business Central può connettersi ad altri prodotti Microsoft tramite altri metodi, ma DualWrite è pensato per l'ambito Finance and Operations di Dynamics 365 e per le app basate su Dataverse. Non è uno strumento per copiare ogni tabella che trovi. Un record dovrebbe essere trasferito perché è necessario avere lo stesso dato operativo in entrambi i luoghi, non perché copiare i dati sembra più sicuro. DualWrite non sostituisce un piano di integrazione più ampio quando un'azienda necessita di flussi di reportistica, collegamenti a sistemi terzi o migrazioni di grande volumidità.

Trattare ogni connessione ai dati come lo stesso tipo di lavoro crea problemi rapidamente. Limiti, preparazione ed errori comuni. Pensa a DualWrite come un accordo di stretta di mano tra due sistemi. Accettano di mantenere sincronizzati determinati record condivisi, ma non è un canale magico per ogni tabella, report o sistema esterno. Prima di configurarlo, verifica quali integrazioni esistono già. Se è una vecchia connessione DualWrite, aggiornano entrambi lo stesso record cliente e puoi creare conflitti in fretta. È un grattacapo di cui non è bisogno. Quindi concorda prima le basi. Come inserirete no? Quale entità legale possiede ogni record? Ti può portare modifiche. Di quali ruoli di sicurezza bisogna ogni team? Rimuovi i duplicati e i record incompleti prima sincronizzazione. Inizia con le mappe predefinite di Microsoft. Collegano già i record più comuni. Per tabelle e campi personalizzati serve un test accurato.

Controlla le tabelle correlate e le dipendenze delle mappe, perché a volte un record deve avere un altro già esistente per poter essere sincronizzato. Benifica la prima sincronizzazione in base alla quantità di dati che possiede. Non trattarla come un interruttore della luce ad azionare durante la posa prima. Creerebbe di problemi. Una mappa in pausa necessita comunque di un responsabile di un piano. Le modifiche in coda e i record falliti non restano lì per sempre. Monitora i log delle attività, gli errori, gli avvisi, le soglie. Quando qualcosa fallisce, individua il campo mancante, il record errato o la regola infranta alla base. Ripetuti i tentativi non ripareranno da terra. Quando vedi DualWrite come un ponte controllato, tutto torna al suo posto. In conclusione, unica conversazione aziendale condivisa. DualWrite mantiene i record condivisi supportati in movimento tra finance e operations e le tue app basate su Dataverse.

In questo modo i team possono lavorare con dati aziendali connessi. Iscriviti sulla tua piattaforma di podcast preferita per ulteriori pillole di conoscenza con me, Mirko Peters, su M365FM. E condividi questo episodio con chi connette ancora vendite, assistenza e finanza tramite l'ennesimo foglio di calcolo.