L'instradamento basato su soglie consente di memorizzare le regole di approvazione in tabelle per importo, dipartimento o regione, evitando di dover modificare il codice a ogni cambiamento di policy.
Le regole di approvazione hard-coded sembrano funzionare all'inizio. Uno sviluppatore aggiunge qualche condizione, il workflow gira e il team va avanti.
Il problema emerge quando cambia il business. Il reparto finance aumenta un limite di spesa, una regione adotta una policy diversa o un dipartimento richiede un approvatore aggiuntivo per certe richieste. Quello che sembrava un piccolo aggiornamento si trasforma in modificare la logica dell'app, testarla e aspettare un rilascio.
Quel ritardo è costoso. Un aggiornamento di policy che dovrebbe richiedere minuti può richiedere giorni se dipende da lavoro tecnico. In quel lasso di tempo, i dipendenti seguono le vecchie regole, le approvazioni si bloccano e i manager iniziano a gestire eccezioni via email o chat.
Le eccezioni nascoste peggiorano le cose. Col tempo, i team aggiungono regole una tantum come "se l'importo supera 5.000 e il dipartimento è Sales, invia al Direttore A" o "se la richiesta proviene dall'Europa, salta questo passaggio." Quando quelle regole vivono in profondità nel workflow, solo poche persone le vedono.
Allora domande semplici diventano difficili da rispondere:
Quando nessuno vede l'insieme completo delle regole, gli errori seguono. Qualcuno pensa di rispettare la policy, ma l'app sta ancora usando una regola vecchia. Un nuovo manager riceve richieste che non dovrebbe vedere, mentre il vero approvatore resta fuori dal processo.
Per questo l'instradamento basato su soglie funziona meglio quando le policy di approvazione cambiano spesso. Invece di trattare le regole come parti fisse dell'app, le memorizzi come dati di business che si possono revisionare e aggiornare.
Immagina una semplice policy per le spese. Le richieste sotto 1.000 vanno a un team lead, quelle da 1.000 a 10.000 a un responsabile di dipartimento e tutto ciò che è sopra va a finance. Se questi limiti cambiano il mese prossimo, il business non dovrebbe avere bisogno di uno sviluppatore solo per mantenere le approvazioni in movimento.
Hard-codare trasforma aggiornamenti ordinari di policy in progetti software. Questo è il vero costo.
L'instradamento basato su soglie significa che il percorso di approvazione cambia in base a valori che definisci in anticipo. Una soglia è semplicemente un confine, come un importo oltre $1.000, una richiesta dal dipartimento Finance o un acquisto effettuato in Europa.
Invece di scrivere quelle regole direttamente nell'app, le memorizzi in tabelle. Il workflow legge la tabella, trova la regola corrispondente e invia la richiesta alla persona giusta.
Una configurazione di base potrebbe essere così:
Il processo rimane lo stesso, ma i valori che lo controllano possono cambiare.
Questa è l'idea chiave. La logica è la parte che dice: "controlla le regole e scegli la prima corrispondenza." I dati di policy sono l'elenco delle regole: intervalli di importo, dipartimenti, regioni, approvatori e priorità.
Quando logica e policy sono mescolate, anche una piccola modifica può richiedere uno sviluppatore per editare il workflow. Quando sono separate, il workflow resta stabile e cambiano solo le righe di regola.
Per esempio, se le vendite in APAC ora richiedono l'approvazione del direttore sopra $3.000 invece di $5.000, aggiorni una voce nella tabella. Non ricostruisci l'intero processo di approvazione.
Questo è più semplice da gestire perché le policy cambiano più spesso della struttura dei processi. I team si riorganizzano, i budget si spostano e le regioni ottengono nuovi responsabili. Una tabella gestisce tutto questo meglio delle condizioni hard-coded.
In una piattaforma no-code come AppMaster, questo in genere significa creare una tabella di regole e lasciare che il processo la controlli a runtime. Il modello è facile da capire per i non tecnici perché corrisponde a come le policy sono scritte nella realtà: se questa condizione corrisponde, invia qui.
Una buona tabella di regole dovrebbe rispondere a una domanda semplice: quando una richiesta corrisponde a queste condizioni, chi deve approvarla?
Se l'instradamento dipende da valori nascosti nel codice, ogni aggiornamento di policy diventa una ricostruzione. Una tabella mantiene quei cambi visibili e più facili da gestire.
Una tabella pratica di solito inizia con i campi che descrivono la richiesta:
Importo e valuta sono importanti perché lo stesso numero può significare cose diverse in budget o Paesi differenti. Una richiesta per 5.000 USD può seguire un percorso, mentre 5.000 EUR o 500.000 JPY potrebbero richiederne un altro.
Dipartimento e regione riflettono come le aziende funzionano davvero. Finance, HR e Operations spesso hanno percorsi di approvazione diversi anche per la stessa spesa. La regione conta quando esistono regole locali o manager diversi.
Il tipo di richiesta è un filtro utile. Viaggi, acquisti di software, pagamenti a fornitori e approvazioni sconto possono richiedere revisori diversi. Senza quel campo, richieste non correlate possono finire sulla stessa regola.
Per l'approvatore, memorizza un ruolo invece del nome di una persona. Usa valori come Department Manager, Regional Director o Finance Controller. Quando qualcuno cambia incarico, aggiorni l'assegnazione del ruolo una sola volta invece di modificare ogni regola.
Aiuta anche aggiungere start e end dates. Questo copre policy che iniziano in un giorno preciso, regole temporanee durante la chiusura di bilancio o cambi pianificati per il trimestre successivo. Mantieni lo storico senza lasciare regole scadute attive.
Vale la pena aggiungere un campo priority. Una regola per "EU + Finance + over 10,000" dovrebbe solitamente prevalere su una regola più ampia come "all departments + over 10,000." Una priorità chiara mantiene l'instradamento prevedibile.
Mantieni la struttura semplice: una riga deve corrispondere a una regola di approvazione.
Se le spese di marketing sopra $2.000 in Europa richiedono un manager regionale, quello dovrebbe essere in un singolo record. Quando ogni riga ha un significato chiaro, la configurazione è più semplice da aggiornare, testare e controllare.
La tabella principale dovrebbe concentrarsi su due cose: le condizioni che attivano una regola e l'esito che dice al workflow cosa fare dopo. Questo la rende leggibile sia per gli utenti di business sia per chi costruisce il processo.
Una tabella pulita spesso include questi campi:
Per le colonne di condizione, usa campi esatti invece di testo libero quando possibile. Un department ID è più sicuro che digitare "Finance" ogni volta. Lo stesso vale per codici regione, tipi di richiesta e centri di costo. Piccole tabelle di lookup per dipartimenti, regioni e ruoli di approvazione aiutano a evitare errori di battitura e rendono i filtri più semplici.
Per le colonne di esito, decidi cosa deve restituire il workflow. In alcuni team, la regola deve puntare a una persona specifica. In altri, deve instradare verso un ruolo come Regional Manager o Finance Director. Scegli un approccio e mantieni coerenza.
La priorità conta perché più regole possono corrispondere alla stessa richiesta. Non fare affidamento sull'ordine delle righe o sulla data di creazione. Aggiungi un campo numerico di priority e definisci come funziona, ad esempio 1 controllata per prima e 100 dopo.
Serve anche una regola di fallback. Questa è la rete di sicurezza per tutto ciò che non è coperto da una riga specifica. Una regola di default potrebbe inviare le richieste non corrispondenti a un operations manager o a una coda di revisione admin. Senza di essa, le richieste possono rimanere bloccate senza percorso.
Se costruisci questo in AppMaster, queste tabelle possono essere modificate visivamente, così i cambi di policy avvengono nei dati anziché in rami di workflow hard-coded.
Inizia dalla decisione, non dalla tabella. Scrivi le domande esatte a cui il tuo workflow deve rispondere. Un acquisto sopra $5.000 richiede un manager? Finance revisa tutto ciò che viene da Sales? Le richieste di una regione seguono un percorso diverso?
Quando queste scelte sono chiare, l'instradamento basato su soglie diventa più semplice perché stai memorizzando la policy invece di indovinare la logica in seguito.
Una configurazione semplice segue di solito cinque passi.
Prima, crea una approval rules table con i campi che influenzano l'instradamento. Colonne comuni includono amount_min, amount_max, department, region, approver_role, priority e active_status.
Secondo, decidi quali campi possono restare vuoti. Un department o region vuoto può significare "questa regola si applica a tutti" quando non esiste una corrispondenza più specifica.
Terzo, aggiungi le regole dalla più specifica alla più generale. Una regola per "Sales + Europe + over $10,000" dovrebbe essere controllata prima di una regola ampia come "any department + any region + over $10,000."
Quarto, testa con esempi reali prima del lancio. Usa casi limite come esattamente $5,000, dati di dipartimento mancanti o una regione senza regole personalizzate.
Quinto, limita chi può modificare la tabella. I cambi di policy devono essere facili, ma non aperti a tutti.
Ecco un esempio semplice. Una richiesta da $12,000 di HR in Nord America può prima corrispondere a una regola "HR over $10,000," che la invia al direttore HR. Se non esiste una regola specifica per HR, il sistema può tornare a una regola più ampia come "any department over $10,000," che la manda a finance.
L'ordine importa più di quanto molti team pensino. Se regole ampie stanno sopra regole specifiche, la persona sbagliata riceve la richiesta e la fiducia nel sistema cala.
Prima del go-live, assegna un owner per le modifiche alle regole, conserva un breve documento di policy e testa nuovamente dopo ogni aggiornamento. Piccoli cambi di instradamento possono avere grandi effetti.
Immagina un'azienda che usa un unico modulo di richiesta di acquisto per tutti i team. Ogni richiesta include importo, dipartimento e regione. Il sistema confronta quei valori con una rules table e sceglie l'approvatore giusto.
Supponiamo che l'azienda abbia due dipartimenti, Marketing e IT. Entrambi possono inviare una richiesta per $4,000, ma il percorso di approvazione non deve essere lo stesso.
| Department | Region | Amount range | Approver |
|---|---|---|---|
| Marketing | US | $0 to $5,000 | Marketing Manager |
| Marketing | US | $5,001+ | Finance Director |
| IT | US | $0 to $3,000 | IT Manager |
| IT | US | $3,001+ | CTO |
| Marketing | EU | $0 to $5,000 | Regional Marketing Lead |
Ora confronta due richieste con lo stesso importo. Una richiesta Marketing per $4,000 negli US va al Marketing Manager. Una richiesta IT per $4,000 negli US salta l'IT Manager e va al CTO, perché IT ha una soglia più bassa.
La regione può cambiare l'esito. Una richiesta Marketing da $2,500 negli US va al Marketing Manager, ma la stessa richiesta in EU va al Regional Marketing Lead. Il modulo resta lo stesso. Cambia solo la regola che combacia.
Questo è il vero valore di una rules table. La policy vive nei dati, non nella logica del workflow.
Se l'azienda aggiorna la policy il mese prossimo, non serve ricostruire l'intero processo. Se IT decide che le richieste sopra $2,000 devono ora andare al CTO, modifichi una sola riga:
Tutto il resto continua a funzionare. Le nuove richieste seguono subito la nuova policy mentre la struttura dell'app rimane intatta.
La parte più difficile dell'instradamento basato su soglie non è quasi mai l'idea centrale. Sono i casi limite disordinati che compaiono dopo, quando la policy cambia e nessuno ricorda perché una richiesta è finita dalla persona sbagliata.
Un errore comune è avere regole sovrapposte senza una priorità chiara. Potresti avere una regola che manda tutte le richieste Marketing sopra $3,000 al responsabile del dipartimento e un'altra che manda qualsiasi richiesta sopra $5,000 a Finance. Una richiesta Marketing da $6,000 combacia con entrambe, quindi il sistema ha bisogno di un vincitore chiaro. Metti quella priorità nella rules table, non nella logica nascosta del workflow.
Un altro errore è hard-codare persone invece di ruoli o gruppi. I nomi cambiano. I team cambiano. Qualcuno va in ferie o si sposta. Se una regola dice "invia a Maria Lopez," la modificherai ogni volta che cambia l'organico. È più sicuro instradare verso un ruolo come Regional Finance Manager o Sales Director, poi mappare quel ruolo alla persona attuale.
Saltare una via di fallback causa fallimenti silenziosi. Prima o poi, una richiesta non corrisponderà a nessuna regola perché l'importo è insolito, il dipartimento è nuovo o un campo è vuoto. Quando succede, il workflow dovrebbe comunque fare qualcosa di sicuro, come inviare l'elemento a una coda default o al team admin.
Le eccezioni regionali sono un altro punto debole. Una policy valida in un Paese può non essere valida in un altro per limiti locali di spesa, regole fiscali o esigenze di reporting. Se testi solo una regione, puoi perdere casi dove EU, US o APAC dovrebbero seguire percorsi diversi.
Le regole basate sul tempo si dimenticano facilmente. Se crei una regola temporanea per fine trimestre, congelamento di budget o un progetto speciale, assicurati che abbia start e end dates. Le regole scadute devono smettere di applicarsi automaticamente. Altrimenti, vecchie eccezioni restano attive e mandano le richieste nella strada sbagliata.
Prima di attivare l'instradamento basato su soglie, rivedilo dal punto di vista di un utente reale. Ogni richiesta dovrebbe arrivare all'approvatore giusto senza che nessuno debba indovinare il motivo.
Mantieni la revisione finale semplice.
Verifica che ogni richiesta normale abbia una corrispondenza chiara. Se due regole possono applicarsi contemporaneamente, gli utenti avranno risultati incoerenti.
Assicurati che ci sia una via di fallback. Dipartimenti mancanti, regioni nuove o importi insoliti devono comunque andare da qualche parte in modo sicuro.
Conferma che gli aggiornamenti di policy possano avvenire senza uno sviluppatore. Se Finance o Operations devono cambiare limiti, date o approvatori, dovrebbero poter modificare i record in una tabella invece di richiedere una modifica al codice.
Testa le date, non solo i valori. La policy di ieri e quella del prossimo mese devono comportarsi come previsto quando le date di efficacia sono in gioco.
Scrivi la logica di instradamento su una pagina in linguaggio semplice. Se un manager non riesce a spiegarla chiaramente, probabilmente è troppo complessa.
Un test utile è creare cinque richieste di esempio che coprano casi normali, edge case e casi di policy scaduta. Se il team riesce a prevedere il risultato prima di eseguirle, la configurazione è probabilmente pronta. In caso contrario, semplifica.
Parti in piccolo. Scegli un flusso di approvazione che oggi causa i maggiori ritardi o confusione, come richieste d'acquisto sopra una certa soglia o note spese per dipartimento. Costruisci quello per primo, testalo con casi reali e poi aggiungi altri tipi di regole.
Questo approccio rende il modello di instradamento più affidabile. Le persone possono vedere come funzionano le regole, dove compaiono le eccezioni e cosa va cambiato prima che la configurazione cresca.
Il primo rollout dovrebbe rispondere a quattro domande di base:
Quest'ultimo punto è molto importante. Se nessuno è chiaramente responsabile degli aggiornamenti di policy, il workflow si discosterà gradualmente da come il business realmente opera. Assegna una persona o un piccolo team per revisionare i cambi, approvare le modifiche e tenere un breve registro delle ragioni.
Aiuta anche stabilire una cadenza di revisione. Se le policy cambiano spesso, revisiona le regole mensilmente. Se il processo è stabile, trimestralmente può bastare. Una breve revisione può intercettare soglie obsolete, dipartimenti mancanti o eccezioni regionali prima che causino ritardi.
Mantieni la revisione pratica. Fai domande semplici: le approvazioni stanno arrivando alle persone giuste, qualche team ha cambiato struttura, i limiti attuali corrispondono ancora alla policy finance e ci sono troppi override manuali?
Se vuoi costruirlo in modo visivo, AppMaster può essere una buona soluzione per creare la rules table, il processo di routing e le schermate admin dove il personale non tecnico aggiorna le policy. Essendo pensato per applicazioni no-code complete, funziona bene quando vuoi che i team di business gestiscano direttamente i cambi di approvazione invece di rimandare ogni modifica agli sviluppatori.
Una volta che un flusso funziona, riutilizza lo stesso schema nel processo successivo. Passi piccoli e chiari funzionano meglio di una ricostruzione completa.
What is threshold-based routing?Significa che l'app sceglie il percorso di approvazione leggendo le regole come dati anziché usare rami fissi nel workflow. Per esempio, importo, dipartimento o regione possono decidere chi approva una richiesta, e questi valori si possono cambiare in una tabella senza ricostruire l'intero processo.
Why are hard-coded approval rules a problem?Le regole codificate funzionano all'inizio, ma ogni modifica di policy diventa lavoro di sviluppo, test e rilascio. Una tabella di regole è più veloce perché il workflow rimane identico mentre cambiano i valori di policy.
What should I put in an approval rules table?Inizia con i campi che influenzano davvero l'instradamento: minimum amount, maximum amount, currency, department, region, request type, approver role, priority e active status. Se usi policy temporanee, aggiungi anche start e end dates.
Should I store approver names or approver roles?Meglio i ruoli. Se instradi verso un ruolo come Finance Director o Department Manager, i cambi di personale si gestiscono aggiornando la mappatura del ruolo una sola volta invece di modificare molte regole.
How do I handle overlapping approval rules?Usa un campo di priorità chiaro e definisci quale numero prevale. Il sistema dovrebbe controllare prima la regola più specifica: una regola ristretta come EU + Finance + over 10,000 deve battere una regola ampia come all departments + over 10,000.
What if no rule matches a request?Aggiungi una regola di fallback. Se una richiesta manca di dati o non corrisponde a nessuna riga specifica, deve comunque essere inviata a una coda sicura, al team admin o a un approvatore di default invece di rimanere bloccata.
Can non-technical teams update approval rules themselves?Sì, se il sistema è progettato così. In AppMaster puoi mantenere le regole in tabelle e permettere ai processi di business di leggerle a runtime, così il personale autorizzato può aggiornare le policy tramite schermate di amministrazione senza toccare il codice.
Why should I add start and end dates to rules?Le date di validità permettono di programmare cambi e ritirare automaticamente eccezioni temporanee. Sono utili per regole di fine trimestre, congelamenti di budget e cambi di policy che devono iniziare in una data futura senza impattare le richieste correnti.
How should I test threshold-based routing before launch?Testa casi reali prima del lancio, soprattutto gli edge case. Controlla valori esatti di soglia, campi vuoti, dipartimenti nuovi, eccezioni regionali e regole scadute, in modo che ogni richiesta abbia una sola rotta chiara.
What is the best way to start using this approach?Parti con un flusso di approvazione che oggi provoca più ritardi o confusione, come richieste di acquisto sopra una certa soglia o note spese per dipartimento. Mantieni la prima versione piccola, dimostra che le regole funzionano e poi applica lo stesso schema ad altri processi.
14 lug 2026
8 min
13 lug 20268 min
08 lug 20268 minSperimenta con AppMaster con un piano gratuito.
Quando sarai pronto potrai scegliere l'abbonamento appropriato.
