Come costruire un'app web per pipeline di approvazione dei contenuti

Definire il problema e gli utenti

Prima di progettare schermate o scegliere un database, chiarisci cosa stai costruendo: un sistema che porta i contenuti da “qualcuno l'ha iniziato” a “è approvato e pubblicato”, con tutti che sanno quale sia il passo successivo.

Cosa significa una “pipeline di approvazione dei contenuti” (in parole semplici)

Una pipeline di approvazione dei contenuti è l'insieme di passaggi che un contenuto deve attraversare—bozza, revisione, approvazione e pubblicazione—più le regole su chi può farlo avanzare. Pensala come una checklist condivisa con semafori: il contenuto ha uno stato corrente, un prossimo passo e una persona responsabile.

L'obiettivo non è aggiungere burocrazia. È sostituire email disperse, thread di chat e file "latest_final_v7" con un unico posto dove la versione corrente e la decisione sono evidenti.

Utenti tipici e cosa si aspettano

La maggior parte dei team rientra in pochi ruoli (la tua app può implementare questi come ruoli, gruppi o permessi):

• Writers / creators: hanno bisogno di un modo semplice per scrivere, allegare asset, rispondere ai feedback e sapere esattamente cosa cambiare.
• Reviewers (editor, legal, brand, SEO): hanno bisogno di commentare, richiedere modifiche e vedere cosa è cambiato dall'ultima volta.
• Approvers: hanno bisogno di un flusso di decisione rapido: approva, rifiuta o rimanda—spesso con note obbligatorie.
• Publishers: necessitano di un passaggio pulito alla pubblicazione, con la certezza che la versione giusta sia stata approvata.
• Admins: devono configurare regole di workflow, gestire utenti e auditare ciò che è successo.

Anche se l'organigramma è complesso, la tua app dovrebbe mantenere l'esperienza quotidiana semplice: “Cosa mi aspetta?” e “Cosa devo fare dopo?”

Tipi di contenuto comuni da prevedere

Un'app pipeline spesso parte con un tipo di contenuto e poi si espande. Tipi comuni includono:

• Articles and blog posts (contenuti long-form con intestazioni, link e metadata)
• Product pages (campi strutturati come feature, pricing, note di compliance)
• Social posts and email copy (short-form con varianti)
• Assets (immagini, PDF, video) che richiedono approvazione insieme al testo

Questo è importante perché il workflow può essere lo stesso, ma i dati e l'interfaccia cambiano. Per esempio, le pagine prodotto possono richiedere revisioni a livello di campo, mentre gli articoli richiedono testo ricco e commenti editoriali.

Come misurare il successo

Definisci il successo in risultati tangibili per il team:

• Meno colli di bottiglia: meno tempo a chiedersi “chi ce l'ha?”
• Ownership chiara: ogni elemento ha un assegnatario corrente o un ruolo responsabile
• Tracciabilità: puoi rispondere a “chi ha approvato cosa, quando e perché?” senza cercare tra i messaggi

Se puoi misurarlo, ancora meglio—tempo medio da bozza ad approvazione, numero di cicli di revisione e revisioni in ritardo. Questi indicatori guideranno il design del workflow e i report.

Progettare stati del workflow e transizioni

Un'app di approvazione dei contenuti diventa facile da usare quando tutti rispondono a due domande a colpo d'occhio: “In quale stato è?” e “Cosa può succedere dopo?” Inizia definendo un piccolo set di stati chiari e mutuamente esclusivi, quindi decidi le regole che muovono il contenuto tra di essi.

Parti da un modello di stato semplice e riconoscibile

Un baseline comune è:

Draft → Review → Revisions → Approved → Scheduled/Published

Usa nomi user-friendly (“Needs changes” spesso suona meglio di “Revisions”) e assicurati che ogni stato implichi chi dovrebbe agire dopo.

Approvazioni a step singolo vs multi-step

Decidi se “Approved” è una singola decisione o il risultato di più controlli.

Se ti servono approvazioni multi-step (per esempio Legal poi Brand), modellalo esplicitamente:

• Opzione A: Stati separati (es. “Legal Review” → “Brand Review”)
• Opzione B: Uno stato “Review” con approvazioni richieste (es. Legal = approved AND Brand = approved)

L'opzione B mantiene la lista degli stati più corta, ma dovrai mostrare chiaramente il progresso (es. “2 di 3 revisori hanno approvato”).

Regole di transizione: cosa è permesso e quando

Metti per iscritto le mosse consentite e applicale in modo coerente:

• Quando un autore può inviare Draft → Review?
• Chi può mandare il contenuto in Revisions?
• I revisori possono modificare o solo commentare?
• Un contenuto Approved può essere cambiato senza nuova revisione?

Decidi anche se le transizioni “all'indietro” mantengono le approvazioni o le azzerano (la maggior parte dei team azzera le approvazioni quando il contenuto cambia).

Revisioni parallele vs sequenziali

Le revisioni parallele sono più veloci: più revisori possono approvare contemporaneamente e il sistema decide se serve tutti i revisori o solo uno.

Le revisioni sequenziali sono più rigorose: il contenuto deve passare step-by-step (utile per compliance). Se supporti entrambi i modelli, rendilo impostabile per workflow così i team scelgono ciò che si adatta al loro processo.

Pianificare ruoli, permessi e ownership

Un workflow di approvazione fallisce rapidamente quando le persone non sanno cosa possono fare—o chi è responsabile quando qualcosa si blocca. Prima di costruire funzionalità, definisci ruoli chiari, cosa può fare ciascun ruolo in ogni fase e come cambia l'ownership man mano che il contenuto avanza.

Parti da accesso basato sui ruoli

Elenca le azioni che la tua app supporta (create, edit, comment, request changes, approve, publish, archive) e mappale sui ruoli. Un baseline semplice potrebbe essere:

• Author: creare e modificare bozze, rispondere ai feedback
• Reviewer: commentare, richiedere modifiche, approvare entro il proprio ambito
• Approver/Lead: approvazione finale, override quando necessario
• Publisher: programmare/pubblicare e gestire aggiornamenti post-pubblicazione

Tieni “publish” separato da “approve” se vuoi un controllo di sicurezza in più.

Permessi granulari ma prevedibili

La maggior parte dei team ha bisogno di regole che variano per contesto:

• Team o progetto: il Marketing non può approvare i contenuti Legal
• Tipo di contenuto: blog post vs comunicati stampa vs pagine prodotto
• Fase: editing consentito in “Draft”, sola lettura in “In Review”, modifiche limitate in “Approved”

Punta a un modello di permessi che sia facile da spiegare in una frase, tipo: “I permessi sono assegnati per progetto e applicati per fase del workflow.” Se gli utenti devono fare un training per capirlo, è troppo complesso.

Definire ownership e deleghe

Per ogni elemento, memorizza:

• Owner (chi lo guida)
• Assignee corrente (chi deve agire dopo)
• Approver richiesti (individui o gruppi)

Aggiungi deleghe così le approvazioni non si bloccano per ferie: consentire approvatori di backup, passaggi temporanei di ruolo e una regola “auto-reassign dopo X giorni”.

Controlli admin per le eccezioni

Gli admin hanno bisogno di strumenti per far girare il lavoro senza rompere la fiducia: gestire ruoli, vedere i controlli di permesso, risolvere conflitti (es. due approvatori in disaccordo) e riassegnare elementi con una motivazione obbligatoria. Abbina questo a un registro audit (coperto più avanti) così le override sono trasparenti.

Modellare i dati (entità e relazioni)

Il tuo modello dati è il punto in cui una pipeline di approvazione resta flessibile o diventa difficile da cambiare. Punta a una struttura che supporti versioning, discussioni e tracciabilità senza costringere ogni futura funzionalità in un'unica tabella “content”.

Entità core con cui partire

Un baseline pratico include:

• ContentItem: il “contenitore” (es. Article, Landing Page, Press Release). Memorizza metadati stabili come id, type, owner_id, status corrente e timestamp.
• Version: lo snapshot editabile del contenuto in un momento dato (es. title, body, tags, campi strutturati). Un ContentItem ha molte Version.
• Comment: discussione legata a un ContentItem o a una specifica Version (spesso meglio collegarla alla Version per evitare confusione). Un ContentItem ha molti Comment.
• ReviewRequest: richiesta di revisione per una specifica Version, assegnata a uno o più revisori con date di scadenza e istruzioni.
• Approval: decisione di un singolo revisore su una ReviewRequest (approve/reject/request changes), idealmente con una nota obbligatoria.

Relazioni che ti salvano la vita

Modella le relazioni in modo esplicito così i report sono semplici in seguito:

• ContentItem 1→N Version (e un puntatore tipo current_version_id per letture veloci)
• Version 1→N Comment
• Version 1→N ReviewRequest
• ReviewRequest 1→N Approval (uno per revisore)

Se supporti file, aggiungi Attachment collegato a una Version (o a un Comment) così gli asset seguono la revisione esatta.

Stati: enum vs tabella configurabile

Se il tuo workflow è fisso (Draft → In Review → Approved → Published), un enum è semplice e veloce.

Se i clienti hanno bisogno di stati personalizzati (“Legal Review”, “SEO Check”), usa tabelle configurabili come WorkflowState e WorkflowTransition, e memorizza lo stato corrente come chiave esterna. Questo costa di più all'inizio ma evita un deploy di codice per ogni cambiamento.

Campi strutturati e riferimenti

Anche contenuti semplici beneficiano di struttura prevedibile: title, body, summary, tags, più un opzionale JSON per campi specifici per tipo. Aggiungi riferimenti (es. fonti, ticket o pagine correlate) così i revisori vedono il contesto senza cercare altrove.

Costruire l'interfaccia base per drafting e reviewing

L'interfaccia è dove la pipeline prende vita per gli utenti. Punta a due superfici principali—Drafting e Reviewing—con il workflow sempre visibile così nessuno deve indovinare il passo successivo.

Schermata di creazione/modifica bozza: rendi evidente “dove sono”

Nella schermata dell'editor, riserva un'area header coerente per il contesto di workflow:

• Stato corrente (es. Draft, In Review, Needs Changes)
• Owner (chi è responsabile ora)
• Prossimo passo (che azione lo fa avanzare e chi può farla)

Mantieni le azioni contestuali: “Submit for review” dovrebbe apparire solo quando la bozza è sufficientemente valida, mentre “Revert to draft” dovrebbe essere limitato ai ruoli autorizzati. Aggiungi controlli leggeri (titolo mancante, summary vuoto) che evitino invii accidentali senza trasformare l'editor in una compilazione di campi.

Schermata di review: ottimizza per commenti e richieste di modifica

I revisori dovrebbero passare il tempo a leggere e decidere—non a cercare pulsanti. Usa un layout split: contenuto da una parte, strumenti di review dall'altra. Rendi semplice:

• Lasciare commenti inline (ancorati a un paragrafo/selezione)
• Creare una change request con checklist o campi obbligatori
• Risolvere thread e riassumere cosa blocca l'approvazione

Diff + riepilogo delle modifiche: riduci i ping-pong

Quando viene inviata una revisione, mostra una diff view tra versioni e un breve change summary (“Cosa è cambiato dall'ultima review?”). Questo evita feedback ripetuti e accelera la ri-approvazione.

Azioni batch: aiuta i revisori occupati

Per i team che revisionano molti elementi, aggiungi azioni batch nelle liste: approvare più elementi, richiedere modifiche a più elementi o assegnare a un altro revisore—sempre richiedendo una breve nota quando si chiedono modifiche per mantenere tracciabilità.

Notifiche, promemoria e sottoscrizioni

Le notifiche sono il punto in cui un workflow di approvazione sembra “vivo”. Fatto bene, tengono le review in movimento senza costringere le persone a controllare continuamente l'app. Fatto male, abituano gli utenti a ignorare tutto.

Canali: in-app prima, poi email, poi integrazioni chat

Inizia con notifiche in-app per consapevolezza in tempo reale (un'icona campana, una inbox, contatori non letti). Mantieni i messaggi brevi e azionabili: cosa è cambiato, chi l'ha fatto e cosa ci si aspetta dopo.

Aggiungi email per eventi importanti quando qualcuno non è loggato: assegnazione di una review, menzione o scadenza imminente. Se il tuo pubblico usa molto la chat, offri hook opzionali per Slack/Teams per integrazioni come “post in canale quando un elemento entra in Review”. Rendi queste opzioni opt-in per workspace o progetto.

Regole di promemoria per elementi bloccati (SLA-based)

I promemoria devono seguire regole temporali chiare, non sensazioni.

Per esempio:

• Se un elemento resta in Needs Review per 48 ore, ricorda al revisore assegnato.
• Se resta per 72 ore, notifica il backup del revisore o il project owner.
• Se la data di scadenza è tra 24 ore, invia un avviso “scadenza imminente”.

Rendi i promemoria intelligenti: sopprimili se un revisore è out-of-office (se tracciato) e smetti di sollecitare quando viene postato un commento o una decisione.

Sottoscrizioni: segui ciò che ti interessa davvero

Consenti agli utenti di iscriversi a più livelli:

• Un elemento (bozza/articolo) per tracciare ogni cambiamento
• Un progetto/campagna per seguire il progresso complessivo
• Una fase (es. tutto ciò che entra in Legal Review)

Le sottoscrizioni riducono le menzioni “FYI” e aiutano gli stakeholder a ottenere aggiornamenti senza chiedere.

Evitare sovraccarico con preferenze e digest

Dai a ogni utente una pagina di impostazioni notifiche (collegala da /settings/notifications) con:

• Toggle per canale (in-app vs email vs chat)
• Controlli per evento (assegnazione, cambio stato, commento, approvazione/rifiuto)
• Un digest giornaliero o settimanale per aggiornamenti di bassa priorità

Principio di design: invia meno notifiche, ma più chiare—ciascuna dovrebbe rispondere a “cosa è successo?” e “cosa devo fare dopo?”.

Audit trail e cronologia versioni

Quando i contenuti passano in revisione, la storia spesso è più importante dello stato corrente. Un audit trail ti protegge quando qualcuno chiede “Chi ha approvato questo?” o “Perché abbiamo pubblicato quella versione?” Riduce anche attriti interni rendendo le decisioni visibili e responsabili.

Cosa registrare (e come)

Inizia con un registro eventi immutabile: una cronologia a cui si aggiunge, non si sovrascrive. Ogni voce dovrebbe rispondere a quattro domande—chi, cosa, quando e perché.

• Registro immutabile: chi ha cambiato stato, quando e perché (includi campi “reason” opzionali per rifiuti o approvazioni urgenti)
• Cattura decisioni di approvazione, commenti e allegati (es. note legali, screenshot, linee guida brand) insieme all'evento che le ha generate

Mantieni il registro leggibile per utenti non tecnici: mostra timestamp comprensibili, nomi (non ID) e la transizione esatta di stato (Draft → In Review → Approved). Se hai un passaggio “request changes”, registra le richieste come campi strutturati (categoria, gravità) oltre al testo libero.

Cronologia versioni di cui ti puoi fidare

Gli audit spiegano le decisioni; la cronologia versioni spiega i cambiamenti di contenuto. Salva una nuova versione ogni volta che cambiano body, titolo, metadata o campi critici.

• Cronologia versioni con opzioni di restore/rollback così gli editor possono tornare indietro in sicurezza senza copiare/incollare da vecchie email

Rendi l'interfaccia diff-friendly: evidenzia cosa è cambiato tra le versioni (anche una semplice vista “prima/dopo” è sufficiente per cominciare).

Export audit e retention

Gli audit esistono anche fuori dalla tua app.

• Esporta i log per audit (CSV/PDF) dove appropriato

Decidi le regole di retention presto (es. conservare i log per 2–7 anni) e rendi gli export filtrabili per intervallo di date, content item e fase del workflow per evitare di esportare migliaia di righe inutili.

Ricerca, filtri e viste di reporting

Una volta che la pipeline ha più di pochi elementi, le persone smettono di “sfogliare” e iniziano a trovare. Una buona ricerca e viste trasformano la tua app da lista a strumento di lavoro affidabile.

Ricerca full-text che rispetta il modo di lavorare dei team

Supporta ricerca full-text nei luoghi che i revisori citano davvero: titolo, body e commenti. Rendi i risultati prevedibili mostrando i match evidenziati e un contesto base (stato, progetto, assignee corrente). Se conservi contenuti lunghi, indicizza solo ciò che serve (per es. l'ultima versione più i commenti) così i risultati sono veloci e rilevanti.

Un piccolo tocco utile: operatori di ricerca che gli utenti non tecnici capiscono, come virgolette per frasi ("brand voice") o filtrare per tag direttamente nella barra di ricerca.

Filtri che rispondono a domande reali

I filtri dovrebbero rispondere a “Cosa devo fare dopo?” e “Cosa è bloccato?”. Filtri comuni:

• Stato (Draft, In review, Approved, Changes requested)
• Assignee e team
• Data di scadenza (in ritardo, scadenza questa settimana)
• Tag, progetto/campagna, richiedente

Combina filtri liberamente e mostrali come chip rimovibili così gli utenti capiscono perché un elemento è in lista.

Viste salvate per singoli e team

Permetti di salvare un set di filtri come vista nominata, tipo “Needs my review” o “Overdue for Legal”. I team spesso vogliono viste condivise fissate nella sidebar così tutti lavorano dalla stessa coda. Considera i permessi: una vista salvata deve mostrare solo elementi accessibili a chi la visualizza.

Dashboard di reporting che evidenziano i colli di bottiglia

I dashboard non devono essere complessi per essere utili. Parti con qualche metrica chiara: elementi per stato, tempo medio di ciclo per fase e dove il lavoro si accumula. Se una fase è costantemente lenta, è un problema di staffing o policy—i report devono renderlo evidente.

Progettare l'API per le operazioni di workflow

La tua API è il contratto tra UI, integrazioni e regole di workflow. Se è coerente, il prodotto risulta prevedibile; se è incoerente, ogni schermo e integrazione diventa un caso a sé.

REST vs GraphQL (come scegliere)

REST è di solito la scelta più semplice per un'app di approvazione perché le azioni di workflow si mappano bene su risorse (items, reviews, decisioni) e puoi mantenere cache, log e tooling lineari.

GraphQL può aiutare quando molte schermate hanno bisogno di forme diverse dello stesso content item (bozza + revisori + cronologia in una chiamata). Se usi GraphQL, modella comunque le azioni di workflow in modo esplicito (mutations) e mantieni una nomenclatura coerente con la tua macchina a stati.

Mantieni endpoint prevedibili

Progetta attorno a due idee: (1) il content item come risorsa centrale e (2) le azioni di workflow come operazioni esplicite.

Un set REST pratico potrebbe essere:

• GET /content?status=in_review&cursor=... (liste)
• GET /content/{id} (dettagli)
• POST /content/{id}/workflow/request-review
• POST /content/{id}/workflow/decision (approve / request changes / reject)
• POST /content/{id}/workflow/transition (override admin-only, se permesso)

Mantieni i corpi delle richieste semplici e coerenti:

{ "action": "approve", "comment": "Looks good.", "assignedTo": "user_123" }

Evita endpoint come /approveContentNow o PUT /content/{id}/status senza validazione—tendono a bypassare le regole che rendono il workflow affidabile.

Idempotenza per le modifiche di stato (e webhook)

Le operazioni di workflow vengono spesso ritentate (reti mobili, replay delle code, ridelivery dei webhook). Rendi le richieste che cambiano stato idempotenti accettando un header Idempotency-Key e restituendo lo stesso risultato per chiamate ripetute.

Considera anche la concorrenza ottimistica:

• Includi una version (o etag) in GET /content/{id}
• Richiedi If-Match (o version) su decisioni/transizioni per evitare condizioni di "last write wins"

Rate limiting e paginazione per le liste

Gli strumenti di approvazione vivono sulle schermate lista: “Needs review”, “Waiting on legal”, “My assignments”. Implementa la paginazione fin da subito—la paginazione basata su cursore è più stabile quando i dati cambiano.

• GET /content?status=needs_changes&limit=50&cursor=...

Aggiungi limiti di richiesta sensati per token (specialmente per endpoint di ricerca) e restituisci header chiari (es. richieste residue, tempo al reset). Questo protegge il sistema e rende i fallimenti delle integrazioni più facili da diagnosticare.

Integrazioni e hook di automazione

Le integrazioni sono il punto in cui una pipeline di approvazione smette di essere “un altro strumento” e inizia a inserirsi nel flusso di creazione, revisione e pubblicazione del team. L'obiettivo è semplice: ridurre copia-e-incolla, mantenere i file sorgente collegati e far scattare automaticamente il passo successivo.

Target di integrazione comuni

Un'app pratica di workflow di contenuti tipicamente si collega a pochi sistemi:

• CMS (Contentful, WordPress, Webflow): push del contenuto "approved" nella coda di pubblicazione, o pull di bozze per essere riviste.
• Google Docs: importare un Doc come bozza, sincronizzare commenti o snapshot del testo finale quando è approvato.
• GitHub: trattare il contenuto come codice—aprire una PR quando una bozza è pronta, richiedere approvazioni e fare merge alla pubblicazione.
• Figma: allegare i mockup di design a un content item così i revisori vedono le grafiche più aggiornate insieme al testo.
• DAM (Bynder, Cloudinary, Brandfolder): collegare immagini approvate e tracciare diritti d'uso e versioni.

Webhook e eventi di automazione

Esponi un piccolo set di eventi affidabili così altri strumenti possono reagire senza lavori ad hoc:

• content.approved
• content.rejected
• content.published
• review.requested

Ogni webhook dovrebbe includere l'ID del contenuto, stato corrente, timestamp e URL di ritorno alla tua app. Documenta i payload e la strategia di signing in un riferimento semplice come /docs/api.

Import/export per migrazione e backup

I team raramente partono da zero. Supporta:

• Import CSV/JSON per creare item, assegnare owner e impostare stati iniziali
• Export di contenuto + metadata + audit trail per report, compliance o migrazione

Se sviluppi solo una “power feature” qui, falla idempotente: importare lo stesso file due volte non deve creare duplicati.

Scegli uno stack tecnico pratico e un'architettura

Un'app di workflow di approvazione è per lo più “business logic + permessi + auditabilità.” È una buona notizia: non servono tecnologie esotiche per farla bene. Scegli strumenti che il tuo team può rilasciare e mantenere con fiducia, poi progetta l'architettura attorno a operazioni di workflow prevedibili (create draft → request review → approve/reject → publish).

Se stai validando il prodotto prima di investire in una build completa, puoi prototipare l'UI del workflow, i ruoli e le notifiche rapidamente su una piattaforma di vibe-coding come Koder.ai. Perché genera applicazioni complete da chat (inclusi React UIs e backend Go + PostgreSQL), è un modo pratico per trasformare la macchina a stati e le regole di permesso che definisci qui in uno strumento interno funzionante, con esportazione del codice sorgente disponibile quando sei pronto ad andare oltre.

Frontend: ottimizza per velocità e coerenza

Per l'interfaccia, React o Vue sono ottime scelte—scegli quella che il tuo team conosce già. Abbinala a una libreria di componenti (per esempio Material UI, Ant Design, Vuetify) così puoi muoverti in fretta su form, tabelle, modal e badge di stato.

I bisogni chiave dell'UI si ripetono: chip di stato, code dei revisori, diff view e thread di commenti. Una libreria di componenti aiuta a mantenere coerenza senza settimane spese nello styling.

Backend: scegli ciò che il tuo team può gestire

Qualsiasi backend mainstream può gestire una pipeline di approvazione:

• Node/Express: iterazione veloce, grande ecosistema
• Django: ottimo admin tooling, adatto ad app di workflow data-heavy
• Rails: ottime convenzioni per CRUD + workflow
• .NET: buon fit enterprise, ottimi strumenti, buona performance

Ciò che conta è come implementi chiaramente le regole di workflow, applichi i permessi e registri l'audit trail. Preferisci framework che rendono semplice testare la business logic e mantenere i controller snelli.

Archiviazione: Postgres + object storage

Usa Postgres per i dati relazionali del workflow: content items, versions, workflow states, assignments, comments, approvals e permessi. I sistemi di approvazione prosperano grazie a relazioni chiare e transazioni.

Per gli upload (immagini, PDF, allegati), usa object storage (es. compatibile S3) e conserva solo metadata + URL in Postgres.

Job in background: mantieni l'app reattiva

Notifiche, promemoria e webhook outbound dovrebbero essere eseguiti da worker in background, non nel ciclo request/response. Questo evita caricamenti lenti e facilita i retry.

Job tipici:

• Inviare email/Slack quando viene richiesta una review
• Promemoria giornalieri per review scadute
• Inviare webhook alle integrazioni con retry e backoff

Un'architettura semplice che scala con te

Parti con un monolite modulare: un backend, un database, una coda di job. Aggiungi confini chiari (workflow engine, permessi, notifiche) così puoi spezzare i servizi in seguito se necessario. Se vuoi vedere in anteprima come appaiono quei confini da un punto di vista API, guarda il riferimento alla progettazione API per le operazioni di workflow.