I workflow sono event-driven: un trigger si attiva e una sequenza di step viene eseguita sui sistemi connessi senza handoff manuali. Gli step vengono eseguiti in sequenza o in parallelo; logica di branching e gestione dei retry sono a carico della piattaforma. In qualsiasi punto designato il workflow si mette in pausa per una decisione umana — un'approvazione, una revisione, una conferma — poi riprende esattamente da dove si era fermato.

Senza on.it, l'autenticazione va cablata separatamente in ogni applicazione, workflow engine e agente che distribuisci — identity provider, gestione delle sessioni, federazione SSO, applicazione dei ruoli, tutto, per ciascuno. Su on.it, niente di tutto ciò è un tuo problema. Un unico gateway gestisce l'autenticazione per tutto ciò che esegui sulla piattaforma, prima che una richiesta raggiunga il tuo codice.

Isolamento dei dati

Isolamento dei dati applicato sotto il tuo codice

Il codice applicativo letteralmente non può vedere i dati di un altro tenant — nemmeno se ci prova.

Nella maggior parte dei sistemi, l'isolamento è applicato dall'applicazione: ogni richiesta porta un filtro, ogni endpoint circoscrive i propri risultati. Quando uno di questi controlli fallisce — un bug, un aggiornamento di libreria, un caso limite — i dati di un altro contesto appaiono dove non dovrebbero. Il sistema non aveva alcun meccanismo strutturale per impedirlo.

Abbiamo scelto un approccio diverso. I dati di ogni contesto sono completamente separati alla base della piattaforma. L'applicazione non ha mai accesso ai dati di un altro contesto — non perché il codice lo verifichi, ma perché dal punto di vista della piattaforma, quei dati semplicemente non esistono. L'isolamento non è un filtro che l'applicazione applica; è una proprietà strutturale della piattaforma. Questo vale indipendentemente da ciò che fa l'applicazione. Un filtro mancante, un permesso elevato o un'integrazione mal configurata non possono produrre dati di un altro contesto.

Osservabilità

L'audit trail non può essere modificato dal codice applicativo

Ogni azione viene registrata in un log che il codice applicativo non può raggiungere, modificare o antidatare.

La telemetria viene raccolta a livello infrastrutturale — dalla piattaforma, prima e dopo l'esecuzione del tuo codice. Ogni richiesta è tracciata dal punto di ingresso fino al layer dati. L'audit trail è catturato attraverso una pipeline che i processi applicativi non possono raggiungere o modificare — ogni evento viene registrato indipendentemente da ciò che l'applicazione emette, ricercabile e riproducibile da un log strutturato centralizzato. La pipeline di telemetria è chiusa in scrittura ai processi applicativi: l'audit trail è completo, immodificabile e non antidatabile.

La maggior parte delle piattaforme offre un unico punto di estensione — di solito uno strato di scripting o un hook di configurazione sopra un core fisso. Il modello a plugin di on.it attraversa ogni layer dello stack: il modello dati, la business logic e il layer AI seguono tutti lo stesso pattern e le stesse convenzioni. Puoi estendere qualsiasi livello in modo indipendente, senza toccare gli altri.

Analytics

Analytics senza spostare i dati

Interroga il tuo database live e i tuoi dati storici insieme — in un'unica istruzione SQL, senza replica.

Un layer di query federata si posiziona sopra le tue sorgenti dati esistenti — object storage, database operativi, sistemi esterni — leggendo i dati in loco. Dati storici e live sono interrogabili insieme in un'unica istruzione SQL; il layer è in sola lettura e le tue sorgenti rimangono invariate. I dashboard vivono nella piattaforma ed ereditano lo stesso scope enforcement: ogni utente vede solo ciò che il proprio ruolo consente.

AI contestuale

AI al layer dati

Agenti AI che leggono gli stessi dati dell'applicazione — né più, né meno — delimitati dalle stesse regole di isolamento.

Gli agenti AI si connettono direttamente al layer dati. Quando un agente viene eseguito, legge record strutturati, storico degli eventi e segnali in tempo reale dalle stesse sorgenti usate dall'applicazione — al momento della query, sullo stato live. Lo scope è strutturale: ciò che un agente può leggere è determinato dalle stesse regole di isolamento che governano ogni altra richiesta sulla piattaforma. Un agente legge ciò che legge l'applicazione — né più, né meno.