La risposta breve
Un processo di approvazione sull'entità Quote, attivato alla creazione o
all'aggiornamento e ristretto da un normale nodo filtro — che è dove risiede la
soglia. Un totale del preventivo con l'operatore More e un valore di
10000 è tutto ciò che significa "solo sopra 10K". Lo stesso meccanismo
funziona su una percentuale di sconto o su un campo di margine.
L'applicazione è recordLock, non una notifica. Indirizzi
l'approvazione a SalesUnitManager anziché a persone indicate per nome,
così sopravvive ai cambi di personale. E controlli expirationResult
prima di andare in produzione — può essere impostato su Approve, il che
significa che un'approvazione a cui nessuno risponde viene concessa automaticamente.
Il problema di business
I commerciali concedono sconti per chiudere. Il più delle volte è esattamente ciò che si vuole che facciano, e chiedere il permesso per ogni piccola concessione rallenterebbe l'intero team senza alcun beneficio.
Il problema è la coda della distribuzione. Ogni trimestre una manciata di preventivi riporta uno sconto o un totale che nessun responsabile avrebbe approvato, e vengono scoperti a posteriori — alla registrazione dell'ordine, alla fatturazione o quando qualcuno esegue un report sui margini. A quel punto il cliente ha già il numero per iscritto.
Ciò che l'azienda ha chiesto:
- i preventivi al di sopra di una soglia di valore non possono procedere finché qualcuno non li approva;
- tutto ciò che è al di sotto della soglia non viene toccato in alcun modo — nessun passaggio in più, nessuna notifica, niente;
- l'approvatore è chi gestisce in quel momento l'unità di vendita a cui appartiene il preventivo, senza dover mantenere un elenco;
- un audit trail che mostri chi ha approvato cosa e quando;
- e il record effettivamente trattenuto, non solo contrassegnato.
Perché l'approccio ovvio non funziona
Si provano quattro soluzioni prima di ricorrere a un vero processo di approvazione, e ciascuna fallisce nello stesso modo fondamentale: registra un'intenzione anziché impedire un'azione.
Un campo obbligatorio "approvato dal manager"
Autodichiarato e non applicato. La persona che vuole lo sconto è la stessa che spunta la
casella, e quando lo fa nel record non cambia nulla. Il risultato è un campo che vale
sempre true e non significa nulla.
Un'automazione che invia un'email al manager
È una notifica, non un blocco. Nel momento in cui parte l'email, il preventivo è già salvato, già stampabile e già inviabile. Le dice che cosa è successo; non impedisce che succeda.
Una fase della pipeline chiamata "Approval"
Una convenzione, non un controllo. Le fasi vengono spostate dagli utenti, e un utente che ha bisogno di far uscire un preventivo la scavalcherà. Inoltre travisa i dati in silenzio: la fase dice "approvato" perché qualcuno ha trascinato una scheda.
Indicare gli approvatori per nome
Questa soluzione funziona davvero — fino alla prima riorganizzazione. Gli approvatori indicati per nome smettono di funzionare quando qualcuno cambia team, va in ferie o lascia l'azienda, e la modalità di errore è una coda di approvazioni in attesa di una persona che non c'è più. Inoltre deve essere mantenuta per sempre da chiunque si ricordi che esiste.
Il vero requisito sono due cose insieme: un blocco sul record finché la decisione è in sospeso, e un instradamento dinamico che determina l'approvatore dalla struttura organizzativa nel momento in cui viene avviata l'approvazione. Il processo di approvazione di Coevera offre entrambe le cose; nient'altro nella piattaforma ne offre anche solo una.
Configurazione — tre chiamate, non una
Creare un processo di approvazione non lo configura, e configurarlo non lo attiva. Sono tre operazioni separate, e fermarsi dopo le prime due lascia un processo che sembra presente e non fa nulla.
| Passaggio | Contiene |
|---|---|
| 1 · Creazione | Solo name, description e ownerId. Nessun trigger, nessun filtro, nessun approvatore. |
| 2 · Configurazione | L'intero schema, come stringa JSON: trigger, filtro, impostazioni e nodi decisionali. |
| 3 · Attivazione | Una chiamata separata. Finché non viene eseguita, non scatta nulla. |
Lo schema, parte per parte
Il payload di configurazione ha quattro membri di primo livello.
trigger
Indica l'entità e l'evento e — cosa utile — chi può attivarlo. Oltre al tipo di entità e a un evento come la creazione o l'aggiornamento, il trigger contiene un'impostazione degli attori con elenchi di unità e di utenti. Lasciato su qualsiasi utente si applica a tutti; se ristretto, consente di sottoporre al blocco i preventivi di un team senza toccare quelli di un altro.
filter — dove risiede la soglia
È un normale nodo filtro, la stessa struttura usata in tutte le automazioni della
piattaforma. L'esempio acquisito ha un nome che descrive ciò che fa — sum over 10K
— e contiene un'unica regola: il campo del totale del preventivo, operatore
More, valore 10000.
Due conseguenze da mettere in evidenza. Al di sotto della soglia non viene creata alcuna approvazione — non è un'approvazione che approva automaticamente le trattative piccole, semplicemente non scatta. E poiché è un nodo filtro generico, la soglia può essere qualsiasi cosa su cui si possa filtrare: una percentuale di sconto, un campo di margine, una categoria di prodotto o più condizioni combinate.
Si noti che un valore di filtro numerico su un campo monetario viene memorizzato come una tupla che contiene l'importo insieme a un riferimento alla valuta — su un campo multivaluta un semplice numero non dice tutto.
settings — chi decide e che cosa viene bloccato
| Impostazione | Cosa fa |
|---|---|
approvers | Un elenco di voci, ciascuna delle quali è un utente indicato per nome oppure un tipo di ruolo come il manager dell'unità di vendita. |
allApprove | Se tutti gli approvatori devono essere d'accordo, oppure se ne basta uno qualsiasi. |
canDelegate | Se un approvatore può affidare la decisione a qualcun altro. |
recordLock | Il meccanismo di applicazione. Controlla chi può modificare il record mentre la decisione è in sospeso. |
expiration / expirationDays / expirationResult | Se un'approvazione in sospeso scade, dopo quanto tempo e quale verdetto assume alla scadenza. |
salesProcessDependency | Lega l'approvazione alla posizione del record nel processo di vendita. |
Per l'approvatore usi un tipo di ruolo, non un ID utente. Un approvatore di tipo manager dell'unità di vendita viene determinato a partire dall'unità di vendita a cui è assegnato il record quando viene avviata l'approvazione. Continua a funzionare attraverso riorganizzazioni, dimissioni e ferie, e non richiede manutenzione quando l'azienda cambia forma. Gli approvatori indicati per nome sono il motivo più comune per cui un processo di approvazione smette silenziosamente di funzionare un anno dopo essere stato creato.
approveNodes e rejectNodes
Due array di nodi di automazione, eseguiti in base alla rispettiva decisione. Sono gli stessi tipi di nodo usati nelle automazioni ordinarie, quindi tutto ciò che può fare un'automazione può farlo anche una decisione — l'esempio acquisito usa un nodo di aggiornamento del record per spostare la fase della pipeline del preventivo quando l'approvazione viene concessa.
Un dettaglio di forma che sorprende: su un nodo di aggiornamento del record il payload si
trova nell'input dell'entità come stringa JSON, mentre l'array
operations si limita a indicare quali campi al suo interno vengono scritti.
Fornire le operations con un input vuoto produce un errore generico e poco utile.
Cosa impostare concretamente
Per il requisito del §1, la struttura è la seguente:
| Impostazione | Valore | Perché |
|---|---|---|
| Entità / evento del trigger | Quote · creazione o aggiornamento | Intercetta sia un preventivo creato al di sopra della soglia sia uno modificato in seguito fino a raggiungerla. |
| Attore del trigger | Qualsiasi utente | Una governance che esenta alcune persone non è governance. |
| Filtro | Totale · More · soglia | Al di sotto, non scatta assolutamente nulla. |
| Approvatori | Manager dell'unità di vendita (tipo di ruolo) | Sopravvive ai cambi di personale e di organizzazione senza manutenzione. |
allApprove | false, per un unico approvatore | Ha senso solo con più di un approvatore; lo imposti deliberatamente se ne aggiunge un secondo. |
recordLock | Possono modificare gli Approval Process Managers | Blocca chi ha creato il preventivo, lascia un percorso di escalation. Si veda l'avvertenza nel §6. |
expirationResult | Reject, non approve | Si veda il §6 — l'alternativa concede in silenzio un'approvazione che nessuno ha dato. |
| Nodo di approvazione | Spostare la fase della pipeline | Rende visibile la decisione sul record, non solo nella cronologia delle approvazioni. |
| Nodo di rifiuto | Spostare la fase e notificare | Il percorso di rifiuto è quello che più spesso resta vuoto. Si veda il §6. |
Dare al filtro un nome che ne esprima il significato di business anziché il meccanismo ripaga in seguito — il nome è ciò che vede un amministratore quando cerca di capire perché un preventivo è bloccato.
Rendere visibile la decisione
La cronologia delle approvazioni registra chi ha deciso cosa e quando, e questo soddisfa l'audit. Non soddisfa però il team di vendita, che ha bisogno di vedere lo stato sul record stesso.
È a questo che servono i nodi decisionali. In caso di approvazione, sposti il preventivo in una fase che indichi l'approvazione; in caso di rifiuto, lo sposti in una fase che indichi il rifiuto e lo comunichi al proprietario. Se deve essere eseguita un'automazione a valle — pubblicare un valore, creare un'attività, riscrivere su un record padre — il nodo decisionale può attivare un ulteriore processo anziché cercare di fare tutto da sé.
Se il preventivo è un proxy che sostituisce qualcosa che non può ospitare un'approvazione, la riscrittura è l'intero scopo del progetto — quel pattern è il Blueprint 001.
Limiti e compromessi
L'impostazione che trasforma la governance in una messinscena
expirationResult può essere impostato su approvazione. Con la
scadenza attiva e quel verdetto, un'approvazione a cui nessuno risponde viene
concessa automaticamente allo scadere del periodo.
È peggio che non avere alcun processo di approvazione. Produce un audit trail che mostra un'approvazione che nessuna persona ha mai dato — e sarà scoperta da chi esegue l'audit, non da lei. Se la scadenza è attiva, il risultato deve essere il rifiuto, con l'escalation gestita dai nodi di rifiuto. Controlli esplicitamente questo valore su ogni processo di approvazione che eredita.
Il blocco non è un congelamento
Il blocco del record ha due modalità: il record resta modificabile dagli Approval Process Managers, oppure dagli Approval Process Managers e dagli approvatori. È in sola lettura per tutti gli altri, e in nessuna delle due modalità è congelato. È sensato — lascia un percorso di escalation quando qualcosa di urgente è bloccato — ma significa che il record non è immutabile mentre è in sospeso. Non lo descriva a un revisore come se lo fosse.
A cosa non può essere collegata un'approvazione
Le approvazioni possono avere come destinazione solo Account, Contact, Lead, Opportunity o Quote. Le entità personalizzate non sono supportate come destinazioni delle approvazioni, e il record di approvazione stesso non accetta campi personalizzati — quindi tutti i metadati di approvazione su cui deve fare report devono risiedere sul record di destinazione. Entrambi i vincoli, e il pattern proxy che li aggira, sono descritti nel Blueprint 001.
Fonte. Centro assistenza di Coevera, Working with Approval Processes: le approvazioni «possono essere applicate ad Accounts, Contacts, Leads, Opportunities e Quotes».
Il percorso di rifiuto di solito manca
In ogni implementazione che abbiamo esaminato, il ramo di approvazione era completo e quello di rifiuto era vuoto o parziale. Il fallimento è silenzioso: un record rifiutato resta semplicemente dov'era, senza alcun segnale per il suo proprietario, e appare identico a uno ancora in attesa. Costruisca i nodi di rifiuto insieme a quelli di approvazione, altrimenti non li costruirà affatto.
Altre cose da sapere
- Creato non significa attivo. Un processo può esistere, essere completamente configurato, risultare integro e non scattare mai.
- La configurazione è una stringa JSON all'interno della richiesta, il che significa che non viene convalidata rispetto allo schema come gli argomenti ordinari. I marcatori di tipo sono obbligatori alla radice e sui nodi annidati, e un payload che ne è privo viene rifiutato con un messaggio che non lo dice.
- I valori di filtro monetari contengono un riferimento alla valuta insieme all'importo. Una soglia su un campo multivaluta non è solo un numero.
- Qui è verificata una sola configurazione acquisita. Il comportamento con più approvatori — ordine, approvazione parziale, effetto di una delega sull'audit trail — va testato nel suo spazio prima di farvi affidamento.
Verifica
Un processo di approvazione è un controllo. Un controllo che si crede funzionante e non lo è rappresenta lo stato peggiore possibile, quindi il piano di test conta qui più che nella maggior parte delle implementazioni.
- Confermi che tutti e tre i passaggi siano stati eseguiti — creazione, configurazione e attivazione. Rilegga lo stato di attivazione anziché presumere che la chiamata sia riuscita.
- Testi al di sotto della soglia. Il comportamento corretto è che non succeda assolutamente nulla — nessun record di approvazione, nessuna notifica, nessun blocco. Un'approvazione che scatta e si approva automaticamente è un progetto diverso, e sbagliato.
- Testi al di sopra della soglia, e testi separatamente la modifica di un preventivo che supera la soglia. È l'evento di creazione o aggiornamento a intercettare il secondo caso, ed è quello che ci si dimentica di provare.
- Verifichi il blocco come chi ha creato il preventivo, non come amministratore. Acceda come utente commerciale e tenti la modifica. Spesso gli amministratori non riescono affatto a riprodurre il blocco, ed è per questo che viene approvato come funzionante quando non lo è.
- Metta alla prova deliberatamente il percorso di scadenza. Imposti una scadenza breve in uno spazio di test, la lasci trascorrere e confermi che il verdetto assunto sia quello previsto.
- Metta alla prova il rifiuto, non solo l'approvazione. Confermi che il record si sposti e che il proprietario ne venga a conoscenza.
- Confermi che la determinazione dell'approvatore segue l'unità di vendita del record. Assegni un preventivo di test a un'altra unità di vendita, avvii l'approvazione e verifichi che venga indirizzata al manager di quell'unità.
Cosa segnalerebbe una regressione: approvazioni che compaiono su preventivi al di sotto della soglia; un'approvazione in sospeso con l'elenco degli approvatori vuoto; record al di sopra della soglia che raggiungono uno stato chiuso senza alcuna approvazione nella loro cronologia; oppure una cronologia delle approvazioni che mostra decisioni con data e ora esattamente allo scadere dell'intervallo, il che significa che a decidere è il timeout anziché una persona.
Domande frequenti
Come si richiede un'approvazione per un preventivo al di sopra di un certo valore o sconto?
In Coevera CRM un processo di approvazione sull'entità Quote contiene un nodo filtro standard, quindi la soglia si esprime come una normale condizione su un campo — per esempio il totale del preventivo con l'operatore More e un valore di 10000. Al di sotto della soglia non succede nulla e non viene creata alcuna approvazione; al di sopra, l'approvazione viene avviata automaticamente alla creazione o all'aggiornamento del record. Poiché il filtro è un normale nodo filtro, lo stesso meccanismo funziona su un campo di percentuale di sconto, su un campo di margine o su una combinazione di condizioni.
Un'approvazione nel CRM impedisce davvero di modificare il record o si limita a notificare qualcuno?
Blocca il record. Le impostazioni dell'approvazione includono una modalità di blocco del record, ed è questo il meccanismo di applicazione, non una notifica. Le modalità sono due: il record resta modificabile dagli Approval Process Managers, oppure dagli Approval Process Managers e dagli approvatori, ed è in sola lettura per tutti gli altri. Nessuna delle due è un congelamento totale, quindi il blocco è un controllo sull'utente commerciale — meglio saperlo prima di descriverlo a un revisore come immutabile.
Le approvazioni possono essere indirizzate automaticamente a un manager invece di indicare singoli approvatori?
Sì. Una voce di approvatore può specificare un tipo di ruolo anziché un ID utente — per esempio il manager dell'unità di vendita, determinato a partire dall'unità di vendita a cui è assegnato il record nel momento in cui viene avviata l'approvazione. È di gran lunga preferibile all'indicazione di singole persone, perché continua a funzionare quando le persone cambiano team, vanno in ferie o lasciano l'azienda, e non richiede alcuna riconfigurazione quando l'organizzazione cambia.
Cosa succede se nessuno risponde a un'approvazione in sospeso?
Dipende dalle impostazioni di scadenza, e vale la pena controllare con attenzione questa impostazione: il risultato alla scadenza può essere impostato su approvazione, il che significa che un'approvazione su cui nessuno interviene viene concessa automaticamente allo scadere del periodo. Un controllo di governance che approva in silenzio allo scadere del tempo è peggio di nessun controllo, perché produce un audit trail che mostra un'approvazione che nessuna persona ha dato. Imposti deliberatamente il risultato alla scadenza.