Torna al changelog

• Miglioramento

  Esito dei task automatici ovunque

  L'esito di un task concluso compare ora per ogni tipo di task, non solo per quelli manuali: nel dettaglio del task, nella lista dei task della pratica, nel Kanban e nella pagina Task, dove un'etichetta accanto allo stato mostra l'esito (accorciato se lungo, per intero passando col mouse). Per un task Jev rimasto sotto la soglia di confidenza, il dettaglio avverte che il valore è l'esito di incertezza.

• Miglioramento

  «Esecuzione AI» che si legge

  Il dettaglio di un task AI mostra modello, token, durata della chiamata, Data Shield e minimizzazione dei dati; per un task Jev una tabella con, per ogni domanda, la risposta, la confidenza con la soglia che l'ha decisa e il campo in cui è stata scritta; per un task LLM i campi scritti e se la risposta ha impostato l'esito. Il testo del prompt e la risposta grezza non compaiono mai qui: gli amministratori li trovano nel Registro delle chiamate AI, con un collegamento già filtrato su quel task. Le esecuzioni precedenti a questa versione mostrano i dati di base con una nota.

• Design

  «Assegnato a» uguale ovunque

  Dettaglio del task, lista della pratica, Kanban e pagina Task usano la stessa regola del flussogramma: la persona assegnata o «Da assegnare» per i task manuali, «AI» per i task AI e Jev, «Sistema» per script, attese e sotto-processi, «Connettore» per le integrazioni, «Evento» per i task evento. Nessun utente fittizio viene creato: è un'etichetta che descrive chi svolge il lavoro.

• Novità

  Esiti Jev proposti alle regole

  Quando una domanda Jev è marcata come esito, il task tiene aggiornato da solo l'elenco dei propri esiti — le opzioni della domanda più l'esito di incertezza dell'organizzazione — e il selettore delle regole di uscita li propone già pronti. Se gli esiti del task erano stati scritti a mano e non corrispondono più, il Designer lo segnala e offre di sostituirli con un clic; chi salva il flusso via API o lo importa ottiene lo stesso allineamento, con un avviso quando gli esiti scritti a mano restano diversi.

• Design

  Codice di fase generato: mai più un errore interno

  Quando lasci vuoto il campo Codice di una fase, FlowSharp lo deriva dal nome. Con un nome molto lungo il codice generato ora viene sempre accorciato a 100 caratteri e, se due fasi finiscono con lo stesso codice accorciato, una delle due riceve un numero in coda — prima il salvataggio poteva fallire con un errore generico. Un Codice scritto a mano non viene mai toccato da questa regola.

• Miglioramento

  Data Schema: le regole non supportate vengono rifiutate, non perse in silenzio

  Il Data Schema in modalità JSON avanzata conserva tipo, descrizione e struttura dei campi (il formato solo per i campi Documento), ma non regole come «valore minimo», «lunghezza massima» o un elenco di valori ammessi: non c'è un posto dove tenerle. Scriverle prima veniva accettato e poi le regole sparivano senza preavviso alla lettura successiva; ora il salvataggio le rifiuta subito, indicando esattamente quali. Il pulsante «Genera con AI» chiede già uno schema conforme a queste regole: se il modello ne propone comunque una fuori elenco, FlowSharp la toglie da solo prima di mostrarti lo schema, con una nota che spiega cosa è stato tolto — non un rifiuto, uno schema già pronto da salvare. Un flusso importato da file, URL o link condiviso con queste stesse regole nel suo Data Schema non viene invece bloccato: FlowSharp le rimuove e te lo segnala con un avviso, così il flusso importato nasce già pronto.

• Integrazione

  Conflitto sui dati: il rimedio suggerito adesso funziona

  Quando una modifica ai dati di una pratica confligge con un campo già scritto in modo diverso, il messaggio d'errore indicava di «svuotare il campo» prima di riscriverlo — ma non bastava. Ora indica il passaggio che funziona davvero: azzerare il campo, poi scrivere la nuova struttura in un secondo passaggio. In più, una modifica che non cambia realmente nulla non incrementa più il numero di revisione della pratica né lascia una riga falsa nello storico.

• Miglioramento

  Script più onesti quando l'argomento è sbagliato

  Uno script che scrive sui dati della pratica con setData() deve passare due valori — il campo e il valore da scrivere. Se al posto del campo arriva un oggetto, prima il task si concludeva come riuscito senza scrivere nulla e con una riga di storico fuorviante; ora il task fallisce subito, con una causa chiara, senza scrivere né lasciare tracce false.

• Novità

  L'origine di una pratica, sempre visibile

  Il dettaglio di una pratica dice ora come è nata — creazione manuale, API, un assistente MCP, il Flow Agent, un evento, un sotto-processo di un'altra pratica, un avvio pianificato non ancora partito o dati di esempio — nella card «Origine» e nell'anteprima rapida. Un avvio in attesa di conferma (per esempio da un assistente MCP) mostra il canale reale, non «Pianificato». Prima quella card si basava su un dato che l'API non restituisce più da tempo, quindi non compariva quasi mai, e ogni pratica avviata da un'integrazione veniva mostrata come «creazione manuale».

• Miglioramento

  «Archivia» dice cosa resta

  Archiviare un flusso che ha anche una Bozza aperta lo dice nel dialogo di conferma — la Bozza non viene toccata — e se ci sono pratiche ancora in corso su quella versione ne indica il numero, spiegando che continueranno a lavorare lì. Il messaggio resta quello semplice di sempre quando nessuna delle due cose si applica.

• Miglioramento

  Cartelle con soli flussi disabilitati o archiviati

  Una cartella che contiene solo flussi disabilitati o solo archiviati non appare più vuota per poi fallire quando provi a eliminarla: FlowSharp dice quanti ce ne sono e offre di mostrarli, così puoi spostarli — o, per gli archiviati, ripristinarli e poi spostarli, oppure eliminarli definitivamente — prima di eliminare la cartella.

• Design

  Nomi dei tipi di task coerenti ovunque

  Il dettaglio di un task Integrazione ora si intitola «Integrazione», non più «Webhook». Il report d'importazione di una mappa di processo usa gli stessi nomi attuali (Integrazione, Sub-flow) invece dei vecchi nomi tecnici. Lo storico di una pratica mostra ora il verbo giusto per lo stato del task — completato, saltato o fallito, con un'icona dedicata per i saltati — invece di dire sempre «completato»; e la riga «Item creato» nomina il canale reale di avvio invece di dire sempre «creazione manuale».

• Design

  Report d'importazione delle mappe più preciso

  Quando la busta di una mappa dichiara un processo che nessun nodo usa, il report d'importazione dice ora quale — non solo il suo riferimento interno — e il conteggio dei processi mostrato prima di importare non lo conta più, coerente con l'elenco che vedi dopo. Una dipendenza verso un sotto-processo esterno non risolta nomina anche il processo che la contiene, non solo la fase; e i file esportati non mostrano più etichette interne come «fase s1» al posto del nome vero della fase.