Cursor trasforma un foglio vendite in un’app. Chi si occupa del link?
Cursor Live Apps offre hosting, autenticazione e Postgres opzionale. Un pannello commerciale e un portale per i nuovi assunti mostrano dove comincia il lavoro del team.
Lunedì mattina, la responsabile vendite vuole una sola pagina con i clienti che richiedono attenzione. I dati sono in un foglio di calcolo, le regole di assegnazione in una seconda scheda e ognuno ha una copia leggermente diversa. In un pomeriggio uno sviluppatore può preparare un pannello utile. La prima domanda scomoda arriva quando la responsabile chiede il link.
Anysphere, la società che sviluppa l'ambiente di programmazione Cursor, ha lanciato Live Apps il 5 novembre 2026. Puoi chiedere a un agente cloud di Cursor di costruire un'applicazione web. Cursor può predisporre l'hosting, l'autenticazione e, se serve, un database Postgres. Dopo una verifica di sicurezza e un'azione di pubblicazione esplicita, l'app riceve un URL operativo. La funzione è disponibile sui piani a pagamento con gli agenti cloud attivi. Il codice può provenire da un repository nuovo o esistente su Cursor Origin o GitHub. Annuncio di Cursor
Un'app interna diventa così un'opzione pratica per i flussi di lavoro che prima dipendevano da copie di fogli di calcolo e messaggi settimanali. Diventa anche facile passare da un prototipo a uno strumento su cui un collega conta. Un pannello commerciale e un portale per l'inserimento dei nuovi assunti mostrano quando ha senso fare quel passo e come stabilire chi possa vedere, modificare o disattivare ciò che l'app mette a disposizione.
Il pulsante di pubblicazione chiude un lavoro e ne apre un altro
Cursor chiede di specificare che vuoi un'app e di usare un agente cloud. Una sessione di programmazione locale può aiutarti con il codice, ma il flusso Apps descritto da Cursor passa per l'agente cloud. Se parti da zero, puoi creare un repository su Cursor Origin. Se il team ha già un'app in un repository supportato, puoi riutilizzarne il codice. Cursor predispone le risorse, mentre chi pubblica sceglie l'URL e decide quando condividerlo. Configurazione e pubblicazione di Apps
Dal codice a un URL operativo, con il pubblico e la fonte dei dati rappresentati separatamente. Illustrazione originale di Telli.sh.
Cursor descrive due verifiche prima della pubblicazione. I controlli deterministici individuano condizioni note, come un segreto scritto in un file. Una revisione di sicurezza basata sull'IA esamina il codice in cerca di problemi gravi. Secondo Cursor, gli amministratori del team possono aggiungere regole proprie, vedere app e segreti del team e ritirare le app pubblicate. Possono anche approvare alcune pubblicazioni bloccate dalla revisione con IA. Cursor mantiene il blocco quando rileva codice dannoso, segreti incorporati nel codice o credenziali esposte. Spetta comunque a chi gestisce l'app decidere quali credenziali le servano. Annuncio di Cursor · Sicurezza e amministrazione di Apps
Immagina un'app che in home mostra i totali delle vendite e il cui endpoint di dettaglio restituisce tutti i clienti. Quando la responsabile commerciale accede, la pagina può sembrare correttamente limitata. Un altro collega potrebbe comunque indovinare l'URL di dettaglio o chiedere al server i dati di un'area che non vede nella tabella. La revisione della pubblicazione può trovare difetti di implementazione. Le regole di accesso del team restano il riferimento per stabilire la visibilità per area e il collaudo deve verificarle con i ruoli pertinenti.
Con un URL operativo, queste decisioni iniziano ad avere conseguenze. Quando i colleghi salvano il link, un rapporto che smette di funzionare può ritardare la riunione del mattino. Se l'app diventa l'unico posto in cui si registra una decisione o un'approvazione, il database entra a far parte di un processo aziendale. Anche un'app minuscola ha bisogno di una persona che sappia spiegare cosa è successo quando i numeri non tornano.
Parti da un pannello di sola lettura
Supponiamo che il team delle operazioni commerciali voglia vedere le opportunità in due aree. Una prima versione sensata mostra il numero di opportunità per fase, la data dell'ultimo aggiornamento e un link al record del CRM per i dettagli. Inizialmente usa clienti fittizi. Quando la vista è corretta, le credenziali possono dare accesso in lettura a un report circoscritto o a una vista del database contenente soltanto i campi necessari. Le assegnazioni e le note rimangono in carico al CRM. La prima pubblicazione lascia così fuori le modifiche ai dati aziendali e mantiene un riferimento indipendente per confrontare i totali.
Secondo la documentazione di Cursor Apps, i segreti per un data warehouse o un'altra risorsa esterna si possono inserire durante la configurazione dell'app o dal pannello di Apps. Cursor afferma che l'agente non ne vede i valori. Le credenziali entrano comunque in gioco quando l'app pubblicata invia una richiesta. Tieni la connessione nel codice lato server, limita le interrogazioni consentite e verifica la pagina prodotta e le risposte di rete, cercando eventuali campi che dovevano restare sul server. Un segreto di sola lettura aiuta se l'account associato ha davvero accesso di sola lettura ai dati previsti. Segreti in Cursor Apps
| Decisione per la prima pubblicazione | Pannello delle opportunità commerciali | Portale per i nuovi assunti |
|---|---|---|
| Destinatari previsti | Gruppo definito delle operazioni commerciali | Dipendenti e coordinatori dell'inserimento invitati |
| Fonte ufficiale dei dati | CRM o vista di report con accesso limitato | Guida interna approvata e lista delle attività |
| Stato utile da salvare | Filtri e preferenze di visualizzazione | Attività completate dal dipendente autenticato |
| Verifica prima di condividere | Confrontare due aree e provare un URL di dettaglio senza autorizzazione | Verificare che un dipendente non possa leggere o cambiare la lista di un'altra persona |
| Responsabile operativo | Operazioni commerciali, con un referente di riserva | Risorse umane, con un responsabile dei contenuti identificato |
Prova il pannello da tre punti di vista. L'utente previsto deve vedere il totale corretto e l'ora dell'aggiornamento. Un collega di un'altra area deve vedere solo le righe consentite dalla politica dell'app, anche se modifica il link o la richiesta. Chi non rientra fra i destinatari deve ricevere un rifiuto prima che arrivi qualsiasi dato del pannello. Il secondo controllo è particolarmente utile perché il difetto può sfuggire facilmente se verifica l'app soltanto chi l'ha costruita.
Confronta i risultati con un'istantanea fissa del sistema di riferimento. Registra l'intervallo di date, il fuso orario, i criteri di inclusione e il totale esatto previsto per ogni area. Se nel grafico sembrano mancare le opportunità del lunedì, potrebbe trattarsi di un'interpretazione diversa dell'intervallo del report. Nei primi test includi un risultato vuoto, una richiesta alla fonte che superi il tempo di attesa e un aggiornamento in ritardo. Indicare l'ultimo aggiornamento riuscito e mostrare un errore esplicito aiuta a distinguere un disservizio da una vera flessione delle opportunità.
Un portale per i nuovi assunti giustifica il database un campo alla volta
Un portale che si limita a rimandare a pagine di istruzioni esistenti può fare a meno di un nuovo database. Una lista interattiva introduce dati da conservare. Cursor può predisporre Postgres se l'app ne ha bisogno, rendendo più semplice la seconda versione. Prima di usare questa funzione, scrivi quali valori devono davvero essere salvati. Possono bastare l'identificativo di un'attività, la data e l'ora del completamento e un identificativo stabile dell'utente autenticato. Copiare le note del responsabile, un documento d'identità o l'indirizzo di casa di un dipendente aggiunge rischio senza migliorare la lista. Risorse di Cursor Apps
Separa i dati che aiutano i dipendenti a seguire il percorso da quelli che servono al coordinatore per gestirlo. Un dipendente può contrassegnare come completata una propria lettura obbligatoria. Un coordinatore può aver bisogno di vedere le attività in ritardo per un intero gruppo. Applica una regola di accesso distinta alla vista del coordinatore e controlla la relativa query separatamente. Una sola schermata di accesso rende le due viste coerenti, pur rispondendo a esigenze di autorizzazione diverse.
Tre controlli di accesso distinti per la stessa app interna. Illustrazione originale di Telli.sh.
Una piccola prova può usare un dipendente fittizio e un coordinatore di test prima di salvare dati reali. Stabilisci una prova di accesso negato da superare prima di pubblicare. Un dipendente non deve poter sovrascrivere lo stato di un'altra persona, nemmeno cambiando un identificativo nella richiesta del browser. Verifica poi che ripetere l'operazione sulla stessa attività lasci invariato lo stato, senza duplicare i progressi. La prova serve a rendere il comportamento verificabile senza chiedere a un collega di esporre informazioni reali.
Per passare la gestione di un'app del genere conviene avere una lista. Annota come un nuovo coordinatore ottiene l'accesso, dove si modifica la guida, chi può revocare l'accesso a chi ha lasciato l'azienda e che fine fanno i dati già registrati. Decidi come recuperare lo stato necessario se una modifica fallisce. Cursor può predisporre il database. Resta al team stabilire cosa significhino recupero e conservazione per quella specifica lista.
Un invito e una chiave di integrazione hanno scopi diversi
La documentazione attuale di Cursor Apps distingue tre modalità di condivisione. Un'app solo su invito può essere aperta dal suo responsabile e da persone o gruppi specifici che abbiano effettuato l'accesso. La condivisione con il team può aprirla all'intero team di Cursor autenticato. Un'app pubblica può essere aperta da chiunque abbia l'URL. Su Teams ed Enterprise la condivisione pubblica è disattivata per impostazione predefinita, a meno che un amministratore non la abiliti. L'annuncio di lancio evidenzia la condivisione pubblica nei piani individuali. Perciò un URL funzionante dice poco sui destinatari effettivi finché non controlli la visibilità nel pannello di Apps. Condivisione in Cursor Apps
La stessa documentazione descrive le chiavi API per le richieste automatizzate. La chiave viene passata in un'intestazione HTTP e la richiesta è identificata come automatica, senza essere associata a una persona. È comodo se uno script deve chiamare l'app. Cambia anche il modo in cui esamini una richiesta imprevista. Se l'app supporta sia le sessioni delle persone sia una chiave API, verifica che l'automazione possa eseguire solo le azioni necessarie. Registra dove si usa la chiave e chi la sostituirà. Se ogni azione importante inizia quando un collega apre il link, nella prima prova limitati agli utenti umani. Chiavi API di Cursor Apps
Quando un'app legge da un data warehouse, ci sono tre livelli da verificare. Cursor controlla chi può aprire il link. L'app decide a quali azioni e righe quelle persone possono accedere. Il sistema a monte stabilisce cosa può leggere la credenziale di servizio dell'app. Gli altri livelli possono contenere gli effetti di una scelta sbagliata. Se al pannello interno servono solo i conteggi aggregati delle opportunità, assegnargli una credenziale in grado di interrogare ogni record del CRM rende costoso un piccolo difetto dell'app.
I test possono essere semplici. Apri il link pubblicato in sessioni nuove del browser come persona invitata, come collega autenticato senza accesso e senza effettuare l'accesso. Nella sessione autorizzata chiedi un record che deve essere visibile e un altro di un'area diversa. Se uno script usa una chiave, assicurati che la richiesta senza intestazione fallisca e che una chiave revocata venga rifiutata. Sono verifiche separate perché ognuna può mettere in luce un tipo di errore diverso.
Una prima versione circoscritta accelera la verifica
- Scegli un compito e individua i destinatari. Per il pannello, chiedi i totali settimanali delle opportunità per fase, con record fittizi, un'ora di aggiornamento visibile e un link al CRM. Per il portale, chiedi una breve lista di attività con profili di dipendenti fittizi.
- Avvia un agente cloud e chiedigli esplicitamente di costruire un'app. Usa un repository a cui possa accedere chi se ne occuperà. Mantieni la prima modifica abbastanza piccola da consentire al responsabile di spiegare le rotte, il modello dei dati e la gestione degli errori.
- Specifica quali dati possono persistere e quali richieste possono scrivere. Collega un segreto ad accesso limitato nelle impostazioni soltanto quando il flusso con i dati fittizi funziona. Chiedi all'agente di mostrarti dove si usa il segreto e dove si applicano le verifiche dei destinatari.
- Avvia la revisione per la pubblicazione e leggi il risultato. Scegli l'URL, pubblica esplicitamente e condividi con il gruppo idoneo più ristretto. Prima che qualcuno inizi a dipendere dall'app, prova sul link pubblicato sia le richieste consentite sia quelle da rifiutare.
- Registra chi risponde dell'app, quale servizio a monte contatta e chi può metterla offline. Ripeti una breve verifica dopo aver cambiato la visibilità, un connettore o le credenziali. Conserva un link o una procedura alternativa per quando l'app non è disponibile.
La prima versione può avere un perimetro più piccolo di quello che l'agente potrebbe realizzare. Un pannello che mostra una cifra affidabile ogni mattina può servire più di uno spazio con sei viste e calcoli su cui nessuno concorda. Un portale con una lista ben tenuta può eliminare messaggi ripetuti anche se la vista del coordinatore arriverà in seguito. Una prima versione più piccola dà inoltre a chi gestisce lo strumento il tempo di osservare quali modifiche, richieste di accesso e domande di supporto arrivino davvero.
Conviene valutare il risultato nel corso di una settimana normale. Osserva quanto spesso qualcuno apre l'app di propria iniziativa, se riesce a rintracciare la fonte quando mette in dubbio un valore e quanto tempo impiega chi gestisce l'app a correggere un problema. Un'app che fa risparmiare qualche minuto al giorno può giustificare il lavoro che richiede. Se le persone continuano a tornare al foglio per avere conferma, individua quale risultato dell'app non è ancora affidabile.
Le novità di Cursor rendono più facile avviare una prova di questo genere. Nell'annuncio del 5 novembre, costruzione, database, autenticazione, hosting e link di condivisione fanno parte di un solo flusso. Prima, lo stesso esperimento poteva arenarsi mentre si cercava un responsabile per l'hosting o si configurava l'accesso. Quando questi elementi sono disponibili, il lavoro più delicato diventa definire con chiarezza i destinatari, i dati e le condizioni di pubblicazione. Alla fine, il risultato utile è un link che qualcuno sa usare e di cui qualcun altro sa prendersi cura. Annuncio di Cursor
Fonti
- Lancio di Cursor Live Apps, 5 novembre 2026
- Documentazione di Cursor Apps su configurazione, condivisione e controlli amministrativi
Per conservare un archivio consultabile delle conversazioni e delle decisioni alla base di uno strumento interno, crea un account Telli.sh.