Asana non sa che un container è bloccato in dogana.

Sì. Lo stesso componente Attività viene visualizzato in tre portali: operatore (visibilità completa), cliente (l'acquirente — vede le attività create per lui, come «Approva campione» o «Conferma spedizione frazionata»), e fornitore (il produttore — vede le attività create per lui, come «Invia report SGS» o «Conferma il calendario di ispezione»). Ciascun portale utilizza lo stesso modello di dati con un prefisso API differente (operatore: /api/tasks · cliente: /api/portal/client/tasks · fornitore: /api/portal/supplier/tasks) e una whitelist di tipi di entità circoscritta. L'operatore crea un'attività, la assegna a un contatto del fornitore, e questa appare nell'elenco delle attività del portale fornitore — stesso enum di stato, stessa priorità, stesso flusso di attività. Il fornitore la contrassegna come completata; l'operatore vede il completamento in tempo reale.

Le approvazioni sono Attività. Più precisamente, un'attività con stato pending_approval — uno dei sei stati nativi. Quando un operatore o una controparte invia un elemento che richiede una validazione (una bozza contrattuale rivista, una valutazione di campione, uno sforamento di budget, una versione di documento), il lavoro passa a pending_approval e compare nell'elenco delle attività dell'approvatore insieme a tutto il resto su cui deve agire. L'approvazione, il rifiuto e la richiesta di «modifiche necessarie» sono transizioni di stato sull'attività. La traccia di audit — chi ha approvato cosa, quando e perché — risiede nel flusso di attività dell'attività stessa. Abbiamo deliberatamente scelto di non costruire un motore di approvazioni separato; integrandolo nelle Attività si ottiene una sola casella di posta, un solo flusso di lavoro, un solo punto di riferimento.

Sì — questa è la parte «sistema nervoso» dell'architettura. Gli eventi nelle altre sezioni (cambio di stato di un ordine, QC di produzione completato, ritardo nella spedizione, fattura scaduta, campione valutato, reclamo presentato, documento caricato, messaggio contrassegnato con un punto d'azione) vengono tutti emessi attraverso il motore delle Attività. La piattaforma determina se l'evento richiede attenzione umana in base a regole configurabili per categoria; quando è necessario, viene creata un'attività con il collegamento all'entità ereditato, la categoria preimpostata e un assegnatario suggerito estratto dalla cronologia delle parti responsabili. Le Attività sono il modo in cui la piattaforma comunica agli operatori il lavoro da svolgere — e il modo in cui verifica se quel lavoro è stato effettivamente completato.

La principale superficie di azione di Atlas È la creazione di attività. Quando Atlas rileva qualcosa che richiede un giudizio umano — un margine che scende al di sotto di una soglia, una controparte che smette di rispondere in un thread, un documento in scadenza, un pattern ricorrente tra gli ordini — crea un'attività con i dati pertinenti già allegati. Un messaggio in chat pone una domanda e scorre via. Un'attività porta con sé il contesto, l'assegnatario, la data di scadenza e la traccia di audit che indica se l'operatore ha agito. Questo rende il segnale di Atlas misurabile: l'attività è stata chiusa nei tempi previsti? È stata chiusa del tutto? Il fatto che Atlas crei attività (invece di limitarsi a inviare messaggi) è il modo in cui manteniamo l'IA responsabile del lavoro che porta alla luce.