Il business process flow come guida al ciclo di vendita

Un business process flow (BPF) in Dynamics 365 Sales è una struttura visuale che accompagna il venditore lungo le fasi del ciclo commerciale, garantendo che i dati critici vengano raccolti in modo coerente prima di avanzare. Non è codice di automazione: è un livello di guidance costruito su Microsoft Dataverse, che ogni BPF materializza in una propria tabella di istanze per tracciare la fase attiva di ciascun record.

Il BPF di riferimento è Lead to Opportunity Sales Process, un flusso multi-entity che attraversa la tabella Lead e poi la tabella Opportunity: tipicamente Qualify → Develop → Propose → Close. Un singolo BPF può coprire fino a 5 tabelle e contenere fino a 30 stage: è così che si modella una pipeline che nasce da un contatto grezzo e prosegue come trattativa.

Componenti: stage, step, data step e branching

  • Stage: le macro-fasi (Qualify, Develop, ecc.). A ogni stage è associata una Entity (la tabella su cui insistono i suoi step). Il passaggio a uno stage collegato a un’altra tabella innesca la transizione multi-entity.
  • Step / data step: i campi che il venditore compila all’interno di uno stage. Un data step è legato a una colonna della tabella; marcandolo come Required, l’utente non può passare allo stage successivo senza valorizzarlo. Uno step non required resta puramente indicativo.
  • Branching condizionale: rami alternativi definiti da condizioni sui dati (es. se Budget Amount supera una soglia, instrada verso uno stage di approvazione). Il branching è client-side, valutato in tempo reale mentre il record cambia.

Più BPF sulla stessa tabella: ordine e sicurezza

Una tabella può avere più BPF attivi contemporaneamente. Due leve decidono quale viene applicato:

  1. Process Order (Order Process Flow): definisce la priorità. A un nuovo record viene assegnato il primo BPF nell’ordine a cui l’utente ha accesso.
  2. Sicurezza tramite security role: ogni BPF può abilitare Enable Security Roles, così solo i ruoli autorizzati lo vedono e possono attivarlo. Se un venditore non ha accesso al BPF in cima all’ordine, riceve automaticamente il primo BPF successivo consentito.

L’utente può poi usare Switch Process per passare manualmente a un altro BPF applicabile. Attenzione: cambiare processo modifica lo stato del record rispetto al flusso — la fase attiva viene ricalcolata sulla nuova definizione, e i data step del vecchio BPF non required non vengono “portati” nel nuovo percorso.

BPF vs Power Automate e classic workflow

Il BPF guida, non esegue. Non invia email, non aggiorna record di terze parti, non fa calcoli in background. Quando serve automazione, la scelta corretta è:

  • Power Automate (cloud flow) per logica asincrona/integrazioni (notifiche, creazione record correlati, chiamate ad API). È lo standard attuale.
  • Classic workflow solo su scenari legacy: è tecnologia in disuso, da non proporre in design nuovi.

Un pattern maturo combina i due: il BPF struttura le fasi e le colonne obbligatorie, mentre un Power Automate in trigger sul cambio di stage (colonna Process Stage/Active Stage) esegue le azioni. Chiedersi sempre: “serve accompagnare una persona o eseguire un’azione?” — la prima è BPF, la seconda è Power Automate.

Trappole tipiche d’esame

  • Scenario: il management vuole impedire l’avanzamento oltre “Qualify” senza budget stimato. → Rendere il data step Required su quello stage; un BPF non blocca campi lasciati facoltativi, quindi step non required = nessun vincolo.
  • Scenario: serve inviare un’email automatica quando l’opportunity entra in “Propose”. → Power Automate su cambio stage, non il BPF: il BPF da solo non compie azioni.
  • Scenario: due team di vendita necessitano di pipeline diverse sulla stessa tabella Opportunity. → Creare due BPF con Enable Security Roles distinti e sistemare il Process Order; il primo accessibile diventa il default per il ruolo.
  • Scenario: un venditore usa “Switch Process” a metà trattativa e teme di perdere lo stato. → Il record resta, ma la fase attiva viene ricalcolata sul nuovo BPF; i dati delle colonne restano, ma il percorso e gli step required cambiano.
  • Scenario: si vuole un flusso che parta dal Lead e continui sull’Opportunity in un unico processo. → Un BPF multi-entity (fino a 5 tabelle), non due BPF separati né un workflow.