Manuale dei processi 1 Introduzione BPMN 1.1 Perché automatizzare un processo aziendale? Vantaggi e Obiettivi QUALI SONO I VANTAGGI? Le motivazioni e vantaggi principali posso essere riassunte nei seguenti punti: Risparmiare tempo Delegando al sistema l’attuazione dei processi interni aziendali si fornisce alle persone la possibilità di potersi dedicare ad altre attività, talvolta liberandosi anche dai “mal di pancia” quotidiani. Minimizzare i costi e gli errori Errori umani, equivoci e dimenticanze si traducono sempre in costi aggiuntivi e cercare di minimizzarli è una sfida che ogni azienda si trova ad affrontare. Ottimizzare la comunicazione Flussi continui di email e telefonate tra un reparto e un altro non sono il modo migliore per organizzare e gestire il lavoro, soprattutto quando per portare a termine un determinato processo servono team diversi che intervengono in fasi diverse. In un processo automatizzato ogni persona è guidata da notifiche di sistema che indicano cosa deve fare e quando farlo. Inoltre, tutte le operazioni, le richieste e le modifiche sono registrate e rintracciabili, riducendo al minimo il rischio di perdere informazioni. Rafforzare la consapevolezza del proprio ruolo e delle proprie responsabilità Perché il flusso di lavoro sia gestito correttamente attraverso il software è necessario che ogni membro del team, in qualsiasi reparto, sappia perfettamente quali sono le sue mansioni e le sue responsabilità. Questo implica una chiara definizione delle gerarchie e dei rapporti tra persone e reparti e, in particolar modo, implica la precisa indicazione di chi deve assegnare i compiti, dare input, approvare o rifiutare gli output. Tenere tutto sotto controllo Gestire i flussi di lavoro in maniera automatizzata permette non solo di conoscere in ogni momento lo stato di ogni singola attività, ma anche di tenere sotto controllo il quadro generale della situazione. Automatizzare il monitoraggio significa convocare meno riunioni, ottenendo un notevole risparmio di tempo. QUALI SONO GLI OBIETTIVI DEL BPMN? Gli obiettivi principali posso essere riassunti nei seguenti punti:    Poter definire i così detti “colli di bottiglia” che molto spesso rappresentano un danno riducendo la produttività collettiva  Poter monitorare il flusso operativo delle procedure aziendali in modo da non rischiare di “inciampare” anche nelle casistiche            più complesse  Migliorare lo scambio di informazioni al fine di facilitare la gestione dei dati a livello strutturale  Avere un “disegno” univoco dei processi in modo che tutti i flussi aziendali possano essere correttamente eseguiti e gestiti                nello stesso modo   Integrare attori ed attività in maniera efficace potendo sfruttare degli strumenti alla portata di tutte le tipologie di figure                  aziendali, quindi non solo quelle di natura “tecnica”. 1.2 Sezione Process Manager: Descrizione Generale ed Elenco Funzionalità DESCRIZIONE GENERALE Rappresenta la sezione in cui poter modificare, creare, importare ed esportare i processi BPMN. E’ composto dalle seguenti colonne: -Nome → rappresenta il nome del processo -Descrizione → rappresenta la descrizione del processo -Sotto processi → indica l’elenco di eventuali sotto processi legati al processo in oggetto -Modulo del CRM → indica il nome del modulo “principale” del CRM coinvolto nel processo e sul quale si basano le condizioni iniziali (di partenza) del processo -Attivo → indica se il processo in questione è attivo (si) o non attivo (no) Raggiungimento sezione Process manager con tema next Per raggiungere la sezione Process manager con il tema “next” attivo bisogna effettuare i seguenti passaggi: 1) Cliccare sull’icona del profilo e successivamente sulla voce “Impostazioni” 2) Nel menu a sinistra cliccare sulla sezione “Business Process Manager” e successivamente sulla voce “Process manager” Raggiungimento sezione Process manager con tema next22 Per raggiungere la sezione Process manager con il tema “next22” attivo bisogna effettuare i seguenti passaggi: 1) Nel menu a sinistra cliccare sulla voce “Impostazioni”. 2) Sempre nel menu a sinistra cliccare sulla sezione “Business Process Manager” e successivamente sulla voce “Process manager” ELENCO FUNZIONALITA' Qui di seguito l’elenco delle funzionalità principali: -Eliminazione processo -Esportazione BPMN processo -Esportazione VTE BPMN processo -Importazione VTE BPMN su processo già esistente -Creazione processo -Importazione processo ex-novo Eliminazione processo Cliccando il pulsante mostrato in figura è possibile eliminare il processo in oggetto. 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. 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. Esportazione BPMN processo Cliccando il pulsante mostrato in figura è possibile esportare solamente la struttura grafica del processo escludendo quindi la configurazione. Esportazione VTE BPMN processo Cliccando il pulsante mostrato in figura è possibile esportare il processo al completo (struttura + configurazione). Importazione VTE BPMN su processo già esistente Cliccando il pulsante mostrato in figura è possibile Importare sul processo selezionato una nuova versione di quest’ultimo. Creazione processo Per generare un processo bisogna effettuare i seguenti passaggi: 1) Dirigersi sulla sezione Process manager (vedi paragrafo “Raggiungimento sezione Process manager con tema next” oppure “Raggiungimento sezione Process manager con tema next22” in base al tema utilizzato) 2) Cliccare sul pulsante NUOVO posizionato in alto a destra 3) Inserire un nome, una descrizione (non obbligatoria) e infine cliccare su “CREA NUOVO” Una volta completati i passaggi precedenti, l'utente verrà indirizzato sulla schermata finalizzata alla configurazione del diagramma di flusso del processo (vedi capitolo 1.4) Importazione processo ex-novo Per importare dei processi già esistenti, dopo essersi diretti nella sezione “Process manager” bisogna eseguire i seguenti passaggi: 1) Cliccare sul pulsante NUOVO posizionato in alto a destra 2) Inserire un nome, una descrizione (non obbligatoria) e infine cliccare su “IMPORTA...” Una volta completati i passaggi precedenti, l'utente verrà indirizzato sulla schermata finalizzata alla configurazione del diagramma di flusso del processo (vedi capitolo 1.4) 1.3 Configurazione Diagramma di Flusso e Left Menu DIAGRAMMA DI FLUSSO Per poter visualizzare il diagramma di flusso di un processo esistente si dovrà cliccare sul Nome dello stesso presente nella colonna "Nome" della sezione "Process Manager". (Figura 1) Figura 1 All'interno di tale sezione sarà possibile configurare tutti gli elementi facenti parte del diagramma cliccando direttamente su ognuno di essi. (Figura 2 e Figura 3) Figura 2 Figura 3 N.B: La configurazione dei singoli elementi verrà trattata nei capitoli successivi. Per poter eseguire delle modifiche al diagramma del processo si deve cliccare sul pulsante "Modifica Diagramma". (Figura 4) Figura 4 L'utente verrà reindirizzato nella sezione apposita e verranno messi a disposizione una serie di strumenti selezionabili dal Left Menù. Una volta completata la configurazione sarà sufficiente cliccare sul pulsante "Salva" per procedere con il salvataggio del diagramma. (Figura 5) Figura 5 Gli elementi utilizzabili per costruire il diagramma del processo saranno selezionabili rapidamente anche attraverso un menù rapido che diventerà disponibile al click di uno specifico elemento già coinvolto. (Figura 6) Figura 6 LEFT MENU Il Left Menu consiste in un Menu che può essere utilizzato durante la modifica del diagramma del processo e contiene: -una selezione rapida degli elementi principali utilizzabili per la creazione dei processi (Figura 7) -una serie di funzioni utili per una facile ed organizzata creazione dei flussi dei processi (Figura 7) N.B: Per tutti le voci legate ad elementi inseribili all'interno del diagramma, si dovrà trascinare l'elemento selezionato tenendo premuto con il pulsante sinistro del mouse e rilasciandolo sul punto desiderato. Figura 7 Hand Tool                                                                                                                                                                                                      Strumento utile per muovere la visuale in modo facile ed efficiente. Lasso Tool Strumento utile per muovere un gruppo di task/elementi contemporaneamente rendendo l’organizzazione e la strutturazione del flusso più facile e veloce. Create/Remove Space Tool Strumento utile per muovere tutte le task/elementi contemporaneamente rendendo l’organizzazione e la strutturazione del flusso facile e veloce. Start Event Permette di selezionare ed utilizzare lo Start Event. End Event Permette di creare e utilizzare l’End Event. Intermediate/Boundary Event Timer Permette di creare ed utilizzare l’Intermediate/Boundary Event. Gateway Permette di creare ed utilizzare i Gateway. Task Permette di creare ed utilizzare Task. Sub Process Permette di creare ed utilizzare i Sub Process. DataObjectReference                                                                                                                                                                                      Questo simbolo permette di svolgere un azione che al momento non è ancora stata implementata NOTA BENE: Dalla versione 24.08 è stata completamente rimossa DataStoreReference Questo simbolo permette di svolgere un azione che al momento non è ancora stata implementata NOTA BENE: Dalla versione 24.08 è stata completamente rimossa Pool/Participant Permette di creare delle aree in cui inserire parti del flusso del processo al di fuori delle quali non posso essere create task/elementi nuovi e nemmeno spostati. E’ possibile inoltre indicare a livello testuale gli attori coinvolti. NOTA BENE: Dalla versione 24.08 è stata completamente rimossa 1.4 Simbologia SIMBOLOGIA Qui in basso la simbologia utilizzata per creare un diagramma.                   START EVENT E TIMER START EVENT END EVENT INTERMEDIATE / BOUNDARY EVENT TIMER                   EXCLUSIVE GATEWAY E PARALLEL GATEWAY                   CONDITIONAL TASK E ACTION TASK CONNETTORI 1.5 Azioni BPMN Di seguito elencate le principali azioni BPMN: CREA ENTITA' AGGIORNA ENTITA' ELIMINA ENTITA' INVIA NOTIFICA INVIA EMAIL INVIA NEWSLETTER CREA PDF RESETTA FORM DINAMICA CICLA RIGHE RESETTA CAMPI CONDIZIONALI COLLEGA ENTITA' e COLLEGA ENTITA' STATICHE TRASFERISCI RELAZIONI INSERISCI RIGA TABELLA e INSERISCI RIGA PRODOTTO COPIA IL BLOCCO PRODOTTI CHIAMA WEB SERVICE ESTERNO CICLA RECORD RELAZIONATI 1.6 Sezione Process Helper: Introduzione e Modalità di Utilizzo INTRODUZIONE Il Process Helper, come si può dedurre dal nome, è uno strumento che viene in aiuto a chi configura i processi, fornendo la possibilità di creare delle “strutture” volte alla richiesta e storicizzazione di dati denominate “Form Dinamiche”. Sono composti da due macro-sezioni: CAMPI DI TESTATA FORM DINAMICA MODALITA’ DI UTILIZZO Nello specifico, ci sono diversi modi per sfruttare questo strumento, qui di seguito sono riportati quelli principali: 1) Utilizzo dei Process Helper (e relative Form Dinamiche) per creare maschere personalizzate presentabili agli utenti Interni/Esterni/Business Portal al fine di richiede e salvare informazioni Esempi: UTILIZZO PROCESS HELPER PER RICHIESTA DATI UTENTI INTERNI - VERSIONE STANDARD UTILIZZO PROCESS HELPER PER RICHIESTA DATI UTENTI INTERNI - VERSIONE PULSANTI RAPIDI UTILIZZO PROCESS HELPER PER RICHIESTA DATI UTENTI ESTERNI UTILIZZO PROCESS HELPER PER RICHIESTA DATI UTENTI BUSINESS PORTAL 2) Utilizzo dei Process Helper per attivare la sezione “Grafico processo” e poter: -monitorare lo stato di avanzamento di una singola istanza di processo con i relativi attori coinvolti -eseguire di manutenzione diretta sulle singole istanze attive dei processi Esempio: UTILIZZO PROCESS HELPER PER ATTIVAZIONE GRAFICO PROCESSO 3) Utilizzo dei Process Helper (e relative Form Dinamiche) per creare degli spazi virtuali nel quale immagazzinare dati o svolgere operazioni necessarie esclusivamente all’interno del processo (e che quindi sarebbe inutile storicizzare nei moduli del crm) Esempio: UTILIZZO PROCESS HELPER PER USO INTERNO PROCESSO 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". Dalla versione 26.07 per i campi di tipologia Picklist, è stata migliorata la logica di selezione dei valori da gestire. Nello specifico, i valori selezionabili vengono mostrati all'interno di un campo combo box multi-selezione permettendo la selezione di più valori contemporaneamente. Inoltre è stata aggiunta anche la voce "Valore Qualsiasi" per poter prendere facilmente in considerazione tutti i valori esistenti nella picklist senza quindi dover inserire manualmente eventuali nuovi valori inseriti in futuro. (Figura 12) Figura 12 - "è 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 13) 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 13 - "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 14) Figura 14 - "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 15) Figura 15 - "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 16) Figura 16 - "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 17) Figura 17 - "in" -> dalla versione 26.07 è disponibile questo operatore che permette di verificare se il valore presente in un campo picklist corrisponde almeno ad uno tra i valori specificati all'interno della condizione. (Figura 18) Figura 18 - "non in" -> dalla versione 26.07 è disponibile questo operatore che permette di verificare se il valore presente in un campo picklist NON corrisponde a nessuno tra i valori specificati all'interno della condizione. (Figura 19) Figura 19 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", "in", "non in" 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 condizioni 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 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 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). 3 Azioni BPMN 3.0 Modalità di Esecuzione delle Azioni BPMN Per ogni azione BPMN configurabile all'interno dei processi (Figura 1), è possibile selezionate una tra le seguenti modalità di esecuzione: - Standard -> l'azione viene eseguita nell'istante in cui il processo si posiziona sull'Action Task in cui è configurata, chiaramente il processo attende sempre che l'azione venga completata prima di procedere con l'esecuzione delle azioni successive previste dal flusso - Background -> l'esecuzione dell'azione viene delegata ad un cron/worker, quindi non viene eseguita nell'istante in cui il processo si posiziona sull'Action Task in cui è configurata ma entra all'interno di una coda specifica, chiaramente il processo attende sempre che l'azione venga completata prima di procedere con l'esecuzione delle azioni successive prevista dal flusso, quindi in questo specifico caso di può parlare di una vera e propria "interruzione" del processo. Figura 1 3.1 Crea Entità Questa azione permette di creare record di entità presenti all'interno del sistema (moduli base o custom). Per ogni singolo campo è possibile settare un valore statico o dinamico (preso quindi dalle entità coinvolte nel processo stesso) (Figura 1) Figura 1 Per selezionare un valore dinamico, il sistema mette a disposizione la picklist "Seleziona opzione" dalla quale è possibile accedere ai campi delle entità dei modulo coinvolti all'interno del processo (Figura 2) Figura 2 ATTENZIONE: per i campi di tipologia "Picklist" e "Utente", per poter utilizzare il campo "Seleziona opzione" si dovrà prima selezionare la voce "Altro" della picklist disponibile a sinistra (Figura 3) Figura 3 NOTA BENE: il sistema esegue in automatico un filtro basandosi sul campo di partenza dal quale si sta consultando la picklist "Seleziona opzioni", di conseguenza mostrerà solamente i campi la cui tipologia può essere accettata dal campo di partenza. Se, ad esempio, all'interno del campo "Collegato a" del modulo Assistenza Clienti volessi inserire il contenuto del campo di tipo testo "Cognome" del modulo Lead, il sistema non renderò disponibile tale campo, questo perché permetterà di selezionare solamente le colonne del campo tabella di tipologia "Relazionato a". (Figura 4) Figura 4 Inoltre, sempre dall'azione di Crea entità, abbiamo la possibilità di attivare un re-direct alla nuova entità creata oppure ad una entità coinvolta nel processo. (Figura 5) Figura 5 Cliccando sul pulsante "Nuova entità creata", l'utente verrà reindirizzato al nuovo record creato in questa specifica azione. Invece, selezionando l'ID di una delle altre entità coinvolte nel processo, il sistema reindirizzerà l'utente sul record di quel specifico modulo. Creazione Eventi a Calendario: funzione Avvisa Dalla versione 26.04 è possibile configurare ed abilitare l'invio di promemoria automatici attraverso la sezione dedicata. (Figura 6) Figura 6 3.2 Aggiorna entità Questa azione permette di aggiornare un'entità (istanza di un modulo) coinvolta direttamente nel processo o comunque un'entità relazionata ad esse. Per ogni singolo campo è possibile riportare dei valori statici o dinamici (presi quindi dalle entità coinvolte nel processo stesso). Figura 1 Per selezionare un valore dinamico, il sistema mette a disposizione la picklist "Seleziona opzione" dalla quale è possibile accedere ai campi delle entità dei modulo coinvolti all'interno del processo (Figura 2) Figura 2 ATTENZIONE: per i campi di tipologia "Picklist" e "Utente", per poter utilizzare il campo "Seleziona opzione" si dovrà prima selezionare la voce "Altro" della picklist disponibile a sinistra (Figura 3) Figura 3 NOTA BENE: il sistema esegue in automatico un filtro basandosi sul campo di partenza dal quale si sta consultando la picklist "Seleziona opzioni", di conseguenza mostrerà solamente i campi la cui tipologia può essere accettata dal campo di partenza. Se, ad esempio, all'interno del campo "Collegato a" del modulo Assistenza Clienti volessi inserire il contenuto del campo di tipo testo "Cognome" del modulo Lead, il sistema non renderò disponibile tale campo, questo perché permetterà di selezionare solamente le colonne del campo tabella di tipologia "Relazionato a". (Figura 4) Figura 4 Dalla versione 24.08 è possibile aggiornare anche i campi di tipo "Relazionato a" creati all'interno delle form dinamiche dei process helper (Figura 5) Figura 5 3.3 Elimina entità Questa azione permette di eliminare un'entità (istanza del modulo) coinvolta all'interno del processo. NOTA BENE: il record eliminato da questa azione non viene cancellato completamente dal Data Base ma viene inserito nella sezione "Cestino". Per evitare che l'utente riscontri un messaggio di errore (trovandosi su un record eliminato), solitamente si utilizza la funzione di redirect per reindirizzare l'utente in un'istanza nuova (appena creata) o già esistente. 3.4 Invia notifica Questa azione permette di inviare notifiche interne agli utenti del sistema visualizzabili nella sezione “Notifiche” contrassegnata da un’icona raffigurante una campanella nel menù in alto a destra. Figura 1 CAMPI PRINCIPALI - Descrizione -> rappresenta il corpo della notifica; è possibile settare un testo specifico con dati statici e/o dinamici appartenenti alle entità coinvolte nel processo. - Creato da -> rappresenta l’utente che risulterà essere il creatore della notifica (mittente) - Assegnato a -> rappresenta l’utente che risulterà essere il destinatario della notifica - Collegato a -> rappresenta l’entità (istanza di un modulo) alla quale verrà agganciata la notifica Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) In base alle preferenze dell’utente le notifiche possono essere inviate come vere e proprie notifiche interne nella modalità descritta sopra oppure come classiche email (Figura 3) Figura 3 Nel caso sia stata impostata la modalità “Email” dovranno essere compilati i seguenti campi aggiuntivi (Figura 4) - Oggetto -> rappresenta l’oggetto che avrà la mail - Mail mittente -> rappresenta la mail del mittente - Nome mittente -> rappresenta l’alias relativo al mittente Figura 4 3.5 Invia Email Questa azione permette di inviare email automatiche con la possibilità di allegare documenti e collegare la mail ad un’entità (standard o custom) in maniera tale che rimanga storicizzata. Nel corpo dell'email è possibile riportare oltre ai classici valori statici e/o dinamici altre funzioni generali come la data/ora attuale, il link all'entità desiderata (interno per gli utenti o esterno per i clienti lato portale) (Figura 1) Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) CAMPI PRINCIPALI -Server SMTP → dalla versione 23.08 è possibile indicare la modalità di utilizzo dell'account di server di posta in uscita da utilizzare come mittente. (Figura 2) Figura 2 - Default → nel caso in cui nel modulo Messaggi dell'utente indicato sia presente un account configurato, il sistema utilizzerà il server ad esso associato, nel caso in cui non sia configurato alcun account il sistema utilizzerà il server presente in  Impostazioni -> Server di Posta. - Custom → è possibile configurare un account di posta in uscita direttamente all'interno dell'azione di invio mail. (Figura 3) Figura 3 - Globale → il sistema utilizzerà esclusivamente il server configurato in Impostazioni -> Server di Posta. Oltre alle tre modalità appena descritte, sarà possibile selezionare uno tra gli account configurati nel modulo Messaggi degli utenti attualmente attivi presenti nel sistema. -Da → rappresenta il mittente della mail -A → rappresenta il destinatario della mail -CC → rappresenta gli indirizzi in copia -CCN → rappresenta gli indirizzi in copia nascosta -Rispondi a → rappresenta l'indirizzo al quale verrebbe inviata un’eventuale risposta alla mail automatica -Oggetto → rappresenta l’oggetto della mail -Relaziona email a → è possibile indicare l’entità al quale collegare la mail automatica.  La voce "Automatico (default)" permette di associare la mail all'entità sulla quale il processo si è scatenato -Allega documenti da → è possibile selezionare l’entità da cui prendere i documenti collegati ad essa ed allegarli alla mail. Cliccando la voce “Tutti” il sistema allegherà TUTTI i documenti collegati all'entità. (Figura 4) Figura 4 Ciccando la voce "Filtrato” il sistema allegherà i documenti che rispettano le condizioni inserite nella sezione "Condizioni" (Figura 5) Figura 5 (cliccare sull'immagine per una risoluzione grafica maggiore) 3.6 Invia Newsletter Questa azione permette di inviare una newsletter direttamente da processo relativa ad una campagna statica o dinamica definita all’interno del campo “Campagna”. CAMPI PRINCIPALI - Campagna -> rappresenta il campo attraverso il quale si definisce la campagna relativa alla newsletter che verrà inviata. In base alla situazione è possibile selezionare una delle seguenti opzioni: - Crea nuova ogni volta -> il sistema creerà una nuova campagna ogni volta che partirà il processo. - Crea e poi riutilizza la stessa campagna -> il sistema creerà una campagna solo la prima volta che partirà il processo, quindi le        volte successive utilizzerà la campagna creata la prima volta. - Esistente -> permette di selezionare una campagna esistente - Dal processo -> permette di selezionare un record del modulo Campagne coinvolto nel processo - Nome Mittente -> rappresenta l’alias relativo al mittente della newsletter - Indirizzo Mittente -> rappresenta la mail del mittente della newsletter - Destinatari -> permette di selezionare dei record statici oppure presi da entità coinvolte direttamente nei processi. N.B: possono essere selezionati I record appartenenti ai moduli Aziende, Contatti, Target e Lead. - Oggetto -> rappresenta l’oggetto della newsletter - Template Email -> rappresenta il template Email che verrà utilizzato come corpo della newsletter. - Corpo -> Attraverso l’ Editor è possibile modificare il corpo inserendo del testo statico/dinamico oppure del codice HTML/CSS Dalla versione 26.04 sono stati aggiunti i seguenti campi configurabili: - Language -> permette di indicare una lingua di riferimento - Reply To -> permette di inserire un indirizzo mail al quale verrà indirizzata un'eventuale risposta al mittente della newsletter Figura 1 3.7 Crea PDF Questa azione permette di creare un documento PDF utilizzando un template definito nella sezione "PDFmaker". CAMPI PRINCIPALI - Entità documento PDF -> permette di selezionare un’entità sulla quale generare il PDF. N.B: non è possibile selezionare un’entità (istanza di un modulo) se non è presente nessun Template PDF relativo ad essa - Titolo PDF -> indica il titolo del PDF - Relaziona PDF a -> rappresenta l’id dell’entità coinvolta nel processo alla quale si vuole relazionare il PDF - Lingua template PDF -> rappresenta la lingua del Template PDF (italiano o inglese) - Assegnato a -> rappresenta l’utente assegnatario del PDF - Template PDF -> permette di selezionare uno tra i template disponibili per l’entità selezionata. - Cartella documenti -> permette di selezionare la cartella in cui salvare il PDF Figura 1 3.8 Resetta Form Dinamica Dalla versione 25.02.2 è stata rinominata in "Azzera form dinamica". Questa azione è riferita all'utilizzo del Process Helper e permette di pulire il contenuto dei campi presenti nella Form dinamica dai valori che sono stati inseriti durante la compilazione della stessa. Si utilizza principalmente per permette la ri-compilazione della form dinamica. Di default, eventuali valori di Default inseriti prima della compilazione effettiva della form dinamica verranno ripristinati. (Figura 1) Figura 1 Invece, per svuotare completamente il contenuto dei campi presenti nella form dinamica ignorando eventuali valori di default inseriti prima della sua compilazione effettiva, si deve spuntare il flag “Svuota campo”. (Figura 2) Figura 2 ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo di un'azione di resetta form dinamica per gestire un eventuale ri-compilazione del campo "Data Intervento" di una form dinamica. Il campo in questione presenta, come valore di default, la data di oggi. (Figura 3) Figura 3 In fase di compilazione della form dinamica, l'utente può modificare il contenuto del campo inserendo manualmente la data effettiva di intervento nel caso in cui non coincidesse con la data di oggi. Nel caso in cui, per un qualsiasi motivo, dovesse essere ricompilata la form dinamica, configurando un'azione di resetta form dinamica (PRIMA della configurazione del process helper) senza spuntare il flag “Svuota campo”, il sistema eliminerà l'eventuale data di intervento inserita dall'utente e ripristinerà la data di oggi. Al contrario, configurando un'azione di resetta form dinamica (PRIMA della configurazione del process helper) spuntando il flag “Svuota campo”, il sistema eliminerà sia l'eventuale data di intervento inserita dall'utente che la data di oggi inserita di default, presentando di fatto all'utente il campo vuoto. 3.9 Cicla Righe Questa azione permette di ciclare e quindi gestire dinamicamente le righe di un campo tabella o di un blocco prodotti. NOTA BENE: nel caso in cui nell'entità principale coinvolta nel processo e i relativi moduli relazionati non fosse presente alcun blocco prodotti o campo tabella, l'azione non sarà visibile tra l'elenco delle azioni selezionabili tramite il pulsante "Nuova azione". Per i dettagli sul come utilizzare i campi del blocco prodotti o del campo tabella ciclati all'interno dei processi (es. valore "Corrente") si consiglia di consultare il capitolo 10.1 del manuale dei processi. Per ogni riga ciclata è possibile eseguire una delle seguenti operazioni: Invia email Permette di inviare una mail per ogni riga che rispetta le condizioni impostate nella sezione “condizioni sul campo”. (Figura 1) Per considerare tutte le righe basterà lasciare non compilata quella sezione.  Figura 1 Crea entità Permette di creare un’entità di un qualsiasi modulo (standard o custom) per ogni riga che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figura 2) Per considerare tutte le righe basterà lasciare non compilata quella sezione.  Figura 2 Aggiorna entità Permette di aggiornare un’entità coinvolta nel processo per ogni riga che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figura 3) Per considerare tutte le righe basterà lasciare non compilata quella sezione.  Figura 3 Invia notifica Permette di inviare una notifica per ogni riga che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figura 4) Per considerare tutte le righe basterà lasciare non compilata quella sezione.  Figura 4 Inserisci riga tabella Permette di inserire una riga in un campo tabella presente nelle entità coinvolte nei processi o nelle form di process helper per ogni riga che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figure 5, 6 e 7) Per considerare tutte le righe basterà lasciare non compilata quella sezione. Figura 5 Figura 6 Figura 7 Inserisci riga prodotto Permette di inserire una riga in un blocco prodotti presente nelle entità coinvolte nei processi per ogni riga che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figure 8, 9 e 10) Per considerare tutte le righe basterà lasciare non compilata quella sezione. Figura 8 Figura 9 Figura 10 Elimina riga prodotto Permette di eliminare una riga in un blocco prodotti presente nelle entità coinvolte nei processi per ogni riga che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figura 11) Per considerare tutte le righe basterà lasciare non compilata quella sezione. N.B: questa opzione sarà presente solo se si sta ciclando le righe di un blocco prodotti. Figura 11 Elimina riga tabella Permette di eliminare una riga in un campo tabella presente nelle entità coinvolte nei processi o nelle form di process helper ogni riga che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. Per considerare tutte le righe basterà lasciare non compilata quella sezione. (Figura 12) N.B: questa opzione sarà presente solo se si sta ciclando le righe di un campo tabella.  Figura 12 Funzione SDK Permette di eseguire una funzione SDK di tipologia Action per ogni riga che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figura 13 e 14) N.B: questa funzionalità è disponibile solamente dalla versione 25.02 in poi. Figura 13 Figura 14 3.10 Resetta Campi Condizionali Questa azione è riferita all'utilizzo di campi condizionali lato processo.  Infatti, è possibile settare campi condizionali sull'entità selezionata (coinvolta nel processo) oppure basati sulle Form Dinamiche presenti nel processo. Nel caso di campi condizionali sull'entità, questi prevalgono sui campi condizionali settati lato amministratore. Quest'ultimi vengono disabilitati sino al termine del processo o ad una task di azione "Resetta campi condizionali". (Figura 1) Figura 1 3.11 Collega Entità e Collega Entità Statiche COLLEGA ENTITA' Questa azione permette di relazionare tra loro 2 entità dinamiche che presentano una relazione N - N. Le 2 entità infatti non presentano un campo relazionato tra loro, bensì la relazione ad N. (Figura 1) Figura 1 COLLEGA ENTITA' STATICHE Questa azione permette di relazionare ad una entità dinamica del processo una o più entità statiche tra quelle proposte. Si rende utile per esempio per relazionare entità comuni a più casistiche del flusso stesso, es. relazionare lo stesso documento (informativa privacy, checklist, ecc.) (Figura 2) Figura 2 3.12 Trasferisci Relazioni Questa azione permette di trasferire/copiare le entità relazionate da un'entità ad un'altra del processo. Nel caso di relazione 1 - N i record saranno trasferiti, mentre nel caso di relazione N - N i record saranno copiati. Tale azione si rende utile in flussi di conversione entità dove l'entità di partenza viene convertita in altro e quindi tutte le entità collegate alla vecchia possono essere trasferite/copiate nella nuova. (Figura 1) Es. In un processo di conversione da lead a contatto/azienda tutte le entità che erano collegate al vecchio lead possono essere trasferite/copiate al nuovo contatto/azienda. Infine è possibile eliminare il lead senza perdere quindi tutte le azioni che erano collegate a questo. Figura 1 3.13 Inserisci Riga Tabella e Inserisci Riga Prodotto INSERISCI RIGA TABELLA Questa azione permette di inserire delle righe in un campo tabella(Figura 1 e 2) NOTA BENE: nel caso in cui nell'entità principale coinvolta nel processo e i relativi modulo relazionati non fosse presente alcun campo tabella, l'azione non sarà visibile tra l'elenco delle azioni selezionabili tramite il pulsante "Nuova azione". I valori inseriti possono essere statici e/o dinamici (presi quindi dalle entità coinvolte nel processo). Figura 1 Figura 2 INSERISCI RIGA PRODOTTO Questa azione permette di inserire delle righe in un blocco prodotti (Figura 3 e 4) NOTA BENE: nel caso in cui nell'entità principale coinvolta nel processo e i relativi modulo relazionati non fosse presente alcun blocco prodotti, l'azione non sarà visibile tra l'elenco delle azioni selezionabili tramite il pulsante "Nuova azione". I valori inseriti possono essere statici e/o dinamici (presi quindi dalle entità coinvolte nel processo). Figura 3 Figura 4 3.14 Copia il Blocco Prodotti Questa azione permette di copiare il blocco prodotti tra entità coinvolte nel processo. (Figura 1) N.B: entrambe le entità devono possedere un blocco prodotti.  Figura 1 Tutti i campi presenti a standard verranno copiati in automatico, invece i campi custom verranno copiati solo se presente una mappatura specifica all'interno dell'apposita sezione "Mappatura Campi" configurabile direttamente dal blocco prodotti del Layout Editor del modulo coinvolto. (Figura 2) Figura 2 3.15 Chiama Web Service Esterno Permette di richiamare un Web Service esterno di tipo REST precedentemente configurato su Impostazioni -> Business Process Manager -> Webservice REST. (Figura 1 e 2) Figura 1 Figura 2 - Nome → Permette di definire un nome al WS che stiamo configurando, utile per: 1) rendere più semplice ed intuitiva la sua selezione lato processo 2) rendere più facile il suo riconoscimento nella lista dei WS per un eventuale modifica lato interfaccia - Descrizione → Permette di definire una descrizione al WS che stiamo configurato, utile per inserire specifiche di dettaglio in merito al suo funzionamento - Attivo → Se impostato, permette il suo utilizzo lato processi - Tipo → Permette di definire la tipologia di WS da richiamare, al momento è possibile selezionare solamente la voce "REST" - Metodo → Permette di definire il metodo HTTP da utilizzare per la richiesta, è possibile selezionare uno tra i seguenti valori: "GET","HEAD","POST","PUT","DELETE","OPTIONS","PATCH" - Indirizzo → Permette di definire l'endpoint del WS che stiamo configurando, come ad esempio https://mywebsite.example.com/api/ - Autenticazione → Permette di definire il metodo di autenticazione utilizzato per richiamare il WS, nello specifico: 1) Basic: permette di definire un Nome utente e relativa Password statica con il quale il WS eseguirà l'autenticazione 2) Bearer (OAuth2): permette di eseguire un autenticazione a 2 fattori - Client ID: rappresenta l'ID per accedere all'applicazione - Autenticazione Client Secret: rappresenta la chiave segreta da utilizzare per autenticarsi correttamente - Autenticazione Chiave Privata (PEM o JWK): permette di caricare una file di tipo PEM o JWK che rappresenta la chiave privata da utilizzare per autenticarsi correttamente - Scope: permette di definire lo scope, ovvero quali operazioni sono ammesse dal sistema (sola lettura, sola scrittura, oppure in lettura/scrittura) - Token URL: permette di definire l'URL da utilizzare come Token - Headers → Permette di definire i parametri headers richiesti dal WS che stiamo configurando Solitamente, la necessità di tali parametri dipende dalla struttura del WS e pertanto viene definita all'interno della sua documentazione dedicata. - Parametri → Permette di definire i parametri in input richiesti dal WS che stiamo configurando Solitamente, la necessità di tali parametri dipende dalla struttura del WS e pertanto viene definita all'interno della sua documentazione dedicata. - Corpo grezzo → Permette di passare un unica stringa in formato JSON contenente tutti i parametri in input richiesti dal WS che stiamo configurando Solitamente, la necessità di mappare tale sezione dipende dalla struttura del WS e pertanto viene definita all'interno della sua documentazione dedicata. - Campi restituiti → Permette di salvare N parametri restituiti in output dal WS Solitamente, la necessità di tali campi dipende dalla struttura del WS e pertanto viene definita all'interno della sua documentazione dedicata. Nel caso di risposte complesse (oggetto con più attributi) è possibile eseguire un'estrazione su più livelli (indicando nome campo restituito e attributo, es. object.attribute, object.list.0.attribute). Prendendo quindi in considerazione il seguente JSON come esempio: { "object1":{ "attribute1" : "value1", "attribute2" : "value2", "attribute3" : "value3", }, "object2" : "value4" } Per ottenere direttamente come risposta il valore del parametro "attribute2", si dovrà eseguire la configurazione riportata in Figura 3 Figura 3 - Pulsante Prova Web Service → Permette di eseguire un test di chiamata restituendo un popup con il Codice di ritorno, il Messaggio della risposta, lo Stato e l'Output previsto dal WS. Quindi, una volta configurato il WS lato Impostazioni -> Business Process Manager -> Webservice REST, sarà possibile richiamare tale WS all'interno dei processi (Figura 4 e 5). Figura 4 Figura 5 Al fine di spiegare al meglio la configurazione di tale azione all'interno di un processo, qui di seguito viene riportato un esempio di configurazione di una chiamata WS. L'obiettivo del processo è quello di generare, all'attivazione di un collaboratore su Vtenext, un utente su un sistema esterno associato ad esso. Il WS richiede in input un JSON con la seguente struttura: { "firstname" : "Mario", "lastname" : "Rossi", "type" : "Dipendente Interno", "email" : "mariorossi@test.com", "status" : "Active" } In caso di esito positivo, verrà restituito Codice della risposta = 201 e come output un JSON contenente diversi variabili, tra cui l'id dell'utenza creata, qui di seguito un esempio del JSON: {   "firstname":"Mario",   "lastname":"Rossi",   "type":"Dipendente Interno",   "email":"mariorossi@test.com",   "status":"Active",   "id":"532",   "createdAt":"2025-07-03T13:05:11.752Z" } Per prima cosa, all'interno di Impostazioni -> Business Process Manager -> Webservice REST eseguiamo al configurazione iniziale del WS (Figura 6) Figura 6 Successivamente, creiamo un processo avente il diagramma di flusso mostrato in figura 7: Figura 7 Nella ServiceTask "Chiamata WS" configuriamo l'azione di chiamata WS esterno. (Figura 8) Figura 8 Il sistema ha riportato in automatico tutti gli elementi configurati in Impostazioni -> Business Process Manager -> Webservice REST. In aggiunta, è possibile definire ulteriori Headers, Parametri e Campi restituiti potendo passare quindi valori dinamici presi dai record coinvolti all'interno del processo. ATTENZIONE! → in alcuni casi, i parametri Headers ereditati dalla configurazione eseguita in Impostazioni -> Business Process Manager -> Webservice REST verranno impostati di default come null (Figura 9) Figura 9 Di conseguenza, per fare in modo che la chiamata WS funzioni correttamente, si dovrà selezionare una tra voce "Default" disponibile nella picklist "Seleziona opzioni" presente in alto a destra di ogni campo. (Figura 10) Figura 10 All'interno del Corpo grezzo, modifichiamo il JSON di partenza inserendo dinamicamente il contenuto dei campi del modulo Collaboratore associato al processo. Nella ScriptTask "Storicizza risposta WS" attiviamo un process helper e nella sua form dinamica andiamo a creare 4 campi testuali (Figura 11). Infatti, la chiamata WS di default restituisce le variabili "Codice della risposta", "Messaggio della risposta" e "Esito Positivo?" (1 se la chiamata ha avuto esito positivo, 0 se ha avuto esito negativo). Infine, andiamo a creare il campo "id" all'interno del quale andremo a storicizzare l'output previsto dal WS che ci interessa, ossia l'id esterno dell'utenza creata. Figura 11 Per mapparne il contenuto, all'interno della picklist "Seleziona opzioni", il sistema mette a disposizione una sezione dedica per le chiamate WS con relativo metaid (Figura 12) Figura 12 Nella Task "Controllo Chiama WS" andiamo ad eseguire un controllo sul contenuto del campo "Codice della risposta" ed "Esito Positivo?" e instradiamo il processo in due rami differenti (Figura 13) Figura 13 Le ScriptTask finali "OK" e "KO" mostrate nel diagramma di flusso del processo potranno essere configurate a piacimento, ad esempio per storicizzare l'output del WS (quindi l'id dell'utenza creata nel sistema esterno) all'interno di un campo dedicato nell'anagrafica del collaboratore, oppure mandare una mail/notifica al reparto IT in caso di chiamata non andata a buon fine. 3.16 Cicla Record Relazionati Questa azione permette di utilizzare i record (istanze di un modulo) aventi una relazione 1- N o N - N con il modulo di partenza. Per poter sfruttare i dati dei record ciclati all'interno dell'azione, il sistema mette a disposizione (nella picklist "Seleziona opzione") una sezione dedicata (Figura 1) Figura 1 Cliccando sulla sezione specifica, il sistema permette di selezionare rapidamente uno tra i campi presenti nel modulo relazionato preso in esame (Figura 2) Figura 2 NOTA BENE: il sistema esegue in automatico un filtro basandosi sul campo di partenza dal quale si sta consultando la picklist "Seleziona opzioni", di conseguenza mostrerà solamente i campi la cui tipologia può essere accettata dal campo di partenza. Se, ad esempio, all'interno del campo "Membro di" del modulo Azienda volessi inserire il contenuto del campo di tipo testo "Indirizzo", il sistema non renderò disponibile tale campo, questo perché permetterà di selezionare solamente i campi di tipologia "Relazionato a". Una volta selezionato il campo del modulo relazionato che si sta ciclando, verrà presentata un'ulteriore picklist alla destra del campo "Seleziona opzioni", dalla quale sarà possibile selezionare una tra le voci disponibili (Figura 3) Figura 3 - "Somma" -> solo per i campi di tipologia Numero, Valuta e Percentuale, permette di ottenere la somma di TUTTI i record del modulo relazionato interessato (collegati al modulo di partenza). ATTENZIONE! -> Questa voce ignora le condizioni inserite nella sezione "Condizioni". Per approfondire la gestione della somma parziale dei record del modulo relazionato interessato (collegati al modulo di partenza) consultare il capitolo 9.1 del manuale dei processi. NOTA BENE: questa voce sarà comunque disponibile anche per le altre tipologie di campi ma, logicamente, non produrrà alcun risultato. -"Minimo" -> solo per i campi di tipologia Numero, Valuta e Percentuale, permette di ottenere il valore più basso tra TUTTI i record del modulo relazionato interessato (collegati al modulo di partenza). ATTENZIONE! -> Questa voce ignora le condizioni inserite nella sezione "Condizioni". NOTA BENE: questa voce sarà comunque disponibile anche per le altre tipologie di campi ma, logicamente, non produrrà alcun risultato. -"Massimo" -> solo per i campi di tipologia Numero, Valuta e Percentuale, permette di ottenere il valore più alto tra TUTTI i record del modulo relazionato interessato (collegati al modulo di partenza). ATTENZIONE! -> Questa voce ignora le condizioni inserite nella sezione "Condizioni". NOTA BENE: questa voce sarà comunque disponibile anche per le altre tipologie di campi ma, logicamente, non produrrà alcun risultato. -"Media" -> solo per i campi di tipologia Numero, Valuta e Percentuale, permette di ottenere il valore medio tra TUTTI i record del modulo relazionato interessato (collegati al modulo di partenza). ATTENZIONE! -> Questa voce ignora le condizioni inserite nella sezione "Condizioni". NOTA BENE: questa voce sarà comunque disponibile anche per le altre tipologie di campi ma, logicamente, non produrrà alcun risultato. -"Ultimo" -> permette di ottenere il valore dell'ultimo record del modulo relazionato interessato (collegati al modulo di partenza). ATTENZIONE! -> Questa voce ignora le condizioni inserite nella sezione "Condizioni". -"Corrente" -> permette di ottenere il valore corrente, ovvero il valore del record del modulo relazionato interessato (collegati al modulo di partenza) che si sta ciclando in quel preciso momento ATTENZIONE! -> Questa voce è l'unica che rispetta le condizioni inserite nella sezione "Condizioni". -"Sequenza" -> permette di ottenere il valore di un record specifico (se presente) del modulo relazionato interessato (collegati al modulo di partenza). ATTENZIONE! -> Questa voce ignora le condizioni inserite nella sezione "Condizioni". Per indicare esattamente il numero del record si dovrà compilare il campo che verrà presentato sulla destra e infine cliccare sul pulsante dedicato (Figura 4) Figura 4 (cliccare sull'immagine per una risoluzione grafica maggiore) Per prendere in considerazione solamente una parte dei record relazionati, è possibile indicare delle condizioni che permettono di coinvolgere solamente i record che le soddisfano. Queste condizioni dovranno essere indicate nella sezione "Condizioni sul campo" (Figura 5) Figura 5 (cliccare sull'immagine per una risoluzione grafica maggiore) Per ogni record ciclato è possibile eseguire una delle seguenti operazioni: Invia email Permette di inviare una mail per ogni record che rispetta le condizioni impostate nella sezione “condizioni sul campo”. (Figura 6) Per considerare tutti i record basterà lasciare non compilata quella sezione. Figura 6 Crea entità Permette di creare un’entità di un qualsiasi modulo (standard o custom) per ogni record che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figura 7) Per considerare tutti i record basterà lasciare non compilata quella sezione. Figura 7 Aggiorna entità Permette di aggiornare un’entità coinvolta nel processo per ogni record che rispetta le condizioni impostate nella sezione “Condizioni”. (Figura 8) Per considerare tutti i record basterà lasciare non compilata quella sezione. Figura 8 Invio notifica Permette di inviare una notifica per ogni record che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figura 9) Per considerare tutti i record basterà lasciare non compilata quella sezione.  Figura 9 Inserisci riga tabella Permette di inserire una riga in un campo tabella presente nelle entità coinvolte nei processi o nelle form di process helper per ogni record che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figure 10 e 11) Per considerare tutti i record basterà lasciare non compilata quella sezione. Figura 10 Figura 11 Crea PDF Permette di creare un PDF per ogni record che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figura 12) Per considerare tutti i record basterà lasciare non compilata quella sezione. Figura 12 Funzioni SDK Permette di lanciare una funzione SDK di tipologia Action per ogni record che rispetta le condizioni impostate nella sezione “Condizioni sul campo”. (Figura 13 e 14) N.B: questa funzionalità è disponibile solamente dalla versione 25.02 in poi. Figura 13 Figura 14 3.17 Importa Azioni da... Questa funzionalità permette di duplicare un'azione già configurata all'interno della stessa Action Task o di un' altra presente all'interno dello stesso processo. Risulta essere uno strumento molto utile e pratico nel momento in cui si necessita di creare un'azione simile ad una già esistente evitando di dover riconfigurare da zero tutto il suo contenuto. Per procedere con la duplicazione di un'azione si deve cliccare il pulsante "Importa azioni da..." disponibile in alto a destra di ogni Action Task. (Figura 1) Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) Il sistema presenterà l'elenco di tutte le azioni configurare all'interno del processo e sarà possibile selezionare quelle da duplicare, anche più di una contemporaneamente se necessario. (Figura 2) Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) Al salvataggio verranno generate le nuove azioni selezionate e alla Descrizione verrà aggiunto il tag [importata]. (Figura 3) Figura 3 (cliccare sull'immagine per una risoluzione grafica maggiore) A questo punto sarà possibile apportare le modifiche necessarie al contenuto dell'azione appena duplicata entrando in modifica della stessa. 3.A Azioni AI Queste azioni permettono di integrare i nuovi Strumenti AI all'interno dei processi e quindi automatizzarne l'utilizzo. 3.A.1 Chiama LLM Permette di eseguire una richiesta ad un LLM precedentemente configurato in Impostazioni > Strumenti AI > LLM. Una volta selezionato uno tra i modelli LLM disponibili verranno caricati tutti gli elementi configurati in Impostazioni > Strumenti AI > LLM e potranno essere personalizzati. Figura 1 In aggiunta, è possibile definire ulteriori Headers, Parametri e Campi restituiti potendo passare quindi valori dinamici presi dai record coinvolti all'interno del processo. Di default è già configurato il campo con il contenuto della risposta del modello (Figura 2) che potrà essere richiamato per applicarlo nelle successive fasi del processo (Figura 3). Figura 2 Figura 3 3.A.2 Chiama tool MCP Permette di eseguire una richiesta al tool di un server MCP precedentemente configurato in Impostazioni > Strumenti AI > MCP Client. Questa azione permette di ottenere la risposta ad un tool MCP in maniera deterministica diversamente da quello che potrebbe fare un agente. L'utente potrebbe quindi implementare un proprio "agente" all'interno di un processo facendo interagire chiamate a LLM e a tool MCP. Una volta selezionato uno tra i client MCP disponibili e il tool desiderato verranno caricati i Parametri di input previsti dal tool e i Campi restituiti che potranno essere modificati in base alla risposta del tool. Figura 1 - esempio di chiamata ad un tool di ricerca web Normalmente i tool restituiscono il risultato in un formato adatto ad essere interpretato da un modello LLM quindi va verificata la risposta per includerla nel flusso di un processo. es. di risposta del tool web_search_exa alla domanda "qual'è l'indirizzo email PEC dell'azienda VTENEXT?" Title: Contatti - vtenext CRM + BPM URL: https://www.vtenext.com/it/contatti/ Published: 2021-01-28T21:00:22.000Z Author: N/A Highlights: info@vtenext.com Viale Sarca, 336/F 20126 Milano (MI) Tel (+39) 02 3790 1352 P.I. 09869110966 Registration Number MI – 2118732 --- Title: Fatturato Vtenext Srl (MI) – Scarica Bilanci e Visure Camerali Ufficiali URL: https://www.companyreports.it/vtenext-srl-09869110966 Published: N/A Author: N/A Highlights: **Indirizzo** Viale Sarca, 336/F - [Milano (](https://www.companyreports.it/comune/milano "Vedi le aziende del comune di Milano")[MI](https://www.companyreports.it/provincia/milano "Vedi le aziende della provincia di Milano")) ... ** ** ... ## **Visura Camerale di Vtenext Srl** La visura camerale di **Vtenext Srl** fornisce una panoramica completa dell’assetto legale e societario dell’impresa: sede legale, capitale sociale, oggetto sociale, elenco soci, cariche in corso e indirizzo PEC. La visura è disponibile in formato ordinario o storico ed è scaricabile in tempo reale da **CompanyReports.it**. ### **Bilanci e Documenti Aziendali di Vtenext Srl** ... PEC * ... * Email PEC * Codice di fatturazione ... ```json { "@context": "https://schema.org", "@type": "Organization", "name": "CompanyReports", "url": "https://www.companyreports.it", "logo": "https://www.companyreports.it/dist/img/companyreports-logo-new.webp", "contactPoint": { "@type": "ContactPoint", "contactType": "sales", "email": "info@adcapital.it" } } ... { "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Vtenext Srl", "legalName": "Vtenext Srl", "image": "https://www.companyreports.it/og-image-Fatturato%20Vtenext%20Srl%20%28MI%29%20%E2%80%93%20Scarica%20Bilanci%20e%20Visure%20Camerali%20Ufficiali.jpg", "vatID": "09869110966", "taxID": "09869110966", "foundingLocation": "MI", "foundingDate": "2017-04-04", "isicV4": "6201", "knowsAbout": "Produzione di software non connesso all'edizione", "address": { "@type": "PostalAddress", "postalCode": "", "addressLocality": "Milano, Italy", "addressCountry": "IT", "addressRegion": "MI", "streetAddress": "Viale Sarca, 336/F" }, "keywords": "Vtenext Srl fatturato, utile Vtenext Srl, perdita Vtenext Srl, risultato Vtenext Srl , andamento Vtenext Srl, partita iva Vtenext Srl , bilancio Vtenext Srl , visura Vtenext Srl, 09869110966, Partita Iva 09869110966, Codice Fiscale 09869110966, DUNS Vtenext Srl, D-U-N-S Vtenext Srl, Report Aziende per fatturato" --- Title: VTENEXT S.R.L. SOCIETA' BENEFIT 03641400233 - Visurissima.it - Le informazioni a portata di click URL: https://www.visurissima.it/aziende/VTENEXT-SRL-SOCIETA-BENEFIT_03641400233.html Published: N/A Author: N/A Highlights: Indirizzo completo ... VIA ALZANA 2/C, 37040 ARCOLE (VR) ... crmvillage@pec.it ... Scopri Email Scopri --- [...] 3.A.3 Chiama agente Permette di eseguire una richiesta ad un agente precedentemente configurato in Impostazioni > Strumenti AI > Agenti. Una volta selezionato uno tra gli agenti disponibili verranno caricati tutti gli elementi configurati in Impostazioni > Strumenti AI > Agenti e potranno essere personalizzati. L'agente è in grado di svolgere task in modo automatico in base ai tool attivati e alla conoscenza a cui ha accesso tramite RAG e LLM. E' possibile modificare il System prompt mentre le istruzioni operative vanno indicate nel campo User message. Nei Campi restituiti è già configurato di default il contenuto della risposta per poter essere utilizzata nelle fasi successive del processo. Di seguito un esempio in cui si richiede all'agente di cercare la soluzione ad una richiesta pervenuta via ticket di Assistenza Clienti tramite il tool user_manual e di scriverla in un commento. Figura 1 Al prompt scritto dall'utente vengono aggiunte altre informazioni per indicare il contesto della richiesta come ad esempio quali sono le entità coinvolte nel processo con nome, modulo, crmid. Ecco perchè l'agente è in grado di capire a quale entità del crm si sta facendo riferimento. Eventualmente è possibile utilizzare le variabili di processo per rendere ancora più chiara la richiesta: es. aggiungi un commento al ticket $15-crmid proponendo una soluzione... 3.A.4 Chiama processo tool Permette di eseguire un processo tool. Una volta selezionato il tool desiderato verranno caricati i Parametri di input previsti che potranno essere configurati utilizzando come di consueto le variabili di processo. Questa azione non presenta i limiti dei sotto-processi e può essere richiamata più volte nello stesso processo e anche da più processi diversi. Di seguito un esempio di chiamata ad un tool per l'aggiunta di un commento ad un ticket. I parametri son quelli definiti nel processo tool che in questo caso sono l'id del ticket e il testo. 3.A.5 Esempi Di seguito alcune applicazioni di esempio su come questi nuovi strumenti possono essere integrati nei processi. Web scraping Questo è un processo che alla creazione di un'azienda esegue una chiamata ad un agente richiedendo di cercare online delle informazioni sull'azienda e valorizzandole nell'anagrafica. L'agente dovrà aver attivato un tool per la ricerca web (es. web_search_exa) e i tool del client MCP di VTENEXT per poter accedere alla struttura dei moduli e aggiornare il record.   Il processo parte alla creazione di un'azienda ed esegue l'azione Chiama agente. In User message chiedo di cercare online le informazioni e valorizzarle nell'azienda. Inoltre chiedo di creare un contatto per l'amministratore delegato. Se nell'azione di processo hai impostato la modalità di esecuzione Backgroud dopo il salvataggio il sistema notificherà che il record è ancora in aggiornamento e una volta terminato la pagina del browser si aggiornerà automaticamente. Dal tab Storico si avrà evidenza dei campi aggiornati: Assistenza clienti chiusa In questo caso implementiamo un processo che negli orari in cui gli uffici sono chiusi risponde automaticamente ai ticket di assistenza tecnica informando il cliente della chiusura e tentando di fornire una soluzione al problema. Tool add_comment Per prima cosa realizziamo un processo tool per aggiungere un commento ad un ticket che prevede in input i parametri id ticket e il commento. Nel secondo step del processo eseguiamo una chiamata LLM per rielaborare il testo del commento applicando un certo stile. In questo caso basta utilizzare solamente un LLM anziché un agente in quanto non è necessario utilizzare tool ma solamente sfruttare la capacità linguistica del modello. Infine utilizziamo la funzione SDK Add comment mappando tutti i campi richiesti. In questo caso indico nel parametro ownerid l'id dell'utente Kitt e con ai impostato a true forzo l'aggiunta di una nota informatica in calce al commento che indica che il testo è stato generato tramite AI. Il tool add_comment va quindi attivato nell'agente che utilizzeremo nei prossimi step, assieme al tool user_manual e/o eventuali documenti nella sezione RAG per la conoscenza necessaria a fornire una soluzione. Implementazione processo su ticket Possiamo quindi implementare un nuovo processo oppure integrare le nuove logiche AI in uno già esistente. In questo caso sfrutto un processo già esistente che alla creazione di un ticket imposta lo SLA in base alla priorità. Nella task AI:check orario eseguo una chiamata all'agente con il seguente prompt: L'azienda è aperta dal lunedì al venerdì dalle ore 09:00 alle 13:00 e dalle 14:00 alle 18:00 i soli giorni feriali. Se il ticket è stato creato in orario di apertura restituisci la stringa "open" altrimenti "closed". Restituisci esattamente quella stringa senza aggiungere altro testo o titoli. e predispongo la form dinamica con un campo popolato con la risposta: Configuro la condizione sul campo della form dinamica e il gateway successivo in modo che se l'agente ritorna closed il processo vada nella task AI: risp automatica. Nell'ultima task del processo eseguo prima la chiamata al tool add_comment per informare il cliente della chiusura ed infine la chiamata all'agente per proporre la soluzione. Il commento qui indicato sarà poi rielaborato dal modello LLM nel processo tool. prompt per agente: aggiungi un commento con il tool add_comment proponendo una soluzione al suo problema cercando in user_manual. Nel testo non usare mai titoli o codice markdown, restituisci solo testo semplice. Test Testiamo il processo creando un ticket in orario di chiusura con Titolo login fallito e Descrizione "buongiorno stamattina non riesco più a fare il login a vte, potete controllare urgentemente?" Verranno aggiunti dei commenti simili a questi: 4 Process Helper: Configurazione Campi di Testata 4.1 Assegnato A Rappresenta l’assegnatario del process helper, quindi nel nostro caso l’utente a cui verrà mostrata e richiesta la compilazione della form dinamica (Figura 1) Figura 1 In base al valore impostato nella picklist iniziale è possibile inserire diverse tipologie di assegnatari (statici o dinamici), ovvero: - Utente → permette di selezionare un utente statico esistente nel crm (vedi Figura 2) Figura 2 - Gruppo → permette di selezionare un gruppo statico esistente nel crm (Figura 3) Figura 3 - Altro → permette di selezione un utente o gruppo dinamico pescando dai moduli coinvolti nel processo (Figura 4) Figura 4 - Avanzate → Permette di definire un assegnatario differente (statico o dinamico) al verificarsi di determinate condizioni. Per procedere con la configurazione si deve cliccare il pulsante con I 3 puntini orrizzontali (Figura 5) Figura 5 Successivamente, cliccando su “Aggiungi regola” (Figura 6) e successivamente su “Nuovo gruppo” (Figura 7), si potranno indicare le varie condizioni sui campi dei moduli coinvolti nel processo. Figura 6 Dopo aver cliccato il pulsante “Salva” (Figura 8) si potrà indicare l’assegnatario che verrà selezionato al verificarsi della condizione inserita in precedenza (Figura 9). Una volta salvato, per inserire una nuova regola si dovrà cliccare nuovamente il pulsante “Aggiungi regola”, invece si dovrà cliccare su “Salva” per procedere con la configurazione del process helper. Figura 8 Figura 9 - Email → permette di definire un indirizzo (statico o dinamico) al quale verrà inviata una mail contenente un link ad una landing page dalla quale sarà possibile compilare la form dinamica (Figura 10) Figura 10 Una volta selezionata questa voce, all’interno del process helper compariranno dei campi aggiuntivi volti a recepire le informazioni minime necessarie per poter inviare la mail (Figura 11) Figura 11 Nello specifico: - Oggetto mail → permette di definire l’oggetto della mail da inviare all’assegnatario - Mittente mail → permette di definire il mittente della mail da inviare all’assegnatario NOTA BENE: dovrà essere indirizzo dell’account configurato in Impostazioni → Altre impostazioni → Server di Posta - Messaggio mail → permette di definire il corpo della mail da inviare all’assegnatario (al quale verrà aggiunto il link per accedere alla landing page e compilare la form dinamica) - Il link sarà valido fino a → permette di definire un tempo massimo di validità del link per accedere alla landing page e compilare la form dinamica -Richiedi conferma via mail → permette di inviare un ulteriore mail successiva alla compilazione della form dinamica al fine di mostrare il riepilogo dei dati inseriti e dare eventualmente la possibilità di modificarli (Figura 12) Figura 12 - Business Portal → permette di definire l’ID di un Contatto o Azienda che deve essere associato ad un utenza del Business Portal (Figura 13). Figura 13 4.2 Collegato A Rappresenta il record specifico al quale verrà agganciato il process helper e sul quale verrà mostrata la form dinamica (Figura 1). P.S: Essendo un campo di relazione, al suo interno si possono inserire solamente gli ID dei record coinvolti Figura 1 Dalla versione 26.04 il contenuto di tale campo viene compilato in automatico con il crmid dell'entità principale coinvolta nel processo. 4.3 Stato Rappresenta lo stato del processo, il valore “In corso” viene proposto in automatico (Figura 1). Figura 1 NOTA BENE: dal momento in cui si attiva un process helper all’interno di un processo, da quel momento in poi la gestione dello stato diventa “manuale”, quindi andrà gestita fino alla fine attraverso l’utilizzo di altri process helper. Nello specifico, all’interno di ogni singolo EndEvent configurato, sarà necessario attivare un process helper per forzare lo stato in “Terminato” al fine di chiudere correttamente il processo (Figura 2). In caso contrario, il processo terminerà comunque il proprio flusso ma lo “Stato” rimarrà “In corso” creando potenziali disagi agli utenti assegnatari. Figura 2 Figura 3 4.4 Nome Processo Rappresenta il Nome del processo (che di default sarà sempre quello definito nel campo “Nome” del processo). Inserendo un valore all’interno di questo campo sarà possibile modificare temporaneamente il nome del processo al fine di inserire un titolo più consono rispetto a quanto viene richiesto all’utente in questo specifico step del flusso, in modo da dare un’ulteriore indicazione all’assegnatario del process helper (Figura 1). Figura 1 4.5 Azione Richiesta Rappresenta un campo testuale libero che verrà mostrato all’utente assegnatario del process helper. Si potranno inserire delle indicazioni precise sulle attività che dovranno essere svolte dall’utente (Figura 1 e 2). Figura 1 Figura 2 4.6 Flag Mostra Nell'Entità Collegata Permette di generare una maschera di anteprima che sarà visualizzabile direttamente dal dettaglio del record collegato al process helper (Figura 1 e 2) Per procedere con la compilazione della form dinamica si dovrà cliccare sul pulsante “Compila”. Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) 4.7 Flag Autenticazione a 2 Fattori Permette di richiede l’accesso a 2 fattori per poter confermare e salvare I dati inseriti all’interno della form dinamica del process helper (Figura 1, 2 e 3). Per poter essere utilizzata, l’utente assegnatario del process helper deve avere attiva l’autenticazione a 2 fattori dalle proprie preferenze utente. Per approfondimenti sulla procedura di attivazione e le relative possibilità di utilizzo consultare il capitolo 2.7.2 del manuale generale di Vtenext. Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) Figura 3 (cliccare sull'immagine per una risoluzione grafica maggiore) 4.8 Flag Mostra Documenti Dell'Entità Collegata Permette di visualizzare tutti i record del modulo "Documenti" relazionati all'entità (istanza di un modulo) collegata al Process helper, quindi inserita nel campo "Collegato a". (Figura 1) Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) Questa funzionalità risulta essere maggiormente efficace nelle form dinamiche in cui è stato spuntato il flag "Mostra nell'entità collegata", in quanto, i documenti verranno mostrati in una sezione aggiuntiva all'interno del popup. (Figura 2) NOTA BENE: anche se all'interno della sezione aggiuntiva sono presenti gli spazi per eseguire dei filtri sulle varie colonne, nel concreto si tratta di una funzionalità attualmente non supportata, quindi per ricercare uno specifico documento si consiglia di scorrere manualmente le eventuali N pagine presenti. Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) Invece, nelle form dinamiche in cui NON è stato spuntato il flag "Mostra nell'entità collegata", per visualizzare i documenti si dovrà accedere al dettaglio del record del modulo Processi (Figura 3 e 4). In alternativa, si potranno guardare i documenti direttamente dal record collegato al process helper. Figura 3 (cliccare sull'immagine per una risoluzione grafica maggiore) Figura 4 (cliccare sull'immagine per una risoluzione grafica maggiore) 5 Process Helper: Configurazione Form Dinamica 5.1 Configura Scelta Rapida Questa funzionalità permette di generare dei pulsanti personalizzati che si differenziano dal pulsante base "Compila" e che hanno l'obiettivo di facilitare e velocizzare la gestione di procedure che prevedono un semplice input diretto da parte dell'utente, come spesso capita nei casi in cui serve ottenere una conferma per proseguire con il flusso o per direzionarlo su una specifica diramazione. (Figura 1) Figura 1 Al click del pulsante "Configura Scelta Rapida" il sistema mostrerà una tabella nella quale potranno essere configurati i pulsanti da prevedere. (Figura 2) Nello specifico: - colonna "Etichetta:" -> rappresenta il nome con il quale verrà mostrato il pulsante - colonna "Valore" ->  - colonna "Stile" -> rappresenta il colore con la quale verrà mostrato il pulsante - colonna "Conferma" -> permette di attivare una doppia conferma mostrando un'ulteriore popup che compare al click del pulsante Figura 2 Per visionare un esempio pratico consultare il capitolo 6.2 5.2 Gestione blocchi e campi Permette la creazione di vere e proprie form personalizzate volte a recepire e storicizzare I dati inseriti (in questo caso) da utenti crm o esterni (Figura 1). Figura 1 L’interfaccia di configurazione è identica alla sezione Layout Editor utilizzata per la configurazione dei moduli (capitolo 17.7 del manuale generale di Vtenext). PULSANTE “AGGIUNGI BLOCCO” Tramite il pulsante “Aggiungo blocco” sarà possibile creare un blocco, ovvero la “base” all’interno della quale potranno essere creati I singoli campi o tabelle (Figura 2). Figura 2 Una volta creato un blocco, a destra del nome del blocco verranno resi disponibili una serie di pulsanti volti alla creazione/spostamento/eliminazione dei singoli campi presenti al suo interno (Figura 3). Figura 3 Nello specifico: - Pulsante Modifica → permette di modificare il nome del blocco (Figura 4) Figura 4 - Pulsante Cestino → permette di eliminare il blocco (Figura 5) Figura 5 - Pulsante Aggiungi campo → permette di creare un campo di una tra le diverse tipologie disponibili (Figura 6), approfondimenti vedere sezione “Tipi di campi personalizzati” del capitolo 17.7 del manuale generale di Vtenext Figura 6 - Pulsante Aggiungi campo relazione → permette di creare rapidamente un campo di tipologia “Relazionato a” (Figura 7) Figura 7 -Pulsante Aggiungi campo tabella → permette di creare rapidamente un campo tabella (Figura 8 e 9) Figura 8 Figura 9 -Pulsante Sposta Campi → permette di spostare singoli campi da un blocco all’altro della stesa form dinamica (Figura 10) Figura 10 5.3 Gestione Proprietà dei singoli campi Per gestire le proprietà dei singoli campi presenti nella form dinamica si dovrà cliccare sul pulsante “Modifica” presente alla destra del nome del campo (Figura 1). Figura 1 Nello specifico, si potranno gestire le seguenti proprietà: - Permessi di Default → tramite la compilazione della picklist “Permessi” sarà possibile selezionare una delle seguenti voci: “Lettura / Scrittura”, “Sola Lettura”, “Nascosto” (Figura 2) Figura 2 Per impostare invece i permessi di obbligatorietà si dovrà selezionare il flag “Obbligatorio” (Figura 3) Figura 3 - Valore di Default → tramite la compilazione del campo “Valore di Default” sarà possibile indicare un valore di default statico o dinamico (pescando dalla “picklist Seleziona Opzione”) (Figura 4) Figura 4 - Modalità valori → si tratta di una funzionalità esclusiva per i campi di tipologia “Picklist”. Permette di scegliere se specificare dei valori statici come componenti della picklist (selezionando la voce “Specifica i valori”, Figura 5) oppure se ereditare i valori di una picklist esistente su uno dei moduli coinvolti all’interno del processo o presenti all’interno del crm (selezionando la voce “Eredita da un campo”, Figura 6). Figura 5 Figura 6 NOTA BENE: all’interno dei processi è possibile separare il processo in rami differenti che vengono percorsi dal flusso in base alle condizioni che si verificano al suo interno. Per questo, in fase di configurazione di questa funzionalità, è bene rivolgere una particolare attenzione sulle fonti dalle quali andiamo a ricavare i valori da ereditare. Infatti, nel caso in cui si ereditasse i valori di un campo pescandolo da un istanza coinvolta nel processo, si deve fare attenzione che quell’istanza sia effettivamente sempre coinvolta nell’intero percorso che poi porta al process helper, altrimenti si rischia che il sistema non restituisca nulla perché, in quel specifico ramo percorso dal processo, l’istanza di quel modulo non esiste. Se ad esempio il processo si suddivide in 2 rami differenti, in cui nel primo è presente un’azione di crea entità sul modulo aziende e nel secondo invece il process helper che stiamo configurando, se andremo a pescare i valori da ereditare puntando all’azienda creata dall’azione di crea entità non otterremo alcun valore, questo perché nel percorso che porta al process helper quell’azienda non viene creata. Quindi in questo caso dovremo puntare alle variabili legate ai moduli generici presenti nel crm (Figura 7) Figura 7 5.4 Importa Blocco da Form Dinamica Nel caso in cui i blocchi e campi necessari fossero già esistenti all’interno di un altra form dinamica , tramite il pulsante “Importa da form dinamica...” sarà possibile inserire all’interno della form dinamica una copia del blocco di un form dinamica presente all’interno del processo (comprensivo dei campi presenti al suo interno, Figura 1). Figura 1 NOTA BENE: tutti i campi verranno creati con le seguenti proprietà: -Permessi di default → Sola lettura -Valore di default → variabile che punta al contenuto del campo della form dinamica da cui è stata eseguita la copia 5.5 Importa Blocco da Modulo Nel caso in cui i blocchi e campi necessari fossero già esistenti all’interno di un modulo (standard o custom), tramite il pulsante “Importa da modulo...” sarà possibile inserire all’interno della form dinamica una copia del blocco di un modulo coinvolto nel processo (comprensivo dei campi presenti al suo interno, Figura 1). Figura 1 NOTA BENE: tutti i campi verranno creati con le seguenti proprietà: -Permessi di default → Sola lettura -Valore di default → variabile che punta al contenuto del campo dell’istanza del modulo da cui è stata eseguita la copia 5.6 Sezione Avanzate Tramite questa sezione è possibile impostare delle regole avanzate per gestire i permessi dei campi dei moduli/ form dinamiche coinvolte all’interno del processo. Per accedervi si deve cliccare il pulsante “Avanzate” disponibile all’interno di una qualsiasi Action Task (Figura 1) Figura 1 CAMPI CONDIZIONALI (SU MODULO) Permette di impostare delle regole di campi condizionali applicabili alle istanze dei modulo coinvolti nel processo (Figura 2). Queste regole saranno valide solamente durante la durata del processo, infatti una volta terminato verranno disattivate in automatico. Figura 2 Per procedere con la creazione di una regola si dovrà cliccare il pulsante “Nuova Regola”. Il sistema chiederà l’inserimento di una descrizione testuale tramite la compilazione del campo “Regola”. Successivamente si dovrà selezionare l’istanza coinvolta nel processo, indicare eventuali Ruoli o Gruppi a cui limitare l’applicazione della regola, inserire una condizione (che dovrà verificarsi perché la regola si attivi) ed infine inserire i permessi sui campi interessati (Figura 3). Per approfondimenti sulla configurazione dei campi condizionali consultare la sezione 17.4 del manuale generale di Vtenext. Figura 3 NOTA BENE: rispetto ai campi condizionali standard, da processo è disponibile una colonna aggiuntiva denominata “Valore” che permette di forzare l’inserimento di dati statici o dinamici all’interno dei campi selezionati (Figura 4). Figura 4 CAMPI CONDIZIONALI SU FORM DINAMICA (NON SUPPORTATI NELLA MODALITA' PORTALE) Permette di impostare delle regole di campi condizionali applicabili ai campi di una specifica form dinamica presente all’interno del processo (Figura 5). Queste regole saranno valide solamente durante la durata del processo, infatti una volta terminato verranno disattivate in automatico. Figura 5 Per procedere con la creazione di una regola si dovrà cliccare il pulsante “Nuova Regola”. Il sistema chiederà l’inserimento di una descrizione testuale tramite la compilazione del campo “Regola”. Successivamente si dovrà indicare eventuali Ruoli o Gruppi a cui limitare l’applicazione della regola, inserire una condizione (che dovrà verificarsi perché la regola si attivi) ed infine inserire i permessi sui campi interessati. Per approfondimenti sulla configurazione dei campi condizionali consultare la sezione 17.4 del manuale generale di Vtenext. Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di un Process Helper volto a richiede l’approvazione di un flusso interno tramite la compilazione di un singolo campo denominato “Azione” (Figura 6). Figura 6 Si tratta di un campo di tipo picklist avente i seguenti 3 valori statici: “vuoto”, “APPROVARE” e “NON APPROVARE” e con permessi di obbligatorietà come Default (Figura 7) Figura 7 E’ presente un campo aggiuntivo denominato “Motivo mancata approvazione” che dovrebbe essere mostrato e compilato solamente nel caso in cui l’utente scelga l’opzione “NON APPROVARE”. Per questo è stata creata la seguente regola di campi condizionali su form dinamica che permette di nascondere il suddetto campo nel caso in cui il campo “Azione” abbia un valore diverso da “NON APPROVARE”. Quindi nella sezione “Avanzate”→ “Campi condizionali su form dinamica” è stata inserita una regola denominata “Se Azione diverso da NON APPROVARE nascondi campo Motivo mancata approvazione” (Figura 8). Figura 8 Nella sezione “Condizione” è stata inserita la condizione “Azione” diverso “NON APPROVARE” (Figura 9) Figura 9 Nella sezione “Campi da gestire” è stata selezionata solamente la colonna “Gestito” sul campo “Motivo mancata approvazione ” (Figura 10) Figura 10 PERMESSI AVANZATI Permette di impostare dei permessi di visibilità completi sulle istanze dei moduli coinvolti all’interno del processo potendo specificare un utente o un gruppo (statico o dinamico). N.B: Essi saranno validi anche dopo il termine del processo. Per procedere con l’inserimento di un permesso avanzato si dovrà selezionare un’istanza coinvolta all’interno del processo, un utente o gruppo (statico o dinamico) a cui applicarlo ed infine uno tra i permessi disponibili (“Lettura/scritta” e “Sola lettura”) (Figura 11). Una volta cliccato il pulsante “Aggiungi regola” il permesso avanzato verrà salvato e confermato. Figura 11 6 Process Helper: Esempi di Utilizzo 6.1 Esempio di utilizzo Process Helper per richiesta dati utenti interni - versione standard Come anticipato nel capitolo introduttivo, uno degli utilizzi più comuni del process helper riguarda la creazione di maschere personalizzate presentabili agli utenti interni del crm al fine di richiede e salvare informazioni. I blocchi e campi da cui sono composte queste maschere prendono il nome di “form dinamiche”. PREMESSA: per fare in modo che un utente possa visualizzare e compilare una form dinamica, dovrà aver abilitato i dovuti permessi lato profilo (Figura 1) Figura 1 Per poter configurare un process helper, si deve inanzitutto configurare una Action Task (crea collegamento con sezione dedicata) seguendo la procedura dedicata (Figura 2). P.S: è consigliabile utilizzare il simbolo della User Task, in quanto, stiamo indicando un’attività che andrà in carico all’utente. Figura 2 Successivamente alla User Task, in questo caso specifico è fondamentale creare una Task all’interno della quale eseguire dei controlli per permettere al processo di fermarsi e presentare la form dinamica (Figura 3). Figura 3 Una volta entrati all’interno della User Task (nel nostro esempio “Process Helper”) in modalità di configurazione, troveremo la sezione denominata “Process Helper” con tutti I campi relativi (Figura 4) Figura 4 Una volta configurati I campi principali (Assegnato a, Collegato a, Azione richiesta) andremo a creare nella form dinamica I blocchi e campi necessari al fine di salvare le informazioni che andranno inserite dall’utente (per approfondimenti sulla loro configurazione consultare il capitolo 5). Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di process helper volto a richiede l’approvazione di un flusso interno tramite la compilazione di un singolo campo denominato “Azione” (Figura 5). Figura 5 Si tratta di un campo di tipo picklist avente i seguenti 3 valori statici: “vuoto”, “APPROVARE” e “NON APPROVARE” e con permessi di obbligatorietà come Default (Figura 6) Figura 6 Nella Task di controllo associata (denominata “Controllo process Helper”) viene indicata una condizione che permette al processo non di non proseguire con il proprio flusso fino a quando non sarà stato inserito un valore diverso da vuoto (che rappresenta invece il valore di default della picklist) (Figura 7) Figura 7 Le due condizioni inserite in gruppi separati permettono di instradare il flusso in due percorsi diversi in base alla voce selezionata dall’utente. Lato operativo, il process helper si presenta con una maschera di anteprima come mostrato nella Figura 8, questo perché è stato attivato il flag “Mostra nell’entità collegata”. Figura 8 In alternativa, sarà sempre e comunque visibile e compilabile nella sezione raggiungibile tramite il pulsante dedicato presente nel menù in alto a destra (Figura 9 e 10) Figura 9 Figura 10 Dalla versione 26.04 è stata modificata l'interfaccia di visualizzazione dell'anteprima per poter gestire correttamente più form dinamiche attive contemporaneamente sullo stesso record. Di default vengono mostrare nella modalità Slider". (Figura 11) Figura 11 Premendo il pulsante dedicato potranno essere visualizzate nella modalità "a scorrimento". (Figura 12) Figura 12 Anche la sezione raggiungibile tramite il pulsante dedicato presente nel menù in alto a destra è stata modificata rendendola graficamente più suggestiva e completa. (Figura 13) Figura 13 Cliccando sul pulsante "Tutti" il sistema reindirizzerà l'utente alla vecchia schermata dei processi, la quale è stata comunque migliorata sia a livello grafico che funzionale. Infatti, sono stati aggiunti in lista i seguenti pulsanti: - pulsante di anteprima: permette di visualizzare a metà scheda il contenuto della form dinamica e di procedere con l'eventuale compilazione (Figura 14) - pulsante di compilazione diretta: che permette di aprire direttamente la form dinamica sotto forma di popup. (Figura 15) Figura 14 Figura 15 Al click del pulsante Compila viene mostrato un popup con il contenuto della form dinamica. L’utente dovrà semplicemente compilare il campo “Azione” e infine cliccare sul pulsante “Salva” (Figura 16) Figura 16 6.2 Esempio di utilizzo Process Helper per richiesta dati utenti interni - versione pulsanti rapidi Dalla versione 26.04 è stata introdotta una modalità aggiuntiva di creazione di maschere personalizzate presentabili agli utenti interni del crm al fine di richiede e salvare informazioni. PREMESSA: per fare in modo che un utente possa visualizzare e compilare una form dinamica, dovrà aver abilitato i dovuti permessi lato profilo (Figura 1) Figura 1 Le condizioni di configurazione rimangono le stesse indicate nel capitolo 6.1, quindi per poter configurare un process helper, si deve inanzitutto configurare una Action Task (crea collegamento con sezione dedicata) seguendo la procedura dedicata (Figura 2). P.S: è consigliabile utilizzare il simbolo della User Task, in quanto, stiamo indicando un’attività che andrà in carico all’utente. Figura 2 Successivamente alla User Task, in questo caso specifico è fondamentale creare una Task all’interno della quale eseguire dei controlli per permettere al processo di fermarsi e presentare la form dinamica (Figura 3). Figura 3 Una volta entrati all’interno della User Task (nel nostro esempio “Process Helper”) in modalità di configurazione, troveremo la sezione denominata “Process Helper” con tutti i campi relativi (Figura 4) Figura 4 Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di process helper volto a richiede l’approvazione di un flusso interno tramite la compilazione di due pulsanti di scelta rapida "Approvare" e "Non Approvare". Quindi, una volta configurati i campi principali (Assegnato a, Collegato a, Azione richiesta) andiamo a creare nella form dinamica i due pulsanti previsti compilando la tabella disponibile cliccando il pulsante "Configura scelta rapida". Oltre ad inserire l'etichetta, il valore e lo stile andiamo a selezionare il flag "Conferma" per fare in modo che il sistema mostri un'ulteriore popup di conferma al click del pulsante. (Figura 5). Figura 5 Nella Task di controllo associata (denominata “Controllo process Helper”) viene indicata una condizione che permette al processo non di non proseguire con il proprio flusso fino a quando non sarà stato uno dei due pulsanti previsti. (Figura 7) Figura 7 Le due condizioni inserite in gruppi separati permettono di instradare il flusso in due percorsi diversi in base alla voce selezionata dall’utente. Lato operativo, il process helper si presenta con una maschera di anteprima come mostrato nella Figura 8, questo perché è stato attivato il flag “Mostra nell’entità collegata”. Figura 8 In alternativa, sarà sempre e comunque visibile e compilabile nella sezione raggiungibile tramite il pulsante dedicato presente nel menù in alto a destra (Figura 9 e 10) Figura 9 Figura 10 6.3 Esempio di utilizzo Process Helper per richiesta dati utenti esterni Come anticipato nel capitolo introduttivo, uno degli utilizzi più comuni del process helper riguarda la creazione di maschere personalizzate presentabili agli utenti esterni al fine di richiede e salvare informazioni. I blocchi e campi da cui sono composte queste maschere prendono il nome di “form dinamiche”. Per poter configurare un process helper, si deve innanzitutto configurare una Action Task (crea collegamento con sezione dedicata) seguendo la procedura dedicata (Figura 1). P.S: è consigliabile utilizzare il simbolo della User Task, in quanto, stiamo indicando un’attività che andrà in carico all’utente. Figura 1 Successivamente alla User Task, in questo caso specifico è fondamentale creare una Task all’interno della quale eseguire dei controlli per permettere al processo di fermarsi e presentare la form dinamica (Figura 2). Figura 2 Una volta entrati all’interno della User Task (nel nostro esempio “Process Helper”) in modalità di configurazione, troveremo la sezione denominata “Process Helper” con tutti i campi relativi (vedi Figura 3) Figura 3 Una volta configurati i campi principali (Assegnato a, Collegato a, Azione richiesta) andremo a creare nella form dinamica i blocchi e campi necessari al fine di salvare le informazioni che andranno inserite dall’utente. Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di process helper volto a richiede l’approvazione del step di un flusso tramite la compilazione di un singolo campo denominato “Azione” (Figura 4). Figura 4 Si tratta di un campo di tipo picklist avente i seguenti 3 valori statici: “vuoto”, “APPROVARE” e “NON APPROVARE” e con permessi di obbligatorietà come Default (Figura 5) Figura 5 Nella Task di controllo associata (denominata “Controllo process Helper”) viene indicata una condizione che permette al processo non di non proseguire con il proprio flusso fino a quando non sarà stato inserito un valore diverso da vuoto (che rappresenta invece il valore di default della picklist) (Figura 6) Figura 6 Le due condizioni inserite in gruppi separati permettono di instradare il flusso in due percorsi diversi in base alla voce selezionata dall’utente. Lato operativo, viene inviata una mail all’indirizzo inserito nel campo “Assegnato a” che presenta un pulsante denominato “CLICCA QUI” (Figura 7) Figura 7 Al click del pulsante viene aperta una landing page con il contenuto della form dinamica. L’utente dovrà semplicemente compilare il campo “Azione” e infine cliccare sul pulsante “INVIA” (Figura 8) Figura 8 Una volta salvato verrà presentato nella landing page un messaggio di avviso che l’operazione è stata eseguita correttamente (Figura 9) Figura 9 6.4 Esempio di utilizzo Process Helper per richiesta dati utenti Business Portal Come anticipato nel capitolo introduttivo, uno degli utilizzi più comuni del process helper riguarda la creazione di maschere personalizzate presentabili agli utenti Business Portal al fine di richiede e salvare informazioni. Per i dettagli sulle condizioni e i requisiti per poter attivare la gestione dei processi lato Customer Portal, si consiglia di consultare il capitolo 18.3 del manuale generale di Vtenext. I blocchi e campi da cui sono composte queste maschere prendono il nome di “form dinamiche”. Per poter configurare un process helper, si deve innanzitutto configurare una Action Task (crea collegamento con sezione dedicata) seguendo la procedura dedicata (Figura 1). P.S: è consigliabile utilizzare il simbolo della User Task, in quanto, stiamo indicando un’attività che andrà in carico all’utente. Figura 1 Successivamente alla User Task, in questo caso specifico è fondamentale creare una Task all’interno della quale eseguire dei controlli per permettere al processo di fermarsi e presentare la form dinamica (Figura 2). Figura 2 Una volta entrati all’interno della User Task (nel nostro esempio “Process Helper”) in modalità di configurazione, troveremo la sezione denominata “Process Helper” con tutti i campi relativi (vedi Figura 3) Figura 3 Una volta configurati i campi principali (Assegnato a, Collegato a, Azione richiesta) andremo a creare nella form dinamica i blocchi e campi necessari al fine di salvare le informazioni che andranno inserite dall’utente. Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di process helper volto a richiede l’approvazione del step di un flusso tramite la compilazione di un singolo campo denominato “Azione” (Figura 4). Figura 4 Si tratta di un campo di tipo picklist avente i seguenti 3 valori statici: “vuoto”, “APPROVARE” e “NON APPROVARE” e con permessi di obbligatorietà come Default (Figura 5) Figura 5 Nella Task di controllo associata (denominata “Controllo process Helper”) viene indicata una condizione che permette al processo non di non proseguire con il proprio flusso fino a quando non sarà stato inserito un valore diverso da vuoto (che rappresenta invece il valore di default della picklist) (Figura 6) Figura 6 Le due condizioni inserite in gruppi separati permettono di instradare il flusso in due percorsi diversi in base alla voce selezionata dall’utente. Lato operativo, viene inviata una mail all’indirizzo inserito nel campo “Email” del Contatto o Azienda inserite nel campo “Assegnato a” del Process helper che presenta un pulsante denominato “CLICCA QUI” (Figura 7) Figura 7 Al click del pulsante viene aperto il Business portal e mostrata l’interfaccia di compilazione del processo della sezione “Azioni richieste” (Figura 8) Figura 8 L’utente dovrà semplicemente cliccare sul pulsante “Compila” (Figura 9), compilare il campo “Azione” e infine cliccare sul pulsante “Salva” (Figura 10) Figura 9 Figura 10 6.5 Esempio di utilizzo Process Helper per attivazione Grafico Processo La configurazione di un process helper all’interno di un processo permette di attivare la sezione denominata “Grafico processo” disponibile nel tab “GRAFICO PROCESSO” del dettaglio di ogni singolo record (Figura 1) Figura 1 Da questa schermata è possibile visionare il percorso eseguito dall’inizio alla fine e gli utenti (denominati “Partecipanti”) coinvolti nelle varie Task/Action Task del processo (Figura 2). Figura 2 Inoltre, dalla versione 24.08, le singole Task/Action Task del processo che sono già state eseguite vengono evidenziate di giallo (Figura 3) Figura 3 Invece il punto in cui si trova il processo in quel specifico momento viene evidenziato in blu (Figura 4) Figura 4 Cliccando su ogni singola Task/Action Task è possibile visionare i log specifici relativi a chi ha eseguito la specifica task e relativo arco temporale (Figura 5) Figura 5 Dalla versione 24.08, nel caso in cui in un Process helper venga configurata una Form dinamica, cliccando sulla Action Task relativa e successivamente su “Dettagli” sarà possibile visionarne il contenuto (Figura 6) Figura 6 Dalla versione 26.07 è stata migliorata l'interfaccia di visualizzazione dei log attraverso l'apertura di un pannello dedicato sulla destra. (Figura 7) Figura 7 Con un utenza avente permessi di Amministratore è possibile eseguire della manutenzione diretta su una singola istanza di processo potendo spostare il punto di esecuzione del flusso in avanti (per evitare l’esecuzione di alcune Task/Action Task) o indietro (per rieseguire alcune Task/Action Task). Per procedere con tali operazioni si deve cliccare su “Forza posizione”(Figura 8), poi sulla Task/Action Task sul quale si vuole posizionare il processo (Figura 9), successivamente su “OK” nel popup di conferma (Figura 10), poi su “Continua esecuzione” (Figura 11) ed infine su “OK” nel popup di conferma (Figura 12). Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Nelle Task/Action Task rieseguite viene riportato se l’esecuzione è stata effettuata o meno tramite un forzamento di posizione (Figura 13) Figura 13 E’ consigliato configurare il suddetto Process helper all’interno di una Action Task inserita subito dopo la Task di condizione iniziale per fare in modo che il grafico venga attivato qualche instante dopo la partenza effettiva del processo (Figura 14). Figura 14 Per attivare il Process helper sarà sufficiente compilare i campi obbligatori, ovvero il campo “Assegnato a” e “Collegato a” (Figura 15). Figura 14 NOTA BENE: per evitare di riscontrare errori si consiglia di inserire nel Collegato a l’ID dell’istanza del modulo principale coinvolto nel processo, ovvero il record sul quale il processo si è scatenato, altrimenti si rischia di inserire l’ID di un istanza che non esiste in quel specifico punto del flusso. 6.6 Esempio di utilizzo Process Helper per uso interno al processo Come anticipato nel capitolo introduttivo, uno degli utilizzi del process helper riguarda la creazione di spazi virtuali nel quale immagazzinare dati o svolgere operazioni necessarie esclusivamente all’interno del processo (e che quindi sarebbe inutile storicizzare nei moduli del crm). Per procedere con la configurazione del process helper, si deve innanzitutto configurare una Action Task (crea collegamento con sezione dedicata) seguendo la procedura dedicata (Figura 1). Figura 1 NOTA BENE: NON è obbligatorio creare una Task successiva, in quanto, i controlli che verrebbero eseguiti al suo interno non sarebbero finalizzati a fermare il processo per presentare la form dinamica ma bensì a eseguire un semplice controllo sui dati presenti nei campi della form dinamica (che ricordiamo non sono stati inseriti direttamente da alcun utente). Una volta entrati all’interno della Action Task (nel nostro esempio “Form dinamica di appoggio”) in modalità di configurazione, troveremo la sezione denominata “Process Helper” con tutti I campi relativi (Figura 3) Figura 3 Una volta configurati I campi principali (Assegnato a, Collegato a, Azione richiesta) andremo a creare nella form dinamica I blocchi e campi necessari in base ai dati che vogliamo utilizzare o ai calcoli che vogliamo eseguire. Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di process helper volto a calcolare la differenza in giorni tra due date e storicizzarne il risultato in un campo denominato “Risultato calcolo”, questo per verificare se i due valori presi in esame sono uguali o diversi (e di conseguenza eseguire delle azioni differenti) (Figura 4). Figura 4 Si tratta di un campo di tipologia “Numero” all’interno del quale viene inserita come valore di Default la funzione SDK “Diff Date” che permette di eseguire la differenza tra due date. NOTA BENE: di Default il sistema restituisce il risultato in secondi, invece nel caso in si voglia ottenere il risultato in giorni si deve passare come terzo parametro la parola “days” come fatto in questo esempio (Figura 5) Figura 5 Nella Task di controllo associata (denominata “Controllo Form dinamica di appoggio”) vengono indicati due gruppi di condizioni differenti che permettono al processo di intraprendere delle strade differenti in base al risultato del calcolo (Figura 6). Nello specifico, viene controllato se il contenuto del campo “Risultato calcolo” è uguale o diverso da 0, questo perché se i due valori confrontati sono uguali la differenza calcolata sarà pari a 0, in caso contrario invece sarà diversa da 0. Figura 6 7 Configurazione di un Processo Base 7.1 Configurazione di un Processo Base - Approvazione Preventivo DESCRIZIONE DEL FLUSSO Alla creazione di un preventivo con Stadio Preventivo = “Creato”, il processo si scatenerà e presenterà ai componenti del gruppo “Direzione” un process helper in modalità popup richiedendone la compilazione. In caso di conferma verrà inviata una notifica interna di avviso all’assegnatario del preventivo (che corrisponde al commerciale che sta gestendo il preventivo). Invece in caso di rifiuto verrà inviata una mail di avviso sempre all’assegnatario del preventivo (che corrisponde al commerciale che sta gestendo il preventivo) contenente eventuali note/commenti interni utili alla revisione dello stesso. Se entro due giorni il popup non verrà compilato da nessun utente, il sistema invierà una mail di sollecito ai componenti del gruppo. Nel caso in cui si verificasse un errore SMTP nell’invio della mail di mancata approvazione, il sistema avviserà i componenti del gruppo “Reparto IT” tramite l’invio di una notifica interna. ELEMENTI NECESSARI NEL PROCESSO Per fare questo processo ci serviranno gli elementi elencati qui di seguito: -Condition Task -Action Task -Timer Boundary Event -Gateway -End Event Se il loro funzionamento non è chiaro consigliamo prima di consultare il capitolo 2 del manuale dei processi. CONFIGURAZIONE DIAGRAMMA DI FLUSSO Utilizziamo gli elementi citati in precedenza per impostare un diagramma come quello mostrato nella Figura 1 Figura 1 CONFIGURAZIONE DEI SINGOLI ELEMENTI DEL FLUSSO Procediamo con la configurazione dei singoli elementi che compongono il flusso del processo. Partiamo dalla Condition Task "Creazione preventivo". Nella sezione "Quando eseguire il controllo" selezioniamo l'opzione "Alla creazione” per far partire il processo solamente alla creazione del preventivo con Stadio Preventivo = “Creato” (Figura 2). Figura 2 Nella UserTask “PH richiesta approvazione” configuriamo un process helper al fine di richiedere all’utente le informazioni necessarie all’approvazione del preventivo. Configurazione blocco “Process Helper”: -nel campo “Assegnato a” inseriamo staticamente il gruppo “Direzione” -nel campo “Collegato a” inseriamo l’id del preventivo -nel campo “Nome Processo” indichiamo il nome che verrà attribuito al processo in questo specifico step, quindi inseriamo la parte statica “PH richiesta approvazione” seguita dal valore della variabile “Numero Preventivo” -nel campo “Azione richiesta” inseriamo una breve descrizione dell’attività da svolgere -spuntiamo il campo checkbox “Mostra nell’entità collegata” per far attivare la modalità popup del process helper Il risultato sarà quello mostrato in Figura 3. Figura 3 Configurazione form dinamica: Nella form dinamica creiamo un solo Blocco chiamato “Informazioni Preventivo” (vedi Figura 4) con i seguenti campi: 1 ”Azione” (campo picklist) con i seguenti valori: “vuoto”, “APPROVARE” e “NON APPROVARE” (vedi Figura 5) 2 “Note interne” (campo area di testo) Figura 4 Figura 5 Configurazione azione Resetta Form Dinamica Andiamo a creare un’azione di “Resetta Form Dinamica” per fare in modo che vengano resettati i valori dei campi presenti nella form nel caso in cui venga forzata la ri-compilazione del process helper (vedi Figura 6). Figura 6 Nella Condition Task “Controllo PH richiesta approvazione” andiamo ad eseguire un controllo sul campo “Azione” della form del process helper per indirizzare il processo nel ramo relativo al valore inserito dall’utente (vedi Figura 7) Figura 7 Nel bordo in basso a destra della task andiamo a posizionare un Timer Boundary Event (Figura 8) e procediamo con la sua configurazione inserendo 2 giorni di intervallo temporale (Figura 9) Per approfondimenti consultare il capitolo 2.3 del manuale dei processi. Figura 8 Figura 9 Al Timer Boundary Event andiamo a collegare la SendTask “Invio notifica di sollecito alla Direzione” in modo da inviare una notifica interna ai componenti del gruppo “Direzione” nel caso in cui il processo rimanga fermo sulla Condition Task “Controllo PH richiesta approvazione” per più di 2 giorni (Figura 10) Per approfondimenti consultare la sezione 3.4 del manuale dei processi. Figura 10 Nel gateway successivo andiamo ad associare ad ogni gruppo di condizioni (inserite nella Condition Task “Controllo PH richiesta approvazione”) il ramo corrispettivo da percorrere (vedi Figura 11) Figura 11 Configurazione degli elementi successivi al ramo “APPROVARE” Nella SendTask “Invio notifica interna ad assegnatario preventivo” configuriamo l’invio di una notifica interna all’assegnatario del preventivo (che corrisponde al commerciale che sta gestendo il preventivo) per avvisarlo dell’avvenuta approvazione del preventivo (Figura 12). Per approfondimenti consultare la sezione 3.4 del manuale dei processi. Figura 12 Anche l’endEvent deve essere configurato, in quanto, abbiamo coinvolto un process helper nel processo, quindi si rende necessario andare ad attivare un process helper al suo interno per impostare lo stato del processo in “Terminato” (vedi Figura 13) Figura 13 Configurazione degli elementi successivi al ramo “NON APPROVARE” Nella SendTask “Invio mail ad assegnatario preventivo” configuriamo l’invio di una mail all’assegnatario del preventivo (che corrisponde al commerciale che sta gestendo il preventivo) per avvisarlo della mancata approvazione del preventivo (Figura 14). Per approfondimenti consultare la sezione 3.5 del manuale dei processi. Figura 14 Nella ScriptTask “PH di appoggio per raccolta esito invio mail” andiamo ad attivare un process helper, al fine di sfruttarne la form dinamica per storicizzare il risultato dell’invio della mail (Figura 15). Nello specifico, per ogni azione di “Invio mail” configurata all’interno del processo, il sistema mette a disposizione le seguenti due variabili (Figura 16 e 17): - ”Esito positivo?” → viene restituito 1 nel caso in cui NON sia presente alcun tipo di errore SMTP, in caso contrario viene restituito 0 -”Messaggio di errore” → viene restituita la descrizione dell’errore SMTP riscontrato Figura 15 Figura 16 Figura 17 Nella Condition Task “Controllo risultato invio mail” andiamo ad eseguire un controllo sul campo “Esito positivo?” della form del process helper per indirizzare il processo nel ramo relativo all’esito dell’invio mail (vedi Figura 18) Figura 18 Nel gateway successivo andiamo ad associare ad ogni gruppo di condizioni (inserite nella Condition Task “Controllo risultato invio mail”) il ramo corrispettivo da percorrere (vedi Figura 19) Figura 19 Configurazione degli elementi successivi al ramo “Ok” Anche l’endEvent deve essere configurato, in quanto, abbiamo coinvolto un process helper nel processo, quindi si rende necessario andare ad attivare un process helper al suo interno per impostare lo stato del processo in “Terminato” (vedi Figura 20) Figura 20 Configurazione degli elementi successivi al ramo “Ko” Nella SendTask “Invio notifica interna a reparto IT” configuriamo l’invio di una notifica interna al gruppo “Reparto IT” per segnalare l’anomalia riscontrata sull’invio della mail (Figura 21) Per approfondimenti consultare la sezione 3.4 del manuale dei processi. Figura 21 Anche l’endEvent deve essere configurato, in quanto, abbiamo coinvolto un process helper nel processo, quindi si rende necessario andare ad attivare un process helper al suo interno per impostare lo stato del processo in “Terminato” (vedi Figura 22) Figura 22 7.2 Attivazione di un Processo Base - Approvazione Preventivo Ora procediamo con la visione del processo in azione. Creiamo quindi un nuovo preventivo inserendo le informazioni richieste (Figura 1) Figura 1 Dopo il salvataggio, il processo si scatenerà presentando una maschera di anteprima ad ogni componente del gruppo “Direzione”(Figura 2). Figura 2 La task descritta sopra però sarà visibile solamente entrando sull’anagrafica del preventivo, per questo è possibile in questo caso compilare il process helper attraverso la sezione “Processi” raggiungibile dal menù in alto a destra. (vedi Figura 3) Figura 3 Infatti in essa sono riportati tutti i processi pendenti assegnati direttamente all’utente o ad eventuali gruppi di cui fa parte, quindi basterà cercare la riga avente le seguenti informazioni (vedi Figura 4): -nome processo: “PH richiesta approvazione QUO94” -collegato a: “Nuovo pacchetto ore per Alpha Beta” (ovvero il Soggetto del preventivo) Figura 4 Dopodiché sarà sufficiente cliccare sulla matita alla sinistra del nome processo per poter compilare il process helper (che sarà visualizzato come se fossimo in modifica di un modulo). Una volta arrivati sulla form del process helper, l’utente si ritroverà davanti alla schermata mostrata in Figura 5. Figura 5 Volendo simulare l’approvazione di un preventivo, clicchiamo sul valore “APPROVARE” e procediamo con il salvataggio del process helper. Il sistema invierà in automatico una notifica interna all’assegnatario del preventivo (Figura 6). Figura 6 Volendo invece simulare una mancata approvazione del preventivo, clicchiamo sul valore “NON APPROVARE”  e procediamo con il salvataggio del process helper. Il sistema invierà una mail all’assegnatario del preventivo (Figura 7). Figura 7 Nel caso in cui si verificasse un errore SMTP nell’invio della mail di mancata approvazione, il sistema avviserà i componenti del gruppo “Reparto IT” tramite l’invio di una notifica interna (Figura 8). Figura 8 8 Configurazione di un Processo Avanzato 8.1 Configurazione di un Processo Avanzato - Gestione Rinnovi Installazioni DESCRIZIONE DEL FLUSSO Alla creazione di una nuova installazione il processo si scatenerà ed attenderà fino al raggiungimento della “Data scadenza prossimo rinnovo”. Una volta verificata la condizione temporale stabilita il processo presenterà un process helper in modalità popup e ne richiederà la compilazione all'assegnatario dell'installazione. In caso di conferma del rinnovo verrà creato un nuovo rinnovo, verrà aggiornata la “Data scadenza prossimo rinnovo” dell’installazione ed infine si tornerà sul timer ad attendere fino al raggiungimento della “Data scadenza prossimo rinnovo” appena inserita. In caso contrario invece il processo terminerà dopo aver aggiornato l’installazione con il motivo rifiuto rinnovo inserito dall’utente. MODULO RINNOVI: Al fine di storicizzare al meglio tuti i rinnovi eseguiti creiamo un modulo “Rinnovi” con relazione N a 1 con il modulo “Installazioni” e composto dai campi mostrati nella Figura 1  Figura 1 REQUISITI SUL MODULO INSTALLAZIONI: Sul modulo “Installazioni” creiamo i seguenti campi: -”Data scadenza prossimo rinnovo” (campo data) -”Motivo rifiuto rinnovo” (campo area di testo) ELEMENTI NECESSARI NEL PROCESSO Per fare questo processo ci serviranno gli elementi elencati qui di seguito: -Condition Task -Action Task -Timer Intermediate Catch Event -Gateway -End Event Se il loro funzionamento non è chiaro consigliamo prima di consultare il capitolo 2 del manuale dei processi. CONFIGURAZIONE DIAGRAMMA DEL FLUSSO Utilizziamo gli elementi citati in precedenza per impostare un diagramma come quello mostrato nella Figura 2 Figura 2 CONFIGURAZIONE DEI SINGOLI ELEMENTI DEL FLUSSO Procediamo con la configurazione dei singoli elementi che compongono il flusso del processo. Partiamo dalla Condition Task "Creazione nuova installazione". Nella sezione "Quando eseguire il controllo" selezioniamo l'opzione "Alla creazione” per far partire il processo solamente alla creazione dell’installazione. Figura 3 Nella ScriptTask “Grafico processo” configuriamo un process helper che sfrutteremo per poter visualizzare il grafico del processo nella tab “Grafico processo” dell’entità collegata (vedi Figura 4). Figura 4 Nel Timer intermediate catch event impostiamo la seguente configurazione: Attendi 0 “Prima” “Altro” → variabile “Data prossimo rinnovo dell’installazione” (vedi Figura 5). Figura 5 Nella ScriptTask "Aggiorna stato installazione in fuori servizio” configuriamo un’azione di aggiorna entità per impostare lo stato dell’installazione in “Fuori servizio” (vedi Figura 6) Figura 6 Nella UserTask “PH gestione rinnovi” configuriamo un process helper al fine di richiedere all’utente le informazioni necessarie alla gestione del rinnovo. Configurazione blocco “Process Helper”: -nel campo “Assegnato a” inseriamo l’assegnatario dell’installazione -nel campo “Collegato a” inseriamo l’id dell’installazione -nel campo “Nome Processo” indichiamo il nome che verrà attribuito al processo in questo specifico step, quindi inseriamo la parte statica “Gestione Rinnovi” seguita dal valore della variabile “Nome Installazione” -nel campo “Azione richiesta” inseriamo una breve descrizione dell’attività da svolgere -spuntiamo il campo checkbox “Mostra nell’entità collegata” per far attivare la modalità popup del process helper Il risultato sarà quello mostrato in Figura 7. Figura 7 Configurazione form dinamica: Nella form dinamica creiamo i seguenti blocchi: A) Blocco “Informazioni Installazione” (vedi Figura 8) con i seguenti campi: 1 ”Nome Installazione” (campo testo) 2 "Azienda" (campo relazionato a) 3 "Data a servizio" (campo data) 4 "Stato" (campo picklist) Figura 8 B) Blocco “Informazioni Rinnovo”(vedi Figura 9) con i seguenti campi: 1 Campo tabella “Rinnovi” (vedi Figura 10) con le seguenti colonne: 1.1“Nome Rinnovo” (campo testo) 1.2 “Data inizio” (campo data) 1.3“Data fine” (campo data) 1.4“Note aggiuntive”(campo area di testo) N.B: Impostiamo sia nel campo tabella che nelle singole colonne i permessi in sola lettura poiché al suo interno verranno riportati                  solamente i rinnovi passati 2 “Azione”(campo picklist) con i seguenti valori: vuoto, “Rinnova” e “Non rinnovare” (vedi Figura 11) 3 “Numero Mesi rinnovo” (campo numero) 4 ”Note aggiuntive” (campo area di testo) 5 ”Motivo rifiuto rinnovo” (campo area di testo) Figura 9 Figura 10 Figura 11 Configurazione azione Resetta Form Dinamica Andiamo a creare un’azione di “Resetta form dinamica” così che al prossimo rinnovo il process helper potrà essere nuovamente compilato in quanto verranno resettati i valori dei campi presenti nella form (vedi Figura 12). Figura 12 Configurazione campi condizionali su form dinamica Andiamo ad impostare una serie di regole per gestire i permessi di visibilità dei campi della form al fine di fornire all’utente un’esperienza di compilazione più chiara ed efficiente. Quindi creiamo le seguenti regole: -se Azione uguale a Non rinnovare nascondi Numero mesi Rinnovo, Note aggiuntive e metti obbligatorio Motivo rifiuto rinnovo (vedi Figure 13 e 14) Figura 13 Figura 14 -se campo tabella Rinnovi Passati ha 0 righe nascondilo (vedi Figure 15 e 16) Figura 15 Figura 16 -se Azione uguale a Rinnova metti obbligatorio Numero mesi Rinnovo e nascondi Motivo rifiuto rinnovo (vedi Figure 17 e 18) Figura 17 Figura 18 -se Azione uguale a vuoto nascondi Numero mesi Rinnovo, Note aggiuntive e Motivo rifiuto rinnovo (vedi Figure 19 e 20) Figura 19 Figura 20 Nella ScriptTask “Cicla rinnovi ed inserisci in form dinamica” configuriamo un’azione di cicla record relazionati ed inserisci in campo tabella “Rinnovi Passati” per dare all’utente la visibilità di tutti i rinnovi passati (vedi Figura 21).  Quindi in ogni colonna del campo tabella andiamo ad inserire il valore “corrente” dei corrispettivi campi del modulo Rinnovi(vedi Figura 22). Figura 21 Figura 22 Nella Condition Task “Controllo PH gestione rinnovo” andiamo ad eseguire un controllo sul campo “Azione” della form del process helper per indirizzare il processo nel ramo relativo al valore inserito dall’utente (vedi Figura 23) Figura 23 Nel gateway successivo andiamo ad associare ad ogni gruppo di condizioni (inserite nella task precedente) il ramo corrispettivo da percorrere (vedi Figura 24) Figura 24 Configurazione degli elementi successivi al ramo “Non rinnovare” Nella ScriptTask “Aggiorna motivo rifiuto rinnovo” configuriamo un’azione di aggiorna entità per aggiornare il campo “Motivo rifiuto rinnovo” dell’installazione con il contenuto del campo “Motivo rifiuto Rinnovo” della form del process helper (vedi Figura 25). Figura 25 Anche l’endEvent deve essere configurato, in quanto, abbiamo coinvolto un process helper nel processo, quindi si rende necessario andare ad attivare un process helper al suo interno per impostare lo stato del processo in “Terminato” (vedi Figura 26) Figura 26 Configurazione degli elementi successivi al ramo “Rinnova” Nella ScriptTask “Aggiorna dati installazione” configuriamo un’azione di aggiorna entità per aggiornare il valore dei seguenti campi (vedi Figura 27): -“Data scadenza prossimo rinnovo”: Adesso + variabile della form del process helper “Numero mesi Rinnovo” -”Stato”: “A Servizio” Figura 27 Nella ScriptTask "Cicla rinnovi precedenti e disattivali” configuriamo un’azione di cicla record relazionati ed aggiorna entità per aggiornare tutti i rinnovi collegati all’installazione impostando il loro stato in “Non attivo” (vedi Figure 28 e 29) Figura 28 Figura 29 Nella ScriptTask “Crea rinnovo e collegalo all'installazione” configuriamo un’azione di crea entità per creare un record del modulo rinnovi e relazionarlo all’installazione (vedi Figura 30). Figura 30 Nella ScriptTask “Aggiorna nome rinnovo” configuriamo un’azione di aggiorna entità sul rinnovo per aggiornare il campo “Nome Rinnovo” inserendo il contenuto del campo stesso e successivamente il contenuto della variabile “Numero Rinnovo”. In questo modo ogni rinnovo che verrà creato avrà una prima parte composta dalla parola “Rinnovo” e una seconda parte composta da un numero dinamico progressivo (Nome Rinnovo). (Vedi Figura 31) Figura 31 8.2 Attivazione di un Processo Avanzato - Gestione Rinnovi Installazioni Ora procediamo con la visione del processo in azione. Creiamo quindi un nuova installazione inserendo le informazioni richieste (vedi Figura 1). Figura 1 Dopo il salvataggio il processo partirà posizionandosi sul timer per attendere il raggiungimento della “Data scadenza prossimo rinnovo” (26-02-2022). Infatti osservando il grafico processo possiamo notare che il timer nel diagramma risulta essere circondato da un contorno di colore blu. (vedi Figura 2) Figura 2 Una volta raggiunta la data di scadenza, il processo imposterà automaticamente lo stato in “Fuori Servizio” e presenterà un task all’assegnatario dell’installazione per poter compilare il popup per gestire il prossimo rinnovo. Il popup quindi potrà essere compilato cliccando sul pulsante “Compila” alla destra del task (vedi Figura 3) Figura 3 La task descritta sopra però sarà visibile solamente entrando sull’anagrafica dell’installazione, per questo è possibile in questo caso compilare il process helper attraverso la sezione “Processi” raggiungibile dal menù in alto a destra. (vedi Figura 4) Figura 4 Infatti in essa sono riportati tutti i processi pendenti assegnati direttamente all’utente o ad eventuali gruppi di cui fa parte, quindi basterà cercare la riga avente le seguenti informazioni (vedi Figura 5): -nome processo: “Gestione Rinnovi Installazione Server 1” -collegato a: “ Installazione Server 1” Dopodiché sarà sufficiente cliccare sulla matita alla sinistra del nome processo per poter compilare il process helper che sarà visualizzato come se fossimo in modifica di un modulo. Figura Una volta arrivati sulla form del process helper l’utente si ritroverà davanti alla schermata mostrata in Figura 6. In base al valore del campo Azione si attiveranno I campi condizionali creati precedentemente che gestiranno I permessi dei campi della form coinvolti nelle regole. N.B: Non essendo ancora stato fatto nessun rinnovo, la tabella Rinnovi Passati è stata nascosta sempre attraverso I campi condizionali. Figura 6 Volendo simulare un rinnovo dell’installazione clicchiamo sul valore “Rinnova”, in questo modo il sistema ci mostrerà I campi “Numero mesi Rinnovo” e “Note aggiuntive” (vedi Figura 7). Figura 7 Una volta compilati I 2 campi citati in precedenza salviamo e il processo genererà un rinnovo che verrà automaticamente relazionato all’installazione (vedi Figura 8). Figura 8 Dal primo rinnovo in poi il process helper mostrerà il campo tabella Rinnovi Passati come mostrato in Figura 9 Simulando invece di non voler rinnovare clicchiamo sul valore “Non rinnovare”, il sistema ci richiederà di inserire un motivo rifiuto del rinnovo (vedi Figura 10). Al salvataggio verrà popolato il campo “Motivo rifiuto rinnovo” dell’installazione. Figura 10 9 Approfondimenti su Azione Cicla Record Relazionati nei Processi 9.1 Somma parziale dei record relazionati coinvolti in un ciclo Per eseguire la somma parziale dei record di uno specifico modulo avente relazione 1-N o N-N con il modulo di partenza, non è possibile utilizzare la voce "Somma", in quanto, il sistema prenderà sempre in considerazione TUTTI i record relazionati. Quindi, per ottenere il risultato desiderato, si dovrà configurare un'azione di cicla record relazionati e per ogni riga "Aggiorna entità", in questo modo andremo a salvare il totale all'interno di un campo del modulo di partenza o di una form dinamica (dalla versione 24.08 in poi). Una volta inserite la condizione nella sezione "Condizioni sul campo" per coinvolgere nel ciclo solamente i record interessati, nell'azione di aggiorna entità si dovrà sfruttare la funzione SDK fieldAction Standard "vte_sum()" (per approfondimenti vedere capitolo 12.1) per aggiungere (ad ogni ciclo) il valore del record corrente al contenuto che è già presente nel campo in cui si sta salvando il risultato. ATTENZIONE! -> nel caso in cui si configurasse un processo che si scatena in maniera ricorrente, per ottenere il risultato corretto si deve impostare un'azione di aggiorna entità che svuoti il contenuto del campo nel quale si vuole salvare il risultato. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di un'azione di cicla record relazionati sul modulo Installazioni (partendo dal modulo Azienda) con la quale vogliamo calcolare la somma del campo "Numero manutenzioni annuali" solamente delle installazioni aventi nella colonna "Stato" il valore "A Servizio" e salvarne il risultato nel campo "Tot manutenzioni su installazioni attive" dell'azienda (Figura 1) Figura 1 All'interno del processo configuriamo un'azione di cicla record relazionati (Installazioni) e per ogni riga aggiorna entità del modulo "Aziende" (Figura 2 e 3) Figura 2 Figura 3 Nella sezione "Condizioni sul campo" andiamo ad inserire "Stato" = "A Servizio" (Figura 4) Figura 4 All'interno del campo "Tot manutenzioni su installazioni attive" andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni SDK" (Figura 5) Figura 5 Come primo parametro inseriamo la variabile che identifica il contenuto del campo "Tot manutenzioni su installazioni attive" (Figura 6) Figura 6 Come secondo parametro inseriamo la variabile che identifica il valore corrente del campo "Numero manutenzioni annuali" delle installazioni coinvolte nel ciclo (Figura 7) Figura 7 10 Approfondimenti su Utilizzo Campi Tabella nei Processi 10.1 Approfondimenti su Utilizzo Campi Tabella nei Processi Per poterne sfruttare il contenuto all'interno dei processi, il sistema mette a disposizione (nella picklist "Seleziona opzione") una sezione dedicata per ogni campo tabella coinvolto nei moduli o form dinamiche associate al processo (Figura 1) Figura 1 Cliccando su una sezione specifica, il sistema permette di selezionare rapidamente una tra le colonne presenti nel campo tabella preso in esame (Figura 2) Figura 2 NOTA BENE: il sistema esegue in automatico un filtro basandosi sul campo di partenza dal quale si sta consultando la picklist "Seleziona opzioni", di conseguenza mostrerà solamente le colonne del campo tabella la cui tipologia può essere accettata dal campo di partenza. Se, ad esempio, all'interno del campo "Membro di" del modulo Azienda volessi inserire il contenuto della colonna di tipo testo "Indirizzo", il sistema non renderò disponibile tale colonna, questo perché permetterà di selezionare solamente le colonne del campo tabella di tipologia "Relazionato a". Nel caso in cui non fossero presenti colonne di tale tipologia, il sistema non renderà disponibile l'intera sezione del campo tabella (Figura 3) Figura 3 In alternativa, è possibile accedere alle colonne del campo tabella selezionando la sezione relativa al modulo in cui si trova il campo tabella e scorrendo tra i vari campi disponibili (Figura 4 e 5) Figura 4 Figura 5 Una volta selezionata la colonna del campo tabella interessata, verrà presentata un'ulteriore picklist alla destra del campo "Seleziona opzioni", dalla quale sarà possibile selezionare una tra le voci disponibili (Figura 6) Figura 6 - "Somma" -> solo per le colonne di tipologia Numero, Valuta e Percentuale, permette di ottenere la somma di tutte le righe presenti nel campo tabella interessato. NOTA BENE: questa voce sarà comunque disponibile anche per le altre tipologie di colonne ma, logicamente, non produrrà alcun risultato. -"Minimo" -> solo per le colonne di tipologia Numero, Valuta e Percentuale, permette di ottenere il valore più basso tra tutte le righe presenti nel campo tabella interessato. NOTA BENE: questa voce sarà comunque disponibile anche per le altre tipologie di colonne ma, logicamente, non produrrà alcun risultato. -"Massimo" -> solo per le colonne di tipologia Numero, Valuta e Percentuale, permette di ottenere il valore più alto tra tutte le righe presenti nel campo tabella interessato. NOTA BENE: questa voce sarà comunque disponibile anche per le altre tipologie di colonne ma, logicamente, non produrrà alcun risultato. -"Media" -> solo per le colonne di tipologia Numero, Valuta e Percentuale, permette di ottenere il valore medio tra tutte le righe presenti nel campo tabella interessato. NOTA BENE: questa voce sarà comunque disponibile anche per le altre tipologie di colonne ma, logicamente, non produrrà alcun risultato. -"Ultimo" -> permette di ottenere il valore dell'ultima riga presente nel campo tabella interessato. -"Sequenza" -> permette di ottenere il valore di una riga specifica (se presente) del campo tabella. Per indicare esattamente il numero della riga si dovrà compilare il campo che verrà presentato sulla destra e infine cliccare sul pulsante dedicato (Figura 7) Figura 7 Nel caso in cui volessimo, invece, prendere in considerazione solamente una parte delle righe presenti nel campo tabella, dovremo necessariamente utilizzare un'azione di cicla righe (per approfondimenti sul suo funzionamento visionare il capitolo 10.2 del manuale dei processi) Questo perché, se non eseguiamo un ciclo sul campo tabella, il sistema prenderà in considerazione sempre TUTTE le righe presenti nel campo tabella. Infatti, all'interno di un'azione di cicla righe, sarà possibile indicare delle condizioni che permetteranno di coinvolgere solamente le righe che le soddisfano. Queste condizioni dovranno essere indicate nella sezione "Condizioni sul campo" (Figura 8) Figura 8 Per utilizzare solamente le colonne delle righe che si stanno ciclando e che rispettano le condizioni impostate, all'interno della picklist "Seleziona" disponibile alla destra del campo "Seleziona opzioni" sarà possibile selezionare una voce aggiuntiva denominata "Corrente" (Figura 9) Figura 9 Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di azione di cicla righe sul campo tabella "Sedi" del modulo Azienda (Figura 10) dal quale vogliamo creare un record del modulo custom "Sedi" per ogni riga avente nella colonna Stato il valore "IT". Figura 10 All'interno del processo configuriamo un'azione di cicla righe e per ogni riga crea entità del modulo custom "Sedi" (Figura 11) Figura 11 Nella sezione "Condizioni sul campo" andiamo ad inserire Stato = "IT" mentre nella sezione "Modulo" selezioniamo la voce "Sede"(Figura 12) Figura 12 Nei campi relativi all'indirizzo del modulo Sede inseriamo il contenuto delle varie colonne selezionando sempre la voce "Corrente" della picklist "Seleziona" disponibile alla destra del campo "Seleziona opzioni" (Figura 13) Figura 13 Riprendendo la Figura 10, come risultato finale otterremo la creazione di due record totali del modulo Sedi, il primo record corrispondente alla prima riga e il secondo record corrispondente alla terza riga. 10.2 Somma parziale delle righe di un campo tabella coinvolte in un ciclo Come anticipato nel capitolo 10.1, per eseguire la somma parziale delle righe di un campo tabella coinvolte in un ciclo, non è possibile utilizzare la voce "Somma", in quanto, il sistema prenderà sempre in considerazione TUTTE le righe presenti all'interno del campo tabella. Infatti, la voce "Somma" è una variabile disponibile anche nel caso in cui non si esegua un ciclo. La sua esistenza è finalizzata ad ottenere facilmente la somma di tutte le righe di un campo tabella senza dover necessariamente configurare un'azione di cicla righe. Quindi, per ottenere il risultato desiderato, si dovrà configurare un'azione di cicla righe e per ogni riga "Aggiorna entità", in questo modo andremo a salvare il totale all'interno di un campo di un modulo o di una form dinamica (dalla versione 24.08 in poi). Una volta inserite la condizione nella sezione "Condizioni sul campo" per coinvolgere nel ciclo solamente le righe interessate, nell'azione di aggiorna entità si dovrà sfruttare la funzione SDK fieldAction Standard "vte_sum()" (per approfondimenti vedere capitolo 12.1) per aggiungere (ad ogni ciclo) il valore della riga corrente al contenuto che è già presente nel campo in cui si sta salvando il risultato. ATTENZIONE! -> nel caso in cui si configurasse un processo che si scatena in maniera ricorrente, per ottenere il risultato corretto si deve impostare un'azione di aggiorna entità che svuoti il contenuto del campo nel quale si vuole salvare il risultato. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di un'azione di cicla righe sul campo tabella "Partecipanti" (Figura 1) del modulo Leads dal quale vogliamo calcolare la somma della colonna "Numero" solamente delle righe aventi nella colonna "Tipologia" il valore "Rivenditore" e salvarne il risultato nel campo "Totale Rivenditori" (Figura 2) Figura 1 Figura 2 All'interno del processo configuriamo un'azione di cicla righe e per ogni riga aggiorna entità del modulo "Leads" (Figura 3 e 4) Figura 3 Figura 4 Nella sezione "Condizioni sul campo" andiamo ad inserire "Tipologia" = "Rivenditore" (Figura 5) Figura 5 All'interno del campo "Totale Rivenditori" andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni SDK" (Figura 6) Figura 6 Come primo parametro inseriamo la variabile che identifica il contenuto del campo "Totale Rivenditori" (Figura 7) Figura 7 Come secondo parametro inseriamo la variabile che identifica il valore corrente della colonna "Numero" delle righe del campo tabella coinvolte nel ciclo (Figura 8) Figura 8 Riprendendo le Figure 1 e 2, come risultato finale otterremo la somma della colonna "Numero" della prima e terza riga del campo tabella, che nel nostro caso corrisponde al valore 8 (Figura 9) Figura 9 11 SDK di Processo: Installazione e Configurazione All’interno dei processi è possibile richiamare delle funzioni PHP al fine di eseguire delle operazioni od utilizzare dei dati non disponibili nello standard del motore BPMN.In particolare, esistono 3 differenti tipologie di funzioni registrabili e richiamabili in punti differenti della configurazione di un processo: Fied Action, Task Action e Task Condition. 11.1 SDK Field Action Questa tipologia di funzione viene normalmente utilizzata per valorizzare i campi di un record, form dinamica, ecc. con dei valori calcolati utilizzando il seguente metodo: SDK::setProcessMakerFieldAction($func, $src, $label, $parameters=''); $func : nome della funzione $src : percorso file contenente la funzione $label : etichetta della funzione $parameters (optional) : parametri statici (es. riferimento campo fisso) Per de-registrare il file usare: SDK::unsetProcessMakerFieldAction($func); $func: nome della funzione Queste funzioni possono essere richiamate dalle sezioni apposite “Funzioni SDK” disponibili nel menù a tendina “Selezione opzione” situato in alto a destra di ogni singolo campo. N.B: Tutte le funzioni custom registrate verranno sempre inserite nella sezione “Funzioni SDK”, la sezione “Funzioni data” viene utilizzata esclusivamente per contenere le funzione php disponibili a standard che riguardano I campi data. Un esempio concreto di funzione SDK di questa tipologia è la funzione “sum()” che restituisce la somma dei parametri (statici o dinamici) passati. E’ possibile memorizzare il risultato in un campo di una form dinamica di un Process helper inserendo la funzione come valore di default, oppure inserirlo direttamente in campo di un modulo sfruttando le azioni standard di crea o aggiorna entità. Esempio Registro una funzione per il calcolo della percentuale che avrà bisogno dei parametri in ingresso percentuale e totale. SDK::setProcessMakerFieldAction('vte_calculate_percentage','modules/SDK/src/ProcessMaker/Utils.php','Calculate percentage (percentage,total)'); Nella funzione implementata indicherò quindi i 2 parametri e ritornerò il risultato dell'operazione. function vte_calculate_percentage($percentage, $total) { global $engine, $current_process_actionid; $value = ($percentage / 100) * $total; return $value; } N.B. All’interno delle funzioni registrate sono disponibili le variabili globali $engine e $current_process_actionid. Queste contengono rispettivamente l'oggetto contenente tutte le informazioni relative al processo che si sta eseguendo e l'id dell'azione corrente (es. Crea entità, Aggiorna entità, ... ) 11.2 SDK Action E’ una tipologia di funzione che viene utilizzata per creare delle azioni BPMN custom. È possibile registrare nuove azioni con il seguente metodo: SDK::setProcessMakerAction($func, $src, $label); $func : nome della funzione $src : percorso file contenente la funzione $label : etichetta della funzione Per de-registrare il file usare: SDK::unsetProcessMakerAction($func); $func: nome della funzione Una volta registrata, si rende disponibile all’utilizzo nella sezione “Azione” nella quale sono presenti tutte le altre azioni BPMN. Inoltre una volta scelta la funzione da richiamare, se nella funzione gestiamo dei parametri di input abbiamo la possibilità di passarli direttamente da interfaccia: Esempio Nel seguente esempio registro una funzione per aggiungere un invitato ad un evento. SDK::setProcessMakerAction('vte_add_event_invitee', 'modules/SDK/src/ProcessMaker/Utils.php', 'Add invitee to event (event, user/contact)'); Questa funzione necessita di due parametri: l'id dell'evento e l'id dell'invitato che può essere un utente o un contatto. Per chiarezza indico nel comando di registrazione anche i parametri nella label della funzione. Nella funzione che andrò a sviluppare vanno aggiunti i parametri $event e $invitee che saranno popolati con i valori passati dall'interfaccia di configurazione dell'azione. I primi due parametri invece sono fissi e sono: $engine l'oggetto contenente tutte le informazioni relative al processo che si sta eseguendo $actionid l'id dell'azione corrente function vte_add_event_invitee($engine, $actionid, $event, $invitee) { $engine->log('vte_add_event_invitee', "event:$event invitee:$invitee"); if (strpos($event,'x') !== false) list(,$event) = explode('x',$event); if (strpos($invitee,'x') !== false) list(,$invitee) = explode('x',$invitee); $parent_module = getSalesEntityType($invitee); if ($parent_module == 'Contacts') { $_REQUEST['inviteesid_con'] = $invitee; } else { $_REQUEST['inviteesid'] = $invitee; } $focus = CRMEntity::getInstance('Events'); $focus->retrieve_entity_info_no_html($event,'Events'); $focus->mode = 'edit'; $focus->save('Events'); } Se necessario, sarà possibile prevedere all'interno della funzione il return di un valore che poi sarà richiamabile e salvabile all'interno di un campo di un form dinamica o di un modulo attraverso la variabile "Risultato" nella sezione dedicata disponibile nella picklist "Seleziona opzione". 11.3 SDK Task Condition E’ una tipologia di funzione che viene utilizzata per eseguire dei controlli custom nelle task di controllo dei processi (conditional task). Per registrarle va utilizzato il metodo: SDK::setProcessMakerTaskCondition($func, $src, $label) $func : nome della funzione $src : percorso file contenente la funzione $label : etichetta della funzione Per de-registrare il file usare: SDK::unsetProcessMakerTaskCondition($func); $func : nome della funzione Se richiamate sulla task di “condizione iniziale” (task nella quale vengono definite le regole di partenza del processo), è possibile rendere specifica la partenza del processo in base al risultato restituito. Se richiamate invece sulle delle semplici task di controllo permettono di far prendere al processo strade differenti in base al risultato restituito. Le funzioni di questa tipologia saranno sempre disponibili sotto forma di variabili utilizzabili per eseguire controlli. Un esempio concreto di funzione SDK di questa tipologia è la funzione “get_running_process_current_user” che permette di verificare se il nome dell’utente corrente è uguale o diverso dall’utente definito nella condizione. Se utilizzata nella condizione iniziale permette di far partire il processo solamente se l’utente corrente è uguale ad un determinato utente. Esempio Registro una funzione per verificare se l'indirizzo di fatturazione dell'azienda è uguale quello di spedizione. SDK::setProcessMakerTaskCondition('vte_compare_account_bill_ship_street', 'modules/SDK/src/ProcessMaker/Utils.php', 'Indirizzi di spedizione e fatturazione uguali [e/n]'); Nella funzione implementata sono presenti i seguenti parametri. $module: modulo dell'entità su cui viene eseguita la condizione $id: identificativo dell'entità in formato ws (es. 3x55126) $data: array con i valori dei campi del record La funzione deve restituire una stringa da usare per il confronto lato interfaccia. function vte_compare_account_bill_ship_street($module, $id, $data) { list($wsModId,$id) = explode('x',$id); // do it every time if ($data['bill_street'] == $data['ship_street']) { return 'e'; } else { return 'n'; } } A questo punto posso configurare un processo che parte alla creazione di un'azienda quando l'indirizzo di di fatturazione è diverso da quello di spedizione. 11.4 Procedura di registrazione SDK di processo La procedura descritta qui di seguito è la stessa per le 3 tipologie di funzioni sdk di processo. Supponiamo di dover creare e registrare una funzione SDK di tipo “FIELD ACTION” che permetta di eseguire la divisione tra più valori. Una volta scritta, dovrà essere inserita nel file Utils.php disponibile nel percorso modules/SDK/src/ProcessMaker. Successivamente dovrà essere registrata attraverso il seguente comando da inserire nel file script.php disponibile nel percorso plugins/script : SDK::setProcessMakerFieldAction('nome funzione','percorso','label funzione'); 'nome funzione' → nome della funzione ‘percorso’ → percorso in cui si trova la funzione da registrare ‘label funzione’ → nome con il quale la funzione verrà visualizzata dall’utente nella sezione processi. Inseriamo quindi il comando nel file script.php e lo compiliamo con I dati dell’sdk: SDK::setProcessMakerFieldAction('division','modules/SDK/src/ProcessMaker/Utils.php','division(value1,value2,...)'); N.B: Ogni tipologia ha il proprio comando dedicato, quindi nel caso dovessimo caricate un sdk di tipo “ACTION” dovremmo utilizzare il seguente comando: SDK::setProcessMakerAction('nome funzione','percorso','label funzione'); Nel caso invece dovessimo caricate un sdk di tipo “TASK CONDITION” dovremmo utilizzare il seguente comando: SDK::setProcessMakerTaskCondition('nome funzione','percorso','label funzione'); Una volta completati questi passaggi, basterà lanciare il file script.php e la funzione verrà correttamente registrata. 12 SDK di Processo fieldAction Standard: Descrizione e Utilizzo 12.1 SDK fieldAction: Somma Questa funzione SDK permette di eseguire la somma tra 2 o più valori che vanno passati come parametri. Essendo una funzione di tipo fieldAction, può essere richiamata all'interno dei singoli campi dei moduli o form dinamiche. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione vte_sum() per eseguire la somma tra i valori di due campi denominati "Stima Ore Sviluppo" e "Stima Ore Formazione" e salvarne il risultato nel campo "Totale ore stimate" (Figura 1) Figura 1 All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Totale ore stimate". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni SDK" (Figura 2) Figura 2 Infine passiamo come parametri (separati dalla virgola) il contenuto dei due campi da sommare  (Figura 3) Figura 3 12.2 SDK fieldAction: Differenza Questa funzione SDK permette di eseguire la differenza tra 2 o più valori che vanno passati come parametri. Essendo una funzione di tipo fieldAction, può essere richiamata all'interno dei singoli campi dei moduli o form dinamiche. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione vte_diff() per eseguire la differenza tra i valori di due campi denominati "Ore previste" e "Ore usate" e salvarne il risultato nel campo "Ore rimanenti" (Figura 1) Figura 1 All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Ore rimanenti". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni SDK" (Figura 2) Figura 2 Infine passiamo come parametri (separati dalla virgola) il contenuto dei due campi da sottrarre  (Figura 3) Figura 3 12.3 SDK fieldAction: Moltiplicazione Questa funzione SDK permette di eseguire la moltiplicazione tra 2 o più valori che vanno passati come parametri. Essendo una funzione di tipo fieldAction, può essere richiamata all'interno dei singoli campi dei moduli o form dinamiche. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione vte_mul() per eseguire la la moltiplicazione tra il contenuto dei due campi denominati "Costo fisso a km: (€)" e "Numero km percorsi" e salvarne il risultato nel campo "Totale costo: (€)" (Figura 1)  Figura 1 All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Totale costo: (€)". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni SDK" (Figura 2) Figura 2 Infine passiamo come parametri (separati dalla virgola) i due valori da moltiplicare (Figura 3) Figura 3 12.4 SDK fieldAction: Divisione Questa funzione SDK permette di eseguire la divisione tra 2 o più valori che vanno passati come parametri. Essendo una funzione di tipo fieldAction, può essere richiamata all'interno dei singoli campi dei moduli o form dinamiche. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione vte_div() per eseguire la la divisione tra il campo "Stima Ore Sviluppo" e un valore fisso 8 (che rappresentano le ore lavorative in un giorno) e salvarne il risultato nel campo "Stima gg Sviluppo" (Figura 1)  Figura 1 All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Stima gg Sviluppo". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni SDK" (Figura 2) Figura 2 Infine passiamo come parametri (separati dalla virgola) i due valori da dividere (Figura 3) Figura 3 12.5 SDK fieldAction: vte_json_column_fields Questa funziona SDK permette di generare un codice JSON contenente le label e i valori dei 2 o più campi passati come parametri. Come primo parametro va passato il crmid del record dal quale si vogliono estrarre le informazioni, invece come parametri successivi andranno passati i "fieldname" dei campi da includere, ovvero i nomi in cui quei campi sono registrati a Data Base. NOTA BENE: anche se nella descrizione della funzione viene indicato di passare i parametri successivi all'id inserendo delle parentesi quadre, quest'ultime non devono essere inserite. Viene utilizzata principalmente per formattare un subset di dati al fine di eseguire delle chiamate Web Service di tipo REST (configurabili sempre da processo tramite l'azione standard dedicata "Chiama Web Service Esterno"). Per approfondimenti sulla configurazione di chiamate API da processo si prega di consultare il capitolo 3.15 del manuale dei processi. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione SDK vte_json_column_fields() per la generazione di un codice JSON contenente i seguenti campi e valori di un'istanza del modulo Assistenza Clienti coinvolta nel processo: Titolo Stato All'interno della form dinamica di un process helper procediamo con la creazione di un campo area di testo denominato "Body JSON Format" nel quale verrà salvato il risultato della funzione. Successivamente andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" e ad accedere alla sezione "Funzioni SDK" (Figura 1) Figura 1 Infine passiamo i parametri richiesti dalla funzione, tutti separati dalla virgola. Nello specifico, come primo parametro inseriamo il crmid del record dal quale si vogliono estrarre le informazioni, quindi nel nostro caso l'id del ticket. (Figura 2) Figura 2 Invece, come parametri successivi, inseriamo i "fieldname" dei campi da coinvolgere, ovvero i nomi con cui quei campi sono registrati a Data Base. Nel nostro caso specifico saranno "ticket_title", "ticketstatus" e "ticketpriorities". (Figura 3) Figura 3 Per ricavarli facilmente, sarà sufficiente selezionare il campo relativo dalla picklist "Selezione Opzione" ed eliminare il riferimento all'istanza coinvolta nel processo, ovvero il metaid (Figura 4). Figura 4 Il codice JSON generato sarà come quello mostrato in Figura 5 Figura 5  12.6 SDK fieldAction: vte_json_string Questa funziona SDK permette di convertire una stringa in formato JSON gestendo la compatibilità con in caratteri speciali, in modo da formattarli correttamente ed evitare che entrino in conflitto con esso. Viene utilizzata principalmente per formattare delle stringhe al fine di eseguire delle chiamate Web Service di tipo REST (configurabili sempre da processo tramite l'azione standard dedicata "Chiama Web Service Esterno") senza riscontrare errori di sintassi sul JSON. Nello specifico, nel caso in cui nella stringa fossero presenti dei caratteri speciali utilizzati nella sintassi del JSON come le doppie virgolette ("), lo slash (/) e il backslash (\), la funzione andrà ad inserire in automatico ulteriori backslash per evitare che il JSON generi un errore. Come unico parametro, quindi, passiamo il contenuto di un campo qualsiasi (purché sia una stringa) oppure un semplice valore statico. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione SDK vte_json_string() per la formattazione del campo "Descrizione" contenente la seguente stringa: E \ a quel punto / gli dissi: "Addio!" (Figura 1) Figura 1 All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Descrizione". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni SDK" (Figura 2) Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) Infine passiamo come unico parametro il contenuto del campo da formattare (Figura 3) Figura 3 Il risultato generato dalla funzione sarà come quello mostrato in Figura 4 Figura 4 12.7 SDK fieldAction: vte_json_field_string E' una funzione analoga a vte_json_string(), infatti permette allo stesso modo di convertire una stringa in formato JSON gestendo la compatibilità con in caratteri speciali, in modo da formattarli correttamente ed evitare che entrino in conflitto con esso. Anch'essa viene utilizzata principalmente per formattare delle stringhe al fine di eseguire delle chiamate Web Service di tipo REST (configurabili sempre da processo tramite l'azione standard dedicata "Chiama Web Service Esterno") senza riscontrare errori di sintassi sul JSON. Nello specifico, nel caso in cui nella stringa fossero presenti dei caratteri speciali utilizzati nella sintassi del JSON come le doppie virgolette ("), lo slash (/) e il backslash (\), la funzione andrà ad inserire in automatico ulteriori backslash per evitare che il JSON generi un errore. Per approfondimenti sulla configurazione di chiamate API da processo si prega di consultare il capitolo 3.15 del manuale dei processi. La vera differenza consiste nei parametri inseribili in input. Come primo parametro va passato il crmid del record dal quale si vogliono estrarre le informazioni, invece come secondo parametro va passato il "fieldname" del campo da includere, ovvero il nome in cui quel campo è registrato a Data Base. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione SDK vte_json_field_string() per la formattazione in codice JSON del campo "Città (Fatturazione)" di un'istanza del modulo Azienda coinvolta nel processo contenente la seguente stringa: "Verona" (Figura 1) Figura 1 Il risultato poi verrà salvato all'interno del campo "Descrizione". All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Descrizione". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni SDK" (Figura 2) Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) Infine passiamo i parametri richiesti dalla funzione, tutti separati dalla virgola. Nello specifico, come primo parametro inseriamo il crmid del record dal quale si vogliono estrarre le informazioni, quindi nel nostro caso l'id dell'azienda. (Figura 3) Figura 3 Invece, come secondo parametro, inseriamo il "fieldname" del campo da coinvolgere, ovvero il nome con cui quel campo è registrato a Data Base. Nel nostro caso specifico sarà "bill_city". (Figura 4) Figura 4 Per ricavarlo facilmente, sarà sufficiente selezionare il campo relativo dalla picklist "Selezione Opzione" ed eliminare il riferimento all'istanza coinvolta nel processo, ovvero il metaid (Figura 5). Figura 5 Il risultato generato dalla funzione sarà come quello mostrato in Figura 6 Figura 6 12.8 SDK fieldAction: vte_json_record Questa funziona SDK permette di generare un codice JSON contenente le label e i valori di tutti i campi di un'istanza di un modulo (record) passata in input. Come unico parametro va passato il crmid del record dal quale si vogliono estrarre le informazioni da inserire all'interno del codice JSON. Viene utilizzata principalmente per generare facilmente un codice JSON al fine di eseguire delle chiamate Web Service di tipo REST (configurabili sempre da processo tramite l'azione standard dedicata "Chiama Web Service Esterno"). Per approfondimenti sulla configurazione di chiamate API da processo si prega di consultare il capitolo 3.15 del manuale dei processi. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione SDK vte_json_record() per la generazione di un codice JSON contenente tutti i campi e valori di un'istanza del modulo Aziende coinvolta nel processo. All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Descrizione". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni SDK" (Figura 1) Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) Infine passiamo come unico parametro il crmid del record dal quale si vogliono estrarre le informazioni, in questo caso dell'Azienda (Figura 2)  Figura 2 Il risultato generato dalla funzione sarà come quello mostrato in Figura 3 Figura 3 (cliccare sull'immagine per una risoluzione grafica maggiore) 12.9 SDK fieldAction: Format Date Questa funzione SDK permette di convertire una qualsiasi data passata in input in un formato specifico. Come primo parametro va passato il valore di un campo di un modulo o form dinamica contenente la data che si vuole formattare, invece come secondo parametro va passato il formato secondo le seguenti sintassi: giorno / mese / anno(completo) -> d-m-Y Esempio: 25-10-2024 mese / giorno / anno(completo) -> m-d-Y Esempio: 10-25-2024 anno(completo) / mese / giorno -> Y-m-d Esempio: 2024-10-25 anno(completo) / giorno / mese -> Y-d-m Esempio: 2024-25-10 giorno / mese / anno(parziale) -> d-m-y Esempio: 25-10-24 mese / giorno / anno(parziale) -> m-d-y Esempio: 10-25-24 anno(parziale) / mese / giorno -> y-m-d Esempio: 24-10-25 anno(parziale) / giorno / mese -> y-d-m Esempio: 24-25-10 giorno / mese / anno(completo)  ore / minuti / secondi -> d-m-Y H:i:s Esempio: 25-10-2024 16:32:20 mese / giorno / anno(completo)  ore / minuti / secondi -> m-d-Y H:i:s Esempio: 10-25-2024 16:32:20 anno(completo) / mese / giorno  ore / minuti / secondi -> Y-m-d H:i:s Esempio: 2024-10-25 16:32:20 anno(completo) / giorno / mese  ore / minuti / secondi -> Y-d-m H:i:s Esempio: 2024-25-10 16:32:20 ore / minuti / secondi -> H:i:s Esempio: 16:32:20 solo giorno -> d Esempio: 25 solo mese -> m Esempio: 10 solo anno(completo) -> Y Esempio: 2024 solo anno(parziale) -> y Esempio: 24 solo ore -> H Esempio: 16 solo minuti -> i Esempio: 32 solo secondi -> s Esempio: 20 N.B: un risultato parziale non sarà gestibile all'interno di campi data o datetime, questo perché accettano solamente valori aventi almeno un giorno, mese e anno. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione SDK formatDate() per la formattazione del valore del campo "Periodo Creazione" di un'istanza del modulo Aziende e il suo salvataggio all'interno di un campo di un process helper. All'interno della form dinamica procediamo con la creazione di un campo data denominato "Data creazione" nel quale verrà salvato il risultato della funzione. Successivamente andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" e ad accedere alla sezione "Funzioni data" (Figura 1) Figura 1 Infine passiamo i parametri richiesti dalla funzione, tutti separati dalla virgola. Nello specifico, come primo parametro inseriamo valore del campo "Periodo Creazione" (Figura 2) Figura 2 Invece, come secondo parametro, passiamo il formato con il quale la funzione deve restituire la data, quindi nel nostro caso d-m-Y (Figura 3) Figura 3 Il risultato sarà come quello mostrato in figura 4 Figura 4 12.10 SDK fieldAction: Now Date Questa funzione SDK permette di ottenere e salvare la data odierna all'interno di un qualsiasi campo di tipo testo, area di testo, data e datetime. Di default (quindi senza passare alcun parametro), il risultato verrà sempre restituito nel formato "d-m-Y", per ottenere invece la data in un formato differente andrà passato il formato come unico parametro della funzione, per visionare nel dettaglio la sintassi di ogni casistica disponibile consultare il capitolo ... del manuale dei processi. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione SDK date_now() per il salvataggio della data odierna all'interno di un campo di un process helper. All'interno della form dinamica procediamo con la creazione di un campo data denominato "Data di oggi" nel quale verrà salvato il risultato della funzione. Successivamente andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" e ad accedere alla sezione "Funzioni data" (Figura 1) Figura 1 Infine, se necessario, passiamo il formato con il quale deve essere restituita la data (Figura 2) Figura 2 Il risultato sarà come quello mostrato in figura 3 Figura 3 12.11 SDK fieldAction: Diff Date Questa funziona SDK permette di eseguire la differenza tra due date passate come parametri in input. Come primi due parametri, separati dalla virgola, andranno passati i valori dei due campi di tipo data da coinvolgere nella differenza, tenendo però in considerazione che la funzione esegue il seguente calcolo:  parametro2 - parametro1 Il secondo parametro data non è obbligatorio, quindi nel caso in cui si passasse solamente un valore data (parametro1), il calcolo verrà eseguito prendendo in automatico come secondo parametro (parametro2) la data-ora odierna. Di default (quindi senza passare un terzo parametro), la funzione restituirà sempre il risultato del calcolo in secondi. Invece, per ottenere il risultato in giorni, si dovrà passare la stringa fissa "days". ATTENZIONE! nel caso in cui si scelga di far restituire il risultato in giorni, di default la funzione restituirà sempre un risultato positivo, per abilitare la restituzione di un risultato negativo si dovrà applicare una modifica al codice php. ESEMPIO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione SDK diffDate() per eseguire il calcolo della differenza tra i valori di due campi denominati "Data Inizio" e "Data Fine" e salvarne il risultato (in giorni) nel campo "Intervallo Temporale" (Figura 1) Figura 1 All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Intervallo Temporale". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni data" (Figura 2) Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) N.B: nella label della funzione selezionabile nella picklist "Seleziona opzione.." viene indicata la possibilità di passare un ulteriore parametro denominato "sla" che di default viene impostato a false, di fatto si tratta solamente di un refuso, pertanto risulta essere un parametro non gestibile. Come primo e secondo parametro (separati dalla virgola) passiamo i valori dei campi "Data Inizio" e "Data Fine" nell'ordine appena citato (Figura 3) Figura 3 Infine come terzo parametro passiamo la stringa fissa "days" (Figura 4) Figura 4 Il risultato sarà come quello mostrato in figura 5 Figura 5 12.12 SDK fieldAction: Set lead converted Questa funzione SDK permette al sistema di eseguire una serie di automatismi che consentono la corretta e completa conversione del lead. Infatti, questa funzione può essere utilizzata esclusivamente all'interno del processo di conversione del lead standard disponibile nella sezione "Process manager" con la dicitura "Lead conversion". (Figura 1) Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) Dalla funzione vengono eseguite le seguenti operazioni: 1) Vengono eliminati i riferimenti al lead nella tabella vte_email_directory 2) Nel caso in cui il lead fosse impostato tra i preferiti di qualche utente, la funzione lo sostituisce con l'azienda o il contatto coinvolti nel processo a seconda del valore selezionato nel campo "Trasferisci elementi collegati a". N.B: in caso di selezione del valore "vuoto", il lead non verrà sostituito. 3) Nel caso in cui il lead fosse presente tra le statiche newsletter di qualche campagna, la funzione lo sostituisce con l'azienda o il contatto coinvolti nel processo a seconda del valore selezionato nel campo "Trasferisci elementi collegati a". N.B: in caso di selezione del valore "vuoto", il lead non verrà sostituito. 4) Viene impostato a "1" il valore della colonna "converted" della tabella vte_leaddetails. Questo permette di nascondere completamente la visibilità del lead lato interfaccia (come se fosse stato eliminato). 5) Viene popolata la tabella vte_leadconvrel per tenere traccia della Data di conversione, crmid del lead, crmid dell'azienda, crmid del contatto e crmid dell'opportunità. Come primo parametro va passato il crmid del lead in fase di conversione. Come secondo parametro va passato il crmid dell'azienda (creata o esistente). Come terzo parametro va passato il crmid del contatto (se creato). Come quarto parametro va passato il crmid dell'opportunità (se creata). Come quinto parametro va passato l'id dell'utente che ha fatto scatenare il processo. Per evitare che il sistema esegua i punti 4) e 5) e che quindi il lead venga nascosto lato interfaccia, si deve aggiungere un sesto parametro nel quale inserire il valore statico "false". (Figura 2) Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) 12.13 SDK fieldAction: vte_formula Questa funzione SDK permette di replicare le stesse funzionalità dei campi formula. Quindi nelle formule è possibile utilizzare tutti gli operatori algebrici: più (+), meno (-), diviso (/), per (*). ESEMPIO 1 Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione SDK vte_formula() per eseguire il calcolo del contenuto del campo "Delta Budget fatturato valore ordini aperti" eseguendo la seguente formula:  "Budget" - ( "Fatturato anno corrente" + "Valore ordini aperti" ) (Figura 1) Figura 1  All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Delta Budget fatturato valore ordini aperti". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni data" (Figura 2) Figura 2 Il risultato sarà come quello mostrato in Figura 3 Figura 3 E’ inoltre possibile configurare dei controlli If/Else seguendo la struttura: if condizione then caso_vero else caso_falso end (in questo caso si possono utilizzare >, <, ==. non è ammesso l'operatore !=). ESEMPIO 2 Per comprenderne al meglio il funzionamento, qui di seguito viene riportato un esempio di utilizzo della funzione SDK vte_formula() per inserire nel campo "Formula di saluto" il valore "Sign." nel caso in cui il campo "Sesso" abbia valore "Maschio", in caso contrario il valore "Sign.na". (Figura 4) Figura 4 All'interno di una Action Task procediamo con la configurazione un'azione di Aggiorna entità coinvolgendo il campo "Formula di saluto". Nello specifico, andiamo a richiamare la funzione SDK interessata attraverso la picklist "Selezione Opzione" ed accedendo alla sezione "Funzioni data" (Figura 5) Figura 5 Selezionando Sesso = Maschio in fase di inserimento di un contatto il risultato sarà come quello mostrato in Figura 6 Figura 6 E’ comunque possibile effettuare espressioni anche con campi di tipo data, in particolare ci sono due operatori: time_diffdays: fornisce la differenza in giorni tra due date time_diff: fornisce la differenza in secondi tra due date. Nota. Se viene inserito un solo parametro nelle funzioni time_diff e time_diffdays il valore restituito nel campo formula è la differenza tra la data attuale e la data inserita in parametro. 13 SDK di Processo Action Standard: Descrizione e Utilizzo 13.1 SDK Action: Set entity reference Questa funzione SDK permette di forzare un determinato record all'interno di un'entità (dello stesso modulo) coinvolta nel processo. Viene utilizzata, principalmente, per poter eseguire una qualsiasi tipo di azione standard anche sui record che sono stati inseriti all'interno di campi "Relazionato a" di una form dinamica. Come primo parametro va passato il metaid (l'id che identifica univocamente l'istanza di un modulo all'interno di un processo) dell'istanza sulla quale si vuole forzare il record. Invece, come secondo parametro, va passato il crmid del record da forzare. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato l'esempio di utilizzo della funzione SDK Set entity reference() per la gestione dell'azienda esistente all'interno del processo BPMN standard di conversione del lead. Nella form dinamica del process helper (configurata nella User Task "Request details"), viene data la possibilità all'utente di creare una nuova azienda oppure di selezionarne una esistente. Nello specifico, il crmid dell'azienda esistente viene storicizzato in un campo di tipo "Relazionato a" presente all'interno della form dinamica (Figura 1) Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) Questa tipologia di campo non stabilisce una vera e propria relazione, di conseguenza non viene visto come un'istanza completa del modulo Aziende. Infatti, non possiede alcun metaid (ossia l'id che identifica univocamente l'istanza di un modulo all'interno di un processo). Per questo, le azioni eseguibili sul record contenuto nel campo di relazione sono limitate. Al contrario, l'entità istanziata dall'azione di Crea entità (configurata nella Action Task "Create account") possiede un proprio metaid (ovvero 61), questo perché è stata coinvolta a tutti gli effetti all'interno del processo (Figura 2) Figura 2 Nel caso del processo di conversione del lead, non è possibile coinvolgere all'interno dell'azione standard "Trasferisci relazioni" l'azienda contenuta all'interno del campo di relazione. Per risolvere questo problema, è possibile ricorrere all'utilizzo della funzione SDK Set entity reference() per forzare il record dell'azienda esistente (presente nel campo di relazione) all'interno dell'istanza del modulo Azienda coinvolta tramite l'azione di Crea entità (quindi dell'azienda creata direttamente nel processo). In questo modo, potranno essere eseguite tutte le azioni necessarie senza limitazioni. Quindi, all'interno dell'Action Task "Use existing account" è stata configurata un'azione di tipo "Funzioni SDK" nella quale è stata richiamata l'SDK Set entity reference(). Come primo parametro è stato passato il metaid dell'istanza dell'azienda creata, ovvero 61 (Figura 3) Figura 3 (cliccare sull'immagine per una risoluzione grafica maggiore) Come secondo parametro è stato passato il contenuto del campo di relazione contenente l'azienda esistente (Figura 4) Figura 4 (cliccare sull'immagine per una risoluzione grafica maggiore) In questo modo, per entrambe le casistiche (azienda creata o esistente), nell'Action Task "Transfer relations to account" è stato sufficiente configurare un'unica azione di Trasferisci relazioni. (Figura 5) Figura 5 (cliccare sull'immagine per una risoluzione grafica maggiore) 13.2 SDK Action: Add comment to ticket Questa funzione SDK permette di generare un commento che verrà inserito nella sezione "Commenti" del modulo Assistenza Clienti. Come primo parametro, andrà passato il crmid del ticket sul quale si vuole aggiungere il commento. Come secondo parametro, andrà passato il testo del commento da inserire. Come terzo parametro, andrà inserito l'id dell'utente o del contatto che dovrà figurare come autore del commento. Nel caso in cui, come terzo parametro, si passi l'id di un utente crm, come quarto parametro si dovrà passare la voce fissa "user". Invece nel caso in cui, come terzo parametro, si passi l'id di un record del modulo Contatti, come quarto parametro si dovrà passare la voce fissa "customer". Come quinto parametro, andrà passato il valore fisso "true" nel caso in cui si voglia inviare anche la mail automatica di avviso contenente il testo del commento e un link diretto per accedere rapidamente al dettaglio del ticket (come già avviene di default verso gli utenti portali nel momento in cui un utente crm scrive un commento). In caso contrario, andrà passato il valore fisso "false". ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato l'esempio di utilizzo della funzione SDK Add comment to ticket() per inserire in automatico un commento contenente il seguente testo: "Gentile cliente, prenderemo in carico la sua richiesta il prima possibile." All'interno di un'Action Task procediamo con la configurazione di un'azione di tipo "Funzioni SDK" nella quale richiamiamo l'SDK Add comment to ticket(). Come primo parametro passiamo il crmid del ticket sul quale si vuole aggiungere il commento, nel nostro caso $44-crmid (Figura 1) Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) Come secondo parametro passiamo il testo del commento da inserire, ovvero "Gentile cliente, prenderemo in carico la sua richiesta il prima possibile." (Figura 2) Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore) Come terzo parametro passiamo lo userid fisso dell'utente amministratore, in questo modo figurerà sempre come autore del commento (Figura 3) Figura 3 (cliccare sull'immagine per una risoluzione grafica maggiore) Come quarto parametro passiamo il valore fisso "user" (Figura 4) Figura 4 (cliccare sull'immagine per una risoluzione grafica maggiore) Come quinto parametro passiamo il valore fisso "true" per mandare la mail automatica di avviso al contatto con utenza portale attiva collegato al ticket (Figura 5) Figura 5 (cliccare sull'immagine per una risoluzione grafica maggiore) Il risultato finale sarà come quello mostrato in Figura 6 Figura 6 (cliccare sull'immagine per una risoluzione grafica maggiore) La mail automatica inviata al contatto con utenza portale attiva collegato al ticket sarà come quello mostrato in Figura 7 Figura 7 (cliccare sull'immagine per una risoluzione grafica maggiore) 13.3 SDK Action: Update ModLight row Questa funzione SDK permette di eseguire un aggiornamento delle righe esistenti di un campo tabella presente su un determinato modulo. Come primo parametro va passato l'ID della riga, ossia il parametro chiave che permette di identificare in maniera univoca una specifica riga esistente nel campo tabella. Come secondo parametro va passato il nome a Data Base della colonna del campo tabella che si vuole aggiornare. Come ultimo parametro va passato il valore che si vuole inserire all'interno della colonna definita come secondo parametro. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato l'esempio di utilizzo della funzione SDK Update ModLight row() per aggiornare in automatico a "si" il valore della colonna "Processata" per tutte le righe esistenti del campo tabella "Operazioni" presente nel modulo Commessa. (Figura 1) Figura 1 All'interno di un'Action Task procediamo con la configurazione di un'azione di tipo cicla righe sul campo tabella "Operazioni" e per ogni riga "Funzioni SDK" nella quale richiamiamo l'SDK Update ModLight row(). (Figura 2) Figura 2 Come primo parametro inseriamo il valore corrente della variabile "ID" del campo tabella "Operazioni" (sul quale stiamo eseguendo il ciclo), quindi nel nostro caso "$28-ml3::crmid:curr". (Figura 3) NOTA BENE: si tratta di un dato che non è presente tra le colonne della tabella ma che viene proposto in automatico come variabile all'interno del processo Come secondo parametro inseriamo il nome a Data Base della colonna "Processata", quindi nel nostro caso "f8". (Figura 3) Come ultimo parametro inseriamo il valore "si" che in questo caso, essendo la colonna "Processata" di tipologia checkbox, a Data Base corrisponde al valore "1". (Figura 3) Figura 3 13.4 SDK Action: Update DynaForm table row Questa funzione SDK permette di eseguire un aggiornamento delle righe esistenti di un campo tabella presente su una form dinamica di un process helper. Come primo parametro va passato il metaid, ossia l'ID che identifica univocamente una specifica form dinamica all'interno del processo. NOTA BENE: va passato il numero senza il prefisso DF, quindi se ad esempio l'ID è DF9 va inserito solamente 9. Come secondo parametro va passato il nome a Data Base del campo tabella presente sulla form dinamica del process helper. Come terzo parametro va passata la sequenza della tabella, ossia il parametro chiave che viene utilizzato per identificare le righe da aggiornare. Come quarto parametro va passato il nome a Data Base della colonna del campo tabella che si vuole aggiornare. Come ultima parametro  va passato il valore che si vuole inserire all'interno della colonna definita come quarto parametro. ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato l'esempio di utilizzo della funzione SDK Update DynaForm table row() per aggiornare in automatico a "si" il valore della colonna "Processata" pet tutte le righe del campo tabella "Operazioni" presente su una form dinamica. (Figura 1) Figura 1 All'interno di un'Action Task procediamo con la configurazione di un'azione di tipo cicla righe sul campo tabella "Operazioni" e per ogni riga "Funzioni SDK" nella quale richiamiamo l'SDK Update DynaForm table row(). (Figura 2) Figura 2 Come primo parametro inseriamo il il metaid, ossia l'ID che identifica univocamente una specifica form dinamica all'interno del processo senza il prefisso DF, quindi nel nostro caso 3. (Figura 3) Come secondo parametro inseriamo il nome a Data Base del campo tabella presente sulla form dinamica del process helper, quindi nel nostro caso "vcf_8". (Figura 3) Come terzo parametro inseriamo il valore corrente della variabile "Sequenza", quindi nel nostro caso "$DF3-vcf_8::index:curr". (Figura 3) Come quarto parametro inseriamo il nome a Data Base della colonna "Processata", quindi nel nostro caso "vcf_10". (Figura 3) Come ultimo parametro inseriamo il valore "si" che in questo caso, essendo la colonna "Processata" di tipologia checkbox, a Data Base corrisponde al valore "1". (Figura 3) Figura 3 13.5 SDK Action: Gestisci Ricezione Newsletter Questa funzione SDK permette di abilitare o disabilitare la ricezione delle newsletter sull'indirizzo mail associato ad un Lead, Contatto o Azienza pilotando il campo checkbox "Ricevi Newsletter". Come primo parametro, andrà passato il crmid del record sul quale si vuole aggiornare il valore del campo "Ricevi Newsletter". Come secondo parametro andrà passato il valore fisso "lock" nel caso in cui si voglia impostare a "no" il campo "Ricevi Newsletter", invece per impostarlo a "si" andrà passato il valore fisso "unlock". ESEMPIO DI UTILIZZO Per comprenderne al meglio il funzionamento, qui di seguito viene riportato l'esempio di utilizzo della funzione SDK Set receiving newsletter per disabilitare la ricezione delle newsletter per un Lead. Come primo parametro passiamo il crmid del lead sul quale si vuole aggiornare il valore del campo "Ricevi Newsletter", nel nostro caso $1-crmid (Figura 1) Come secondo parametro passiamo il valore fisso "lock" (Figura 1) Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) 14 SDK di Processo Task Condition Standard: Descrizione e Utilizzo 14.1 SDK Task Condition: Utente Corrente: Nome Utente Questa funzione SDK permette di eseguire un controllo sull'utente che ha fatto scatenare il processo, ovvero l'utente che ha eseguito il salvataggio. Nello specifico, permette di controllare se tale utente corrisponde ad un utente specificato staticamente all'interno della funzione (Figura 1) Per approfondimenti sulla logica di funzionamento di queste tipologie di SDK consultare il capitolo 11.3 del manuale dei processi. Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) 14.2 SDK Task Condition: Project Task usage % Questa funzione SDK permette di eseguire un confronto tra un valore statico (passato alla funzione) e un valore in percentuale calcolato in base al contenuto del campo "Erogazione servizio" del modulo Operazioni. Nel caso in cui nell'operazione sia stata selezionata la voce "Pacchetto", il valore in percentuale verrà calcolato basandosi sui campi "Ore usate" e "Ore pacchetto". Invece nel caso in cui nell'operazione sia stata selezionata la voce "Progetto", il valore in percentuale verrà calcolato basandosi sui campi "Ore usate" e "Ore previste". Per approfondimenti sulla logica di funzionamento di queste tipologie di SDK consultare il capitolo 11.3 del manuale dei processi. Per comprenderne al meglio il funzionamento, in Figura 1 viene mostrata la configurazione di un processo che si scatena nel caso in cui la percentuale di ore usate in un operazione con "Erogazione servizio" = "Pacchetto" è maggiore del 70%. Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore) 15 Sottoprocessi 15.1 Sottoprocessi: Configurazione e Modalità di Utilizzo I sottoprocessi sono delle tipologie particolari di processi che possono essere richiamate all’interno di altri processi definiti “padre”. Per procedere con la loro configurazione, si deve creare un processo inserendo nella condizione iniziale la voce “al lancio del sottoprocesso” (Figura 1) Nel campo “Entità” non sarà possibile selezionare alcun modulo, in quanto, verrà ereditata l’istanza definita nel processo “padre”. Figura 1 Per poter configurare il resto delle Task/Action Task definite nel diagramma di flusso (e quindi poter usufruire di tutti i dati del processo "padre"), si deve prima richiamare il sottoprocesso all'interno del processo "padre" tramite la seguente procedura: 1) Definire una Task all'interno del diagramma di flusso del processo padre (Figura 2) Figura 2 2) Selezionare la voce "Sub process (collapsed)" tra le opzioni disponibili cliccando sul simbolo della chiave inglese (Figura 3 e 4) Figura 3 Figura 4 NOTA BENE: se si configura un sottoprocesso in una versione PRECEDENTE alla 24.08, dopo ogni Task di tipo "Sub process (collapsed)" configurata nel processo "padre", si deve inserire una Task successiva che permetta al processo "padre "di interrompere il proprio flusso fino a quando il sottoprocesso richiamato non avrà terminato la sua esecuzione (Figura 5) Invece dalla versione 24.08 in poi il sistema gestirà in automatico l'interruzione e la ripresa del flusso del processo "padre". Figura 5 3) Accedere all'interno della Task in modalità di configurazione e selezionare il sottoprocesso da coinvolgere (Figura 6) NOTA BENE: anche se nelle versioni precedenti alla 24.08 in questa schermata saranno visibili anche i processi "padri", se selezionati non produrranno alcun risultato, questo perché posso essere selezionati solamente i sottoprocessi. Figura 6 A questo punto, all'interno del sottoprocesso sarà possibile sfruttare tutti i dati delle istanze dei moduli coinvolte nel processo "padre" (Figura 7) Figura 7 Per una limitazione tecnica strutturale del sistema NON è possibile richiamare più volte lo stesso sottoprocesso all'interno di un processo "padre". E' comunque possibile aggirare questa limitazione andando a comporre un diagramma di flusso che permetta al processo di tornare indietro e riseguire la Task di tipo "Sub process (collapsed)" in cui viene richiamato il sottoprocesso coinvolto (Figura 8). Figura 8  15.2 Esempio: Configurazione Processo Gestione Opportunità Processo Principale: Processo Gestione Opportunità La task SubProcess viene utilizzata per richiamare altri processi (sottoprocessi) e quindi semplificare la logica del processo principale. Nel caso proposto di seguito sono presenti 2 SottoProcessi: 1° Invia una mail di riepilogo all’assegnatario e crea eventi di remind assegnati allo stesso utente. 2° Crea un Preventivo precompilato (solo se vere le condizioni precedenti) e lo invia tramite mail aggiornando anche lo stato dell’Opportunità. Nello screenshot è rappresentato il processo configurato. Il seguente processo viene attivato alla creazione di una nuova Opportunità e segue il flusso per una possibile riassegnazione ed aggiornamento stadio di vendita. Per attivarlo si mette la spunta su “attivo” una volta terminato il diagramma e la configurazione Qui a fianco è stata compilata la prima task, la quale rappresenta la condizione iniziale per avviare il processo. Pertanto si seleziona l’entità collegata “Opportunità” e su Quando eseguire il controllo “alla creazione”. Viene poi specificato un Gruppo di condizioni per avviare effettivamente il processo, in questo caso che lo Stadio di Vendita sia differente da quelli indicati (“In Prospettiva”, “Qualificazione”, “In preventivazione”) Questa task rappresenta il richiamo ad un altro processo (sottoprocesso), il quale al suo interno esegue il proprio flusso di esecuzione. Pertanto occorre scegliere quale richiamare tra l’elenco proposto. Al suo internò sarà presente una Task di invio mail per informare l’apertura di una nuova Opportunità e la creazione di 2 remind, uno a 5 giorni dalla scadenza, l’altro a 3. Questa task rappresenta un controllo sullo stato dell’opportunità (Stadio di vendita). Si definiscono quindi le casistiche possibili dei valori da gestire. In questo caso si verifica se è cambiato il valore di questo campo in uno di questi: In Prospettiva Da Analizzare Analisi di Percezione Proposta /Preventivo Prezzo Trattativa/Revisione Proposto il valore Potere decisionale OPPURE Chiuso VINTO Chiuso PERSO Questa task rappresenta un Exclusive Gateway, il quale definisce i flussi possibili in base alle precedenti condizioni settate. In questo caso se lo Stadio di vendita è uno tra quelli descritti precedentemente (In Prospettiva, Da Analizzare, Analisi di Percezione, Proposta/Preventivo Prezzo, Trattativa/Revisione, Proposto il valore, Potere decisionale) prosegue alla task successiva denominata “Richiesta cambio assegnatario”. Altrimenti se uguale a “Chiuso VINTO” o “Chiuso PERSO” prosegue l’esecuzione verso la Task “Invio mail Riepilogo”. Questa task sfrutta il cosiddetto “ProcessHelper” che si interfaccia con l’utente e richiede, come già definito, un suo intervento manuale. Viene flaggato il box “Mostra popup nell’entità collegata” per far comparire una finestra (form dinamica) con un insieme di dati in sola lettura come riepilogo e un campo utente da cui è possibile selezionare il nuovo assegnatario e un campo di tipo Pulsante per modificare il valore della picklist “Conferma”. Occorre poi confermare per procedere Questa Task verifica i dati del ProcessHelper. Come già accennato, attraverso una form dinamica vengono mostrati dei campi di riepilogo e una picklist di conferma (SI/NO) per la nuova ri-assegnazione. Pertanto, si pone il controllo sul campo conferma della Fom Dinamica per verificare che sia stato settato a “SI’ OPPURE “NO”. In questo punto, Exclusive Gateway, assegniamo le strade precedentemente configurate in base alla risposta data nella Form Dinamica. Se l’utente ha confermato (SI) procede con la riassegnazione dell’Opportunità, altrimenti (NO) si procede direttamente al controllo Stato di quest’ultima (Stadio di Vendita). Questa task esegue un’azione di aggiornamento. Il precedente utente selezionato tramite form dinamica viene ora settato tra gli attributi dell’opportunità in questione. Si aggiunge pertanto una NUOVA AZIONE - Aggiorna entità. Si seleziona l’entità Opportunità e si modifica il campo Assegnato a prendendo il riferimento del campo presente in Form Dinamica, nel nostro caso “Nuovo Assegnatario”. Questa task rappresenta l’invio mail di informazione al nuovo assegnatario dell’Opportunità. Questo riceverà quindi un piccolo riepilogo dei dati relativi quest’ultima. Vengono quindi compilati i principali campi mittente, destinatario, oggetto e corpo, necessari per l’invio mail. Questa task rappresenta un secondo controllo sullo stato dell’opportunità (Stadio di vendita). Si definiscono quindi le casistiche possibili dei valori da gestire. In questo caso si verifica se lo stadio di vendita è uguale a “Proposta Preventivo/Prezzo” o meno. Se uguale a questo prosegue con il richiamo al SottoProcesso “Preventivo Precompilato”, altrimenti prosegue direttamente alla Task “Invio mail Riepilogo”. Questa task rappresenta un ulteriore Exclusive Gateway, il quale definisce i flussi possibili in base alle precedenti condizioni settate. In questo caso se lo Stadio di vendita è “Proposta Preventivo/Prezzo” prosegue alla task successiva come accennato, ovvero al richiamo del sottoprocesso “Preventivo Precompilato”. Altrimenti prosegue con l’invio mail. Questa task rappresenta un richiamo ad un altro sottoprocesso, il quale creerà un preventivo e quando passato in stato “Revisionato”, invierà l’email di riepilogo ed aggiornerà lo Stadio di Vendita dell’Opportunità Questa task esegue un’azione di controllo sullo Stadio di Vendita dell’Opportunità, per verificare la completa ed intera esecuzione del SottoProcesso. Se questo è uguale a “Trattativa/Revisione”, il flusso prosegue con la Task successiva di invio mail Riepilogo finale. Questa task rappresenta l’ultima azione, ovvero un invio mail di riepilogo per informare l’assegnatario riguardo i dati relativi l’Opportunità. Pertanto si clicca su NUOVA AZIONE - Invio mail e si inseriscono i campi necessari. Dopo questa Task si giunge al termine del processo, quindi verso l’End Event. Come accennato, il processo termina la sua esecuzione in questo nodo, ovvero l’End Event. Viene collegata l’entità “Opportunità” e settato lo stato a “Terminato”. SottoProcesso: scadenza opportunità La Task rappresentata risulta essere la Task iniziale per il lancio del SottoProcesso. Infatti non viene selezionata nessuna entità e su “Quando eseguire il controllo” si seleziona “al lancio del sottoprocesso”. In questa Task viene configurato l’invio mail per l’assegnatario dell’Opportunità. Si configura quindi una NUOVA AZIONE - Invio mail. Si inseriscono le principali informazioni (mittente, destinatario, oggetto, corpo,…). Nella task descritta qui a fianco vediamo la creazione di un promemoria, ovvero di un Evento a calendario in vista della Scadenza prevista. Infatti, questo viene pianificato a 5 giorni dalla “Data Chiusura Attesa” inserita nell’Opportunità. Pertanto si compilano i diversi campi come desiderato e si sottraggono 5 giorni dalla data indicata. In questa task abbiamo la creazione di un secondo promemoria, ovvero di un Evento a calendario in vista della Scadenza effettiva.Questo, a differenza del primo, viene pianificato a 3 giorni dalla “Data Chiusura effettiva” inserita nell’ Opportunità. Pertanto si compilano i diversi campi come desiderato e si sottraggono 3 giorni dalla data indicata. SottoProcesso: preventivo pre-compilato Come nel precedente Sottoprocesso, anche in questo caso troviamo la Task iniziale per l’avvio. Infatti non viene selezionata nessuna entità e su “Quando eseguire il controllo” si seleziona “al lancio del sottoprocesso”. In questa Task viene configurata una NUOVA AZIONE - Crea Entità, selezionando il modulo “Preventivi”, così da crearne uno precompilato. Si inserisce il titolo dell’azione, i vari campi relazionando anche l’Opportunità in questione e settando la data di fine validità tra 30 giorni. A questo punto il Sottoprocesso blocca il flusso di esecuzione sulla Task descritta in seguito. Si attende infatti che lo Stadio Preventivo dell’entità precedentemente creata (in stato “creato”) passi in “Revisionato”.Solo quando sarà vera questa condizione il processo andrà avanti. Una volta settato il valore “Revisionato” come Stadio Preventivo il processo prosegue ed invia i dettagli di questo via mail all’indirizzo dell’entità relazionata (Azienda o Contatto) e all’assegnatario in copia. Una volta creato il Preventivo, controllato che sia cambiato lo Stato in “Revisionato” ed inviato la mail, aggiorniamo lo Stadio di vendita dell’Opportunità in “Trattativa/Revisione”. A questo punto termina l’esecuzione del Sottoprocesso. 15.3 Esempio: Attivazione Processo Gestione Opportunità ATTIVAZIONE PROCESSO A questo punto abbiamo terminato la configurazione del processo e dei relativi sottoprocessi. Pertanto procediamo con la verifica del corretto funzionamento. Entriamo quindi in creazione di una Nuova Opportunità. In questo caso settiamo come Stadio di vendita “Aperta”. Una volta salvata l’Opportunità, l’assegnatario riceverà una mail di riepilogo dei dati. Inoltre, saranno già presenti 2 eventi relazionati, ovvero le scadenze, una a 5 giorni dalla Data chiusura attesa e l’altra a 3 giorni dalla Data fine effettiva. A questo punto il processo si è fermato ed attende che lo Stadio di vendita cambi valore in uno di quelli precedentemente configurati. In questo caso settiamo il valore “Proposta Preventivo/Prezzo”. Una volta salvato, comparirà una popup all’assegnatario dell’Opportunità con il riepilogo dei dati in sola lettura e la possibilità di riassegnare questa ad un altro utente. Una volta selezionato l’utente desiderato seleziona il valore “SI” dalla picklist (è possibile cliccare il pulsante “CONFERMA/ANNULLA ASSEGNAZIONE” per modificare il valore della stessa picklist in SI/NO) e procede cliccando su SALVA. Una volta confermato (selezionato il valore “SI” in popup, viene aggiornato l’assegnatario dell’Opportunità e questo riceverà una mail con i dati e conferma di presa in carico. Dalle relazioni possiamo già vedere che è stata relazionata la mail ed è stato creato il preventivo, in quanto lo Stadio di vendita era “Proposta/Preventivo Prezzo”. Analizzando la relazione possiamo vedere i dettagli del Preventivo creato. A questo punto, possiamo entrare nel dettaglio, modificare i dati, inserire prodotti e cambiare lo stadio Preventivo in “Revisionato”. Il processo prosegue il flusso ed invia la mail all’assegnatario contenente i dati del Preventivo stesso. Inoltre, lo Stadio di vendita dell’Opportunità viene settato in “Trattativa/Revisione”. A questo punto, l’assegnatario riceve una mail di riepilogo finale con tutti i dati dell’Opportunità. Dalla tab “Grafico Processo” possiamo vedere che il processo ha terminato il flusso di esecuzione. 16 Processi Tool 16.1 Processi Tool: Configurazione e Modalità di Utilizzo Dalla versione 26.07 è stata introdotta una nuova categoria di processi denominata "Tool". Sono stati implementati con l'intenzione di replicare i vantaggi che offrono tutt'ora le funzioni in termini di programmazione lato codice, permettendo di abbattere il concetto di "ridondanza" a cui spesso si va incontro nell'utilizzo di processi Standard. Infatti, questa tipologia di processi possono essere richiamati all'interno di più processi Standard differenti oppure più volte all'interno dello stesso processo Standard, di fatto permettendo di riutilizzare delle porzioni esistenti di processo. Inoltre è possibile richiamare un processo Tool all'interno di un altro processo Tool senza particolari limitazioni. Per motivi di gestione tecnico-funzionale, in un processo Tool non possono essere configurate delle condizioni legate alla creazione o modifica di un record, ma nel caso in cui si volesse utilizzare un processo Tool come se fosse un processo Standard basterà configurare un processo Standard (nel quale configurare le condizioni di partenza del processo) e richiamare subito dopo il processo Tool interessato. Per procedere con la configurazione di un processo Tool, si deve selezionare la voce dedicata "alla chiamata del tool" all'interno della prima Task del diagramma di flusso.  Alla selezione di tale voce la picklist "Entità" verrà impostata in sola lettura, nel caso in cui ci fosse un'entità selezionata il campo verrà anche svuotato. Inoltre, nella sezione sottostante, verrà mostrata una tabella nella quale poter definire i parametri che si vogliono prevedere come input al richiamo del processo Tool. (Figura 1) Figura 1 Per ogni parametro (riga della tabella) dovranno essere compilati i seguenti campi: - Nome parametro -> rappresenta il nome assegnato al parametro e che verrà visualizzato all'interno del processo Standard - Tipo -> rappresenta la tipologia di parametro che il processo Tool si aspetterà di ricevere e può essere di due tipologie: "string": nel caso in cui il parametro sia una stringa "entità": nel caso in cui il parametro sia un'entità, in tal caso dovrà essere necessariamente definito a quale modulo si riferisce nel campo successivo - Entità -> nel caso di Tipologia = Entità dovrà essere compilato con il modulo previsto - Obbligatorio -> permette di rendere obbligatoria la compilazione del parametro in fase di richiamo del processo Tool - Descrizione -> rappresentano le indicazioni utili alla compilazione del parametro nella fase di richiamo del processo Tool Una volta attivato il processo Tool sarà selezionabile all'interno dell'azione BPMN dedicata "Chiama processo tool". (Figura 2) Figura 2 Tool MCP Una volta attivato il processo verrà automaticamente reso disponibile un nuovo tool nei server MCP. Questo permette di poter avviare il processo come fosse un tool di un server MCP. Per poterlo utilizzare il tool dovrà essere attivato nel server, poi va attesa o forzata la sincronizzazione nel client ed eventualmente attivato negli agenti che utilizzano il client MCP.