2 Simbologia, Regole Fondamentali ed Operatori di Confronto

2.1 Start Event e Timer Start Event
START EVENT
Rappresenta il punto univoco da cui ha inizio ogni singolo processo. Ciò significa che può esserne presente solamente uno in ogni singolo processo in quanto il flusso inizia da un solo punto.
Nota bene: deve essere sempre seguito da una task di controllo in quanto essa rappresenta la task in cui inserire le condizioni che, se verificate, faranno scatenare il processo.
Timer Start Event
Una tipologia particolare di timer è lo “Timer Start Event” che viene applicata sullo Start Event per permettere di far partire un determinato processo in un intervallo di tempo prestabilito. Può essere selezionato durante la modalità di modifica del diagramma premendo inizialmente sullo Start Event, poi sulla chiave inglese che compare tra le varie opzioni selezionabili e successivamente selezionando l’opzione “Timer Start Event”.
Nota bene: questa tipologia di start event deve essere seguita da una task di azione in quanto si possono solamente eseguire delle azioni.
Le altre tipologie di Start Event selezionabili non sono al momento implementate.
NOTA BENE: Dalla versione 24.08 sono state completamente rimosse.

2.2 End Event
END EVENT
Rappresenta il punto finale di un processo. A differenza del Start Event, può essere utilizzato più di una volta in un singolo processo, in quanto il flusso potrebbe finire in più punti.

2.3 Intermediate / Boundary Event Timer
INTERMEDIATE/BOUNDARY EVENT TIMER
Rappresenta un elemento molto utilizzato per la gestione delle tempistiche di svolgimento di task e processi.
Può essere selezionato in rapidamente dal menù a sinistra sempre durante la modalità di modifica del diagramma.
Esistono due gruppi di timer che si differenziano a seconda delle azioni da svolgere e dalle task/elementi coinvolti:
1) Intermediate Event Timer
2) Boundary Event Timer
1) INTERMEDIATE EVENT TIMER
Il primo gruppo è composto da diversi tipi di “Intermediate Event”e vengono utilizzati tra due task/elementi. Possono essere selezionati durante la modalità di modifica del diagramma premendo inizialmente sulla task o elemento da cui poi si deve passare al timer, poi sull’icona raffigurante due cerchi chiamata “Intermediate/Boundary Event Timer”.
A questo punto si deve selezionare il timer appena citato, cliccare sulla chiave inglese e poi selezionare una delle opzioni disponibili.
Timer Intermediate Catch Event
E’ un tipologia di timer utilizzata per attende un determinato periodo di tempo prima di passare alla task/elemento successivo.
Le altre tipologie di Intermediate Event selezionabili non sono al momento implementate.
NOTA BENE: Dalla versione 24.08 sono state completamente eliminate.
In fase di configurazione, cliccando sul simbolo del Timer Intermediate Catch Event, si apre l’interfaccia dedicata dove poter inserire le tempistiche di attesa e la data sulla quale basarsi.
All'interno della prima picklist partendo da sinistra, è possibile indicare se attendere la tempistica indicata PRIMA o DOPO rispetto alla data di riferimento.
Invece nella picklist successiva, vengono resi disponibili tre valori:
- Adesso -> come data di riferimenti prenderà la data-ora (timestamp) del momento preciso in cui il processo si posiziona sul timer.
- Data -> permette di inserire una data-ora statici
- Altro -> permette di inserire valori dinamici, quindi pescati dai campi data dei moduli coinvolti all'interno del processo.
2) BOUNDARY EVENT TIMER
Il secondo gruppo è composto da diversi tipi di “Boundary Event” che vengono utilizzati sulle task di controllo e si attivano nel momento in cui si rimane fermi su una task per un determinato periodo di tempo.
Possono essere selezionati durante la modalità di modifica del diagramma premendo inizialmente sulla task o elemento da cui poi si deve passare al timer, poi sull’icona raffigurante due cerchi chiamata “Intermediate/Boundary Event”.
A questo punto si deve selezionare il timer appena citato e trascinarlo su uno dei bordi della task di controllo interessata.
                                           
  
(N.B: Se si clicca semplicemente sull’icona verrà creato un “Intermediate Event” collegato alla task da una freccia. Se si vorrà utilizzare quel timer come Boundary Event sarà sufficiente eliminare la freccia e posizionare il timer sulla task interessata).
Una volta fatto questo si deve selezionare il timer, premere sulla chiave inglese e successivamente selezionare una tra le opzioni disponibili.
Timer Boundary Event
Permette di procedere con l’esecuzione delle task/elementi collegate al timer in base a quanto tempo il processo rimane fermo sulla task di controllo su cui si trova il timer stesso.
L’intervallo di tempo viene prestabilito durante la configurazione del timer.
Possono essere utilizzati solamente sulle task di controllo.
Le altre tipologie di Boundary Event selezionabili non sono al momento implementate.
NOTA BENE: Dalla versione 24.08 sono state completamente rimosse.
In fase di configurazione, cliccando sul simbolo del Timer Boundary Event, si apre l’interfaccia dedicata dove poter inserire le tempistiche di attesa.
Dalla versione 25.02 è possibile specificare una data sulla quale basarsi per definire le tempistiche di attesa.
La configurazione di questa parte è la medesima del timer intermediate, per cui all'interno della prima picklist partendo da sinistra è possibile indicare se attendere la tempistica indicata PRIMA o DOPO rispetto alla data di riferimento.
Invece nella picklist successiva, vengono resi disponibili tre valori:
- Adesso -> come data di riferimenti prenderà la data-ora (timestamp) del momento preciso in cui il processo si posiziona sul timer.
- Data -> permette di inserire una data-ora statici
- Altro -> permette di inserire valori dinamici, quindi pescati dai campi data dei moduli coinvolti all'interno del processo.

2.4 Exclusive e Parallel Gateway
Exclusive Gateway
Permette di suddividere il flusso del processo in più rami differenti in base alle condizioni che si verificano al suo interno.
Deve essere obbligatoriamente preceduto da una task di controllo nella quale si definiscono i gruppi di condizioni ai quali andranno associati dei rami del processo tramite il Gateway.
NOTA BENE: con questa tipologia di Gateway, il processo intraprenderà sempre e solamente un solo ramo tra quelli configurati (ovvero quello associato al primo gruppo di condizione che si verifica tra quelli esistenti nella task di controllo)
Per essere utilizzato, durante la modalità di modifica del diagramma si deve premere sulla task di controllo e poi successivamente selezionare il simbolo del rombo chiamato “Gateway”.
E’ riportato qui di seguito un esempio di Exclusive Gatewy applicato.
Come tutte le altre simbologie può essere selezionata anche dal menù rapido presente a destra.
Parallel Gateway
Svolge la stessa funzione dell’ Exclusive Gateway con l’unica differenza che i rami vengono eseguiti tutti quanti in parallelo. 
Alla fine dei rami deve essere presente un’ Exclusive Gateway che funga da Gateway di chiusura del parallelo. Prima del Gateway di chiusura devono essere configurate tante task di controllo quanti sono i rami coinvolti.
Questa tipolgia di struttura permette di poter scegliere se proseguire con il flusso al completamento di alcuni rami specifici del Gateway oppure attendere il completamento di tutti i rami esistenti.
Nota bene:
-non possono essere utilizzati dei Parallel Gateway all’interno di altri Parallel Gateway
-più Parallel Gateway non posso avere un Exclusive Gateway di chisura condiviso.
Per essere utilizzato, durante la modalità di modifica del diagramma si deve premere sulla task e poi successivamente selezionare il simbolo del rombo chiamato “Gateway”.
E' riportato qui di seguito un esempio di Parallel Gateway applicato.
Le tipologie di Gateway riportate di seguito non sono al momento implementate.
NOTA BENE: Dalla versione 24.08 sono state completamente rimosse.

2.5 Conditional Task e Action Task
CONDITIONAL TASK
Rappresenta l’elemento utilizzato per lo svolgimento di azioni di creazione e controllo all’interno del flusso di un processo.
ACTION TASK
Per definire la tipologia di task, Vtenext mette a disposizione dei simboli utilizzabili per indicare l’azione svolta da ogni singola task.
Questi simboli possono essere selezionati durante la modalità di modifica del diagramma premendo sulla task e poi successivamente sulla chiave inglese che compare tra le varie opzioni selezionabili.
        
E’ importante precisare che questi simboli non vanno a condizionare il comportamento delle singole task, in quanto il loro scopo è semplicemente quello di mostrare un riferimento visivo iniziale che possa facilitare l’interpretazione delle singole task. Quindi sarà a discrezione dell’utente selezionare il simbolo più opportuno all’azione svolta da ogni determinata task.
Una volta selezionato, ogni simbolo verrà posizionato in alto a sinistra della task e sarà visibile durante la configurazione del processo.
Qui di seguito un esempio per ogni tipologia selezionabile:
Script Task
E’ consigliabile utilizzarla per indicare la creazione e l’aggiornamento di task.
Send Task
E’ consigliabile utilizzarla per indicare l’invio di mail e notifiche.
Receive Task
Non è presente un utilizzo particolare consigliato.
User Task
E’ consigliabile utilizzarla per indicare un’attività in carico all’utente.
Manual Task
E’ consigliabile utilizzarla per indicare un’attività in carico all’utente (process helper).
Business Rule Task
Non è presente un utilizzo particolare consigliato.
Service Task
E’ consigliabile utilizzarla per indicare il richiamo di Webservice esterni o SDK.
Gli unici due simboli che permettono invece di svolgere una determinata azione e che quindi condizionano il comportamento di una determinata task sono il “Call Activity” e il “Sub Process”.
Call Activity
Questo simbolo permette di svolgere un azione al momento non implementata.
NOTA BENE: Dalla versione 24.08 è stato completamente rimosso
Sub Process (collapsed)
Questo simbolo permette di richiamare e utilizzare un sotto processo.

2.6 CONNETTORI (connecting object)
CONNETTORI (CONNECTING OBJECT)
Se in un processo gli elementi di flusso (eventi, attività o diramazioni) sono “ciò che avviene effettivamente”, essi devono essere logicamente collegati tra loro. A ciò servono i connettori.
I connettori devono sempre avere la direzione del flusso.

2.7 Regole fondamentali
1 - Alla creazione del processo, il sistema inserisce in automatico uno Start Event (per approfondimenti vedere capitolo 2.1), ovvero l'elemento che rappresenta il punto univoco da cui ha inizio ogni singolo processo.
Può esserne presente solamente uno in ogni singolo processo, in quanto, il flusso inizia da un unico punto. (Figura 1 e 2)
Figura 1
Figura 2
2 - Allo Start Event (per approfondimenti vedere capitolo 2.1) può essere collegata solamente una Conditional Task, ovvero una task di controllo nella quale poter definire le condizioni scatenanti del processo. (Figura 3 e 4)
Figura 3
Figura 4
La stessa logica vale per il Timer Start Event, con l'unica differenza che può essere collegata solamente una task di qualsiasi tipo tranne che Conditional Task. (Figura 5 e 6)
Figura 5
Figura 6
3 - Prima di un Exclusive Gateway ci deve sempre essere una Conditional Task che permette di definire dei gruppi di condizioni sulla base dei quali il processo si suddividerà in più rami. (Figura 7 e 8)
Figura 7
Figura 8

2.8 Operatori di Confronto: Descrizione e Utilizzo nelle Conditional Task
Il sistema mette a disposizione diversi operatori di confronto da poter utilizzare all'interno delle Conditional Task, ovvero le tipologie di task che permettono di eseguire dei controlli sui campi dei moduli/form dinamiche coinvolte all'interno del processo.
ATTENZIONE! -> il sistema è "Case Sensitive", quindi gli stessi valori con maiuscole o minuscole differenti vengono trattati come se fossero diversi.
Esempio: "VTENEXT" e "vtenext" vengono visti dal sistema come valori diversi.
- "uguale" -> permette di verificare se il contenuto di un campo è uguale ad un valore statico specificato all'interno della condizione. (Figura 1)
Figura 1
NOTA BENE: il sistema non permette di confrontare più valori contemporaneamente sulla stessa riga, quindi in caso fosse necessario eseguire un controllo multiplo si dovranno creare delle condizioni separate (Figura 2 e 3)
Figura 2
Figura 3
- "diverso" ->permette di verificare se il contenuto di un campo NON è uguale ad un valore statico specificato all'interno della condizione. (Figura 4)
Figura 4
- "contiene" -> permette di verificare se all'interno di un campo è presente il valore statico specificato all'interno della condizione, a prescindere dalla posizione in cui si trovi. (Figura 5)
Prendendo come riferimento l'esempio riportato in Figura 5, nel caso in cui avessimo un'azienda chiamata "demo_vtenext", la condizione sarà verificata, in quanto, questa tringa contiene "vte".
Figura 5
Al contrario dell'operatore "uguale", il sistema permette di confrontare più valori contemporaneamente sulla stessa riga (Figura 6)
Figura 6
- "non contiene" -> permette di verificare se all'interno di un campo NON è presente il valore statico specificato all'interno della condizione, a prescindere dalla posizione in cui si trovi. (Figura 7)
Figura 7
Come per l'operatore "contiene", è possibile confrontare più valori contemporaneamente sulla stessa riga (che andranno inseriti separati con una virgola).
- "inizia per" -> permette di verificare se il contenuto di un campo inizia con il valore statico specificato all'interno della condizione. (Figura 8)
Figura 8
NOTA BENE: il sistema non permette di confrontare più valori contemporaneamente sulla stessa riga, quindi in caso fosse necessario eseguire un controllo multiplo si dovranno creare delle condizioni separate (prendere come riferimento Figura 2 e 3)
- "finisce con" ->permette di verificare se il contenuto di un campo finisce con il valore statico specificato all'interno della condizione. (Figura 9)
Figura 9
NOTA BENE: il sistema non permette di confrontare più valori contemporaneamente sulla stessa riga, quindi in caso fosse necessario eseguire un controllo multiplo si dovranno creare delle condizioni separate (prendere come riferimento Figura 2 e 3)
- "è cambiato in" -> permette di verificare se il contenuto del campo ha subito precisamente un cambiamento nel valore specificato all'interno della condizione (Figura 10)
Figura 10
Per tutte quelle tipologie di campi che potrebbero avere un valore non definito (testo, numero, data, relazionato a, ecc.), combinando l'operatore "è cambiato in" con l'operatore "diverso", è possibile configurare una condizione che permetta di captare la modifica del contenuto di un campo in un valore consistente di cui non si è a conoscenza. (Figura 11)
Figura 11
L'esempio mostrato in Figura 11 si traduce nella seguente frase: "Data di chiusura attesa è cambiato in un valore che non so definire ma, allo stesso tempo, quel valore è diverso da vuoto, quindi sarà per forza un valore consistente".
- "è cambiato da" -> permette di verificare se il contenuto del campo ha subito un cambiamento da un valore ad un altro, entrambi specificati all'interno della condizione (Figura 12)
Nel primo slot andrà specificato il valore che il campo aveva prima della modifica, mentre nel secondo slot andrà specificato il nuovo valore che è stato inserito.
Figura 12
- "maggiore di" -> permette di verificare se il contenuto di un campo numero/valuta presente è maggiore di un valore statico inserito specificato all'interno della condizione. (Figura 13)
Figura 13
- "maggiore o uguale" -> permette di verificare se il contenuto di un campo numero/valuta presente è maggiore o uguale ad un valore statico inserito specificato all'interno della condizione. (Figura 14)
Figura 14
- "minore di" -> permette di verificare se il contenuto di un campo numero/valuta presente è minore di un valore statico inserito specificato all'interno della condizione. (Figura 15)
Figura 15
- "minore o uguale" -> permette di verificare se il contenuto di un campo numero/valuta presente è minore o uguale ad un valore statico inserito specificato all'interno della condizione. (Figura 16)
Figura 16

2.9 Operatori di Confronto: Regole di Utilizzo nelle Task di Condizione Iniziale
Alcuni operatori di confronto vanno utilizzati con attenzione all'interno delle Task di "Condizione Iniziale", ossia quelle Conditional Task direttamente associate allo Start Event dentro alle quali vengono definite le condizioni che permettono al processo di scatenarsi o meno. (Figura 1 e 2).
Figura 1
Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore)
Nello specifico, nel caso in cui venga coinvolta nella condizione la fase di "modifica" (quindi selezionando una tra le seguenti voci: "alla modifica" ,"alla creazione e modifica", "ogni volta che la condizione risulti vera"), gli operatori di confronto "uguale", "diverso", "contiene", "non contiene", "inizia per", "finisce con", "maggiore di", "maggiore o uguale", "minore di", "minore o uguale" non posso essere utilizzati singolarmente, in quanto, si rischia di creare dei loop, ossia la partenza indesiderata ed incontrollata di più istanze dello stesso processo.
Questo perché, gli operatori di confronto appena citati guardano semplicemente se la condizione è verificata o meno, senza tenere in considerazione in quale salvataggio specifico quella condizione si è verificata la prima volta.
Per comprenderne al meglio il funzionamento, in Figura 3 viene riportato un esempio di Task di Condizione Iniziale NON configurata correttamente.
Figura 3 (cliccare sull'immagine per una risoluzione grafica maggiore)
La condizione "Tipo" = "Potenziale" verifica semplicemente se quel campo possiede quel specifico valore.
Impostando quindi singolarmente questa condizione e coinvolgendo la modifica (in questo caso selezionando la voce "alla creazione e modifica"), il processo non si scatenerà solamente nel salvataggio in cui verrà impostato il "Tipo" in "Potenziale" ma anche nei salvataggio successivi, fintanto che il campo "Tipo" manterrà quel specifico valore.
Proprio per ovviare a questa problematica, il sistema mette a disposizione gli operatori di confronto "è cambiato in" ed "è cambiato da" che consentono di far partire il processo solamente nel salvataggio in cui si è verificato il settaggio di quel specifico valore.
Quindi, configurando il processo come mostrato in Figura 4, il processo si scatenerà solamente nel salvataggio in cui verrà impostato il valore in "Potenziale".
Figura 4 (cliccare sull'immagine per una risoluzione grafica maggiore)

2.10 Configurazione Sezione "Quando eseguire il controllo" nella Task di Condizione Iniziale
All'interno delle delle Task di "Condizione Iniziale", ossia quelle Conditional Task direttamente associate allo Start Event dentro alle quali vengono definite le condizioni che permettono al processo di scatenarsi o meno, la sezione "Quando eseguire il controllo" viene presentata con i seguenti valori:
- "alla creazione" -> il processo si scatenerà solamente dopo la creazione di un record (istanza di un modulo)
- "alla creazione e modifica" -> il processo si scatenerà dopo la creazione o modifica di un record (istanza di un modulo), quindi di fatto in tutte le situazioni attualmente gestite nei processi.
NOTA BENE: l'eliminazione di un record è un situazione non gestita nei processi
- "alla modifica" -> il processo si scatenerà solamente dopo la modifica di un record (istanza di un modulo)
- "ogni volta che la condizione risulti vera" -> il processo si scatenerà al verificarsi delle condizioni (sempre dopo il salvataggio) inserite nella sezione "Condizioni".
Anche per gli altri valori è possibile inserire delle condizioni nella sezione "Condizioni", quindi questa voce risulta essere a tutti gli effetti analoga alla voce "alla creazione e modifica", questo perché viene coinvolta sia la creazione che la modifica.
- "solo che la prima volta che si scatena il processo" -> il processo si scatenerà sono la prima volta che si verificherà la condizione inserita nella sezione "Condizioni".
Successivamente, il processo non potrà mai più scatenarsi su quel specifico record (istanza di un modulo), anche se le condizioni configurate al suo interno si saranno verificate.
- "al lancio del sottoprocesso" -> viene utilizzata esclusivamente per la configurazione dei sotto-processi e permette di far scatenare il sotto-processo nel momento in cui viene eseguita la task di richiamo configurata nel processo padre.
- "in relazione con" -> permette di far scatenare il processo nel momento in cui viene instaurata una relazione tra due record (istanza di un modulo) di due moduli aventi una relazione N - N
Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore)

2.11 Configurazione Sezione "Quando eseguire il controllo" nelle Conditional Task
All'interno delle delle Conditional Task classiche, ossia quelle Task utilizzate per eseguire dei controlli all'interno del processo, la sezione "Quando eseguire il controllo" viene presentata con i seguenti valori:
- "alla modifica" -> il processo attenderà una modifica del record (istanza di un modulo) coinvolto prima di verificare le condizioni configurate all'interno della Conditional Task, anche se dovessero essere già verificate.
- "ogni volta che la condizione risulti vera" -> il processo verificherà nell'immediato le condizioni configurate all'interno della Conditional Task, proseguendo quindi con il flusso nel caso in cui dovessero essere già verificate.
Per comprenderne meglio il funzionamento, in Figura 1 viene mostrato un processo che, alla creazione di un'opportunità, esegue un controllo sullo Stadio di Vendita e si suddivide in due rami differenti. (Figura 1)
Figura 1
Nel caso in cui la Conditional Task "Controllo Stadio di Vendita" fosse stata impostata "alla modifica", anche se l'opportunità in creazione avrà lo "Stadio di Vendita" = "Aperta" o "Da Analizzare", il processo non considererà verificate le condizioni.
Questo perché verrà atteso un salvataggio successivo alla creazione dell'opportunità prima di verificare le condizioni configurate al suo interno. (Figura 2)
Figura 2
Invece nel caso in cui la Conditional Task "Controllo Stadio di Vendita" fosse stata impostata "ogni volta che la condizione risulti vera", se l'opportunità in creazione avrà lo "Stadio di Vendita" = "Aperta" o "Da Analizzare", il sistema eseguirà una verifica nell'immediato proseguendo quindi nel primo o secondo ramo nel caso in cui ci fossero delle condizioni verificate. (Figura 3)
Figura 3

2.12 Gestione Permessi di Visibilità nei Processi
Come per qualsiasi altro modulo standard/custom, per configurare la visibilità del modulo Processi si deve accedere alla sezione dedicata "Accesso condiviso" presente su Impostazioni -> Permessi Utente -> Accesso Condiviso. (Figura 1)
Figura 1
"Privato" -> solamente i seguenti utenti potranno visualizzare il processo:
-l'utente che ha fatto scatenare il processo, ovvero l'utente che ha eseguito la modifica sul record del modulo associato al processo verificando le condizione iniziali definite.
Anche se, in una fase specifica del flusso, il processo verrà assegnato ad un utente differente, l'utente che ha fatto scatenare il processo sarà comunque in grado di vedere dall'inizio alla fine il processo con il rispettivo grafico.
ESEMPIO:
Considerando il processo mostrato in Figura 2 avente nell'EndEvent un Process Helper con assegnatario corrispondente all'utente "UtenteY" (Figura 3), nel caso in cui il processo venga scatenato da "UtenteX", quest'ultimo potrà sempre e comunque vedere il processo anche se nell'EndEvent verrà assegnato a "UtenteY".
Figura 2
Figura 3
-tutti gli utenti con permessi di amministratore, ovvero aventi il flag "Amministratore" spuntato nelle preferenze della propria utenza
-l'utente assegnatario del Process Helper (e quindi del processo) in quel specifico momento
-l'utente che ha eseguito un'attività che ha permesso al processo di proseguire con il proprio flusso, come ad esempio la modifica di un campo sul modulo per il quale il processo era in attesa (tramite una Task)
ESEMPIO:
Considerando il processo mostrato in Figura 4, nel caso in cui il processo venga scatenato da "UtenteX" e si fermi sulla Task "Attesa modifica azienda", se la modifica sull'azienda verrà eseguita sempre da "UtenteX" e quindi "UtenteY" non avrà alcuna interazione con il processo, di fatto "UtenteY" non potrà mai vedere il processo.
Se invece la modifica sull'azienda verrà eseguita da "UtenteY", da quel momento in poi potrà iniziare a vedere il processo.
Figura 4
"Pubblico: Sola Lettura" -> tutti gli utenti presenti nel sistema potranno visualizzare i processi attivi o terminati.
ATTENZIONE! -> tale permesso si riferisce al modulo Processi e non alle Form Dinamiche dei Process Helper, quindi quest'ultime continueranno a fare riferimento al campo Assegnato a del Process helper e quindi a essere compilabili solamente dagli utenti o gruppi definiti al suo interno.
"Pubblico: Lettura, Creazione/ Modifica" -> tutti gli utenti presenti nel sistema potranno visualizzare, creare o modificare i processi attivi o terminati.
ATTENZIONE! -> tale permesso si riferisce al modulo Processi e non alle Form Dinamiche dei Process Helper, quindi quest'ultime continueranno a fare riferimento al campo Assegnato a del Process helper e quindi a essere compilabili solamente dagli utenti o gruppi definiti al suo interno.
"Pubblico: Lettura, Creazione/ Modifica, Cancellazione" -> tutti gli utenti presenti nel sistema potranno visualizzare, creare o modificare ed infine eliminare i processi attivi o terminati.
ATTENZIONE! -> tale permesso si riferisce al modulo Processi e non alle Form Dinamiche dei Process Helper, quindi quest'ultime continueranno a fare riferimento al campo Assegnato a del Process helper e quindi a essere compilabili solamente dagli utenti o gruppi definiti al suo interno.

2.13 Process Manager: Gestione Versioning
All'interno di ogni singolo processo configurato nel sistema, in alto a sinistra è presente un pulsante denominato "Salva versione". (Figura 1)
Figura 1
Esso permette forzare il salvataggio di una nuova versione del processo garantendo la sua storicizzazione all'interno di in una tabella dedicata del DB.
Quindi, in parole più semplici, simula il funzionamento del pulsante "Esportazione VTE BPMN processo" permettendo di salvare una copia della configurazione attuale del processo su una tabella differente da quella principale legata alla sezione Process manager.
Inoltre, viene anche aggiornato il valore del campo "Versione" relativo. (Figura 2)
Figura 2
Questo tipo di operazione risulta essere fondamentale per garantire la possibilità di ripristinare una versione precedente del processo in caso di errori di configurazione o altri tipi di situazioni.
ATTENZIONE!: la cancellazione di un processo tramite il pulsante X dalla sezione Process manager provoca l'eliminazione definitiva del processo da tutte le tabelle relative del DB, compresa la tabella sopra citata.
Di conseguenza, è bene procedere con molta cautela nell'utilizzo di tale funzione, in quanto, una volta eseguita la cancellazione non ci sarà modo di ripristinare il processo e tutte le istanze pendenti associate ai record coinvolti.
Nel caso in cui si voglia salvare una nuova versione di un processo avente delle istanze pendenti (quindi nel nostro caso alcuni lead aventi il processo Ri-Assegnazione Lead attivo), il sistema presenterà il popup mostrato in Figura 3
Figura 3
Inoltre, per completezza verranno anche indicate anche tutte le modifiche pendenti su Campi condizionali e Layout Editor dei moduli presenti nel sistema (anche di moduli non coinvolti nel processo, questo perché il sistema esegue un controllo generale).
Cliccando sul pulsante CONGELA, il sistema salverà in automatico la versione di tutte le modifiche pendenti indicate in precedente e NON aggiornerà la versione delle istanze del processo pendenti sui record individuati (mantenendo nel nostro caso la versione 1.0).
Tale funzionalità è utile nel momento in cui si voglia applicare la nuova versione del processo solamente alle istanze del processo che partiranno in futuro, o meglio dal momento dell'aggiornamento della versione in poi.
Cliccando sul pulsante USA RECENTE, il sistema aggiornerà la versione delle istanze del processo pendenti sui record individuati (impostando nel nostro caso la versione 1.1).