Come Dynamics 365, Power Platform, Azure e Microsoft 365 si integrano, come progettare uno schema Dataverse che non ti vincoli, quando usare Power Automate rispetto a un'integrazione Azure personalizzata, come migrare i dati senza perdere una settimana in pulizia, e come collegare l'identity a tutto lo stack con Entra ID. Scritto da implementazioni reali, non da riassunti della documentazione Microsoft.
Microsoft vende molti prodotti che si sovrappongono in modo confuso. I nomi cambiano ogni pochi anni, i bundle di licenze includono funzionalità in combinazioni non intuitive, e la documentazione è vasta ma organizzata per singolo prodotto piuttosto che per i flussi di lavoro che supportano. Quello che segue è l'opposto: come i pezzi si incastrano nella pratica, le decisioni progettuali che contano e gli errori che costano più tempo da correggere in seguito.
Lo stack commerciale Microsoft ha quattro livelli distinti, e ciascuno dipende da quello sottostante. Capire in quale livello si sta lavorando indica quale prodotto usare e quali vincoli si applicano.
Le implicazioni sono pratiche. Dynamics 365 gira su Dataverse e lo include nella licenza. Power Apps e Power Automate possono connettersi a Dataverse anche senza Dynamics. Azure sta sotto a tutto e gestisce l'identity (tramite Entra ID), le integrazioni che vanno oltre ciò che Power Automate supporta, e qualsiasi elaborazione che Microsoft 365 o Power Platform non può fornire.
Microsoft 365 include SharePoint, OneDrive, Teams, Exchange e le app Office. Non include Dynamics 365 o un ambiente Dataverse di default. I due ecosistemi condividono l'identity tramite Entra ID ma sono linee di licenza separate. La maggior parte della confusione nello scoping deriva dal confonderli.
Dataverse è il database su cui girano Dynamics 365 e Power Platform. È un archivio strutturato, ospitato nel cloud, che comprende i concetti aziendali: tabelle, relazioni, campi di lookup, regole di business e ruoli di sicurezza. Non è un database relazionale generico, e non è adatto a carichi di lavoro con scritture ad alto volume. Dove eccelle è nel conservare record aziendali, applicare il controllo degli accessi a livello di riga e colonna, e fornire dati a flussi Power Automate, Power Apps e form Dynamics senza codice personalizzato.
Il design dello schema in Dataverse è dove la maggior parte delle implementazioni si prepara al successo o crea anni di rifacimento. Alcuni principi validi in ogni progetto che abbiamo realizzato:
xyz_) previene collisioni di nomi con gli aggiornamenti Microsoft. Applicalo fin dal primo giorno; il retrofitting è costoso.Sugli ambienti. Gli ambienti Dataverse sono istanze isolate con database separati. Produzione, UAT e sviluppo devono ciascuno essere un ambiente separato. Promuovere pacchetti soluzione tra ambienti (non copiare dati) è il pattern di deployment corretto. Molti team saltano questo passaggio inizialmente e lo pagano quando una modifica di sviluppo corrompe lo schema di produzione.
Dynamics 365 è disponibile in diverse applicazioni: Sales, Customer Service, Field Service, Finance, Supply Chain e altre. I due punti di accesso più comuni per le aziende in crescita sono Sales (pipeline e CRM) e Customer Service (gestione casi e supporto). Condividono lo stesso backend Dataverse e possono essere distribuiti insieme, ma ciascuno ha un modello dati distinto e una logica di processo aziendale specifica.
Sales fornisce gli oggetti CRM standard, la conversione da Lead a Opportunity, il tracciamento delle attività (chiamate, email, riunioni) e le previsioni della pipeline. Il lavoro di configurazione in una tipica implementazione Sales comprende: personalizzazione dei form Lead e Opportunity per adattarsi al tuo processo di vendita reale, configurazione del flusso di processo aziendale che governa la progressione degli stage, configurazione della sincronizzazione email e calendario con Exchange, e mappatura del modello dati del CRM legacy o dei fogli di calcolo alla struttura delle entità Dynamics.
L'errore più comune è applicare il processo di vendita Dynamics predefinito a un'azienda con un modello diverso e poi combattere lo strumento per mesi. Il flusso di processo aziendale è configurabile; l'approccio giusto è modellare i tuoi stage reali e i campi obbligatori, poi lasciare che Dynamics li applichi piuttosto che costruire workaround nei fogli di calcolo affiancati.
Customer Service è costruito attorno all'entità Case: un record di un problema cliente dall'intake alla risoluzione. La configurazione comprende le regole di routing (quali casi vanno a quali code e agenti), le definizioni SLA, la knowledge base e i form per gli agenti. Customer Service si integra anche con Teams per la collaborazione degli agenti e con Omnichannel for Customer Service se hai bisogno di instradare chat live, email e voce attraverso la stessa interfaccia.
La decisione progettuale critica è come i Case si relazionano con Account e Contact. Nella maggior parte delle implementazioni, un Case appartiene a un Contact ed è associato all'Account del Contact. Se il tuo supporto è B2B (una sola azienda, molti contatti), devi assicurarti che la vista Account mostri tutti i Case di tutti i contatti dell'azienda, non solo quello che ha aperto ogni ticket.
Power Automate è dove proviene la maggior parte dei risparmi di tempo in un'implementazione Microsoft, ed è anche dove viene creato più debito tecnico. Un flusso ben progettato è manutenibile, testabile e gestisce gli errori. Uno mal progettato è un groviglio di condizioni e azioni scope che nessuno riesce a leggere sei mesi dopo.
Alcune regole progettuali che ripagano ogni volta:
Power Apps è un builder di applicazioni low-code che si connette a Dataverse, SharePoint, SQL e centinaia di altre sorgenti dati. Produce due tipi di app: le canvas app (progetti ogni schermata tu stesso) e le model-driven app (l'app genera le schermate dallo schema Dataverse). Dynamics 365 stesso è una model-driven app; la maggior parte degli strumenti interni personalizzati sono canvas app.
Le canvas app sono la scelta giusta quando: il layout dello schermo deve essere preciso, stai costruendo su dati non Dataverse, o gli utenti sono su mobile e hanno bisogno di un'interfaccia su misura. Le model-driven app sono migliori quando: hai uno schema Dataverse complesso con molte tabelle correlate, hai bisogno delle viste, dei form e dei flussi di processo aziendali integrati, o stai estendendo Dynamics 365 stesso.
Il vincolo da conoscere prima di iniziare: le canvas app non sono un sostituto per una vera applicazione web quando hai bisogno di logica di business complessa, alta concorrenza di utenti o sofisticato controllo degli accessi a livello UI. Funzionano bene per 5-50 utenti interni che fanno inserimento e recupero dati strutturato. Oltre questo limite, di solito è meglio serviti da una web app leggera su una Azure API.
Sulle licenze. Le licenze Power Apps sono per utente al mese. Una canvas app che legge solo dati SharePoint e Microsoft 365 non richiede una licenza premium. Una canvas app che si connette a Dataverse o API esterne sì. Questa distinzione fa risparmiare costi significativi su larga scala, quindi mappa le tue sorgenti dati prima di acquistare.
Power Automate gestisce la maggior parte dell'automazione dei flussi di lavoro. Quando hai bisogno di qualcosa che non può fare in modo affidabile, Azure è la risposta. I casi in cui scegliamo Azure invece di Power Automate:
Logic Apps e Power Automate condividono la stessa libreria di connettori e lo stesso linguaggio di espressioni. Logic Apps è la scelta giusta quando hai bisogno che l'integrazione giri in un'area geografica Azure specifica, richiedi SLA enterprise, devi integrarti in una pipeline di deployment Azure DevOps, o hai requisiti di conformità che precludono l'archiviazione dei dati nel tenant cloud Power Platform.
Entra ID (ex Azure Active Directory) è la dorsale di identity dello stack commerciale Microsoft. Ogni utente Microsoft 365 e Dynamics 365 si autentica attraverso di esso. Se vuoi single sign-on su tutti i tuoi strumenti SaaS, policy di accesso condizionale o accesso guest per collaboratori esterni, Entra è dove lo configuri.
Il lavoro pratico in una tipica implementazione copre tre aree. Prima, verificare che tutti gli utenti siano provisionati in Entra e che le licenze siano assegnate correttamente, perché un utente mal configurato incontrerà errori confusi in Teams, SharePoint e Dynamics. Seconda, configurare le policy di accesso condizionale: richiedere l'autenticazione a più fattori, limitare l'accesso da dispositivi non gestiti per le app sensibili e bloccare l'accesso da posizioni ad alto rischio. Terza, configurare le enterprise application per qualsiasi SaaS non Microsoft che supporta la federazione SAML o OIDC, in modo che gli utenti accedano a tutto con le credenziali Microsoft.
Per le aziende con utenti ospiti (collaboratori, clienti, partner), gli account guest Entra B2B consentono di invitare identità esterne a specifici canali Teams, siti SharePoint o persino specifiche viste Dynamics, senza dare loro accesso completo da dipendente. Il confine delle autorizzazioni è applicato a livello Entra, non a livello applicativo, il che è più affidabile.
Microsoft 365 è il livello di collaborazione su cui la maggior parte delle aziende già opera. Il lavoro che facciamo qui in un progetto di implementazione Microsoft è meno sull'attivazione di Teams e più sul renderlo utile in relazione a Dynamics e Power Platform.
Le due integrazioni che offrono più valore sono l'app Dynamics 365 per Teams e i flussi Power Automate che portano gli eventi Dataverse nei canali Teams. L'app Dynamics consente ai team di vendita e supporto di visualizzare e modificare i record CRM senza uscire da Teams, il che è importante per le aziende dove Teams è la superficie di comunicazione principale. Il pattern delle notifiche nei canali significa che un nuovo lead, una trattativa chiusa o un'escalation di un caso possono comparire come scheda nel canale Teams appropriato con il contesto rilevante, sostituendo la catena manuale di email.
SharePoint merita una nota specifica. SharePoint è eccellente per l'archiviazione di documenti, i contenuti intranet e le liste strutturate. È un cattivo sostituto di Dataverse quando hai bisogno di dati relazionali, sicurezza a livello di riga o più di poche migliaia di elementi in una lista. Vediamo molti team cercare di gestire i processi aziendali su liste SharePoint perché hanno già la licenza, per poi scontrarsi con i limiti delle colonne, la soglia di 5.000 elementi nella vista e la mancanza di relazioni calcolate. Dataverse è lo strumento giusto per i dati aziendali strutturati; SharePoint è lo strumento giusto per documenti e contenuti.
Power BI si connette a Dataverse, SharePoint, SQL, Excel e alla maggior parte delle API cloud, e mostra i dati in dashboard incorporabili in Teams, SharePoint o un URL pubblico. In un'implementazione dello stack Microsoft, il lavoro di reporting copre tipicamente tre livelli: dashboard operative per la visibilità quotidiana (pipeline per stage, casi aperti per team), report gestionali (win rate, tempi di risoluzione, utilizzo licenze) e riepiloghi esecutivi che aggregano più sorgenti dati.
La decisione progettuale più importante è se usare la modalità DirectQuery o Import. La modalità Import carica i dati nel motore in-memory di Power BI e li aggiorna su pianificazione, tipicamente una o più volte al giorno. È più veloce per la maggior parte dei tipi di query e gestisce meglio dataset più grandi. DirectQuery invia query direttamente alla sorgente al caricamento del report, il che fornisce dati in tempo reale ma è più lento e carica di più Dataverse. Per i dati Dynamics 365 che non devono essere in tempo reale al minuto, Import con refresh orario è di solito il compromesso migliore.
Sulla sicurezza a livello di riga. Se i tuoi report Power BI mostrano dati che utenti diversi devono vedere solo in parte (i commerciali vedono la propria pipeline, i manager vedono il loro team, i direttori vedono tutto), configura la sicurezza a livello di riga nel dataset Power BI, non creando report separati. Un report con sicurezza a livello di riga applicata al dataset è manutenibile; venti report varianti per ruoli diversi non lo sono.
La migrazione dei dati è dove la maggior parte delle timeline di implementazione Microsoft slittano, e quasi sempre perché i dati sorgente erano peggiori di quanto chiunque pensasse. La conversazione standard di discovery con un cliente sui dati del CRM legacy o del foglio di calcolo tende a rivelare: record Contact duplicati con ortografie diverse, numeri di telefono in più formati, valori degli stage di trattativa che si mappano vagamente al nuovo processo di vendita, e file allegati non referenziati da nessun campo record.
Un processo realistico di migrazione dati ha cinque passaggi. Prima, un'estrazione dei dati sorgente nella loro forma grezza, senza pulizia manuale. Seconda, un passaggio di profiling: contare i valori nulli, i duplicati, le violazioni di formato e i gap di integrità referenziale. Terza, un documento di mappatura che specifica, per ogni campo sorgente, quale campo Dataverse corrisponde, quale trasformazione si applica e cosa fare con i valori che non si mappano in modo pulito. Quarta, un import di prova in un ambiente sandbox, validato rispetto ai numeri del profiling. Quinta, l'import in produzione con una cattura delta per tutti i record cambiati durante la finestra di migrazione.
Lo strumento che usiamo per la maggior parte delle migrazioni Dataverse è la funzione di import dati Dataverse per dati flat semplici, e Azure Data Factory per migrazioni multi-tabella più complesse o per dati che richiedono trasformazioni significative prima di poter essere caricati. Power Query (presente sia in Power BI che in Power Automate) gestisce il lavoro di trasformazione più leggero.
La fase più importante da proteggere è il design dello schema. Le modifiche al modello di entità Dataverse dopo che i dati sono stati migrati richiedono rimappatura, re-import e ripetizione dei test su flussi e form interessati. Due settimane di lavoro attento sullo schema inizialmente risparmia quattro settimane di rifacimento in seguito. Ogni progetto di implementazione che abbiamo realizzato in anticipo sui tempi lo ha fatto perché lo schema era bloccato prima dell'inizio della configurazione.
Lo user acceptance testing è l'altra fase che viene compressa quando le timeline slittano. L'UAT non è solo una casella da spuntare prima del go-live; è l'ultimo punto in cui un flusso di processo aziendale mal configurato o un'integrazione interrotta possono essere individuati prima di influire sui dati dei clienti reali. Costruiamo gli script UAT dalle mappe dei processi create durante lo scoping, in modo che gli utenti testino scenari reali, non improvvisando.
Una breve lista dei pattern che causano costantemente il blocco o il fallimento dei progetti:
Questo è l'intero metodo. Quando vuoi applicarlo alla tua organizzazione, il prossimo passo è un audit gratuito: una vera analisi del tuo stack Microsoft attuale, dei tuoi processi e dei gap esistenti, in circa due giorni, senza alcun impegno.
Un audit gratuito del tuo stack Microsoft attuale, i risultati scritti e un ambito fisso per costruire ciò che conta. Risultati in 48 ore.
Richiedi un audit Microsoft gratuito