Gli agenti costruiscono. Tu decidi cosa va in Produzione
Per chi lavora sulle istanze ServiceNow dei clienti. SNForge legge l'istanza e risponde con le fonti, misura licenze, CMDB e debito tecnico, prepara i documenti di consegna. Quando serve una modifica, porta il requisito fino all'update set e alle promozioni. Su ogni decisione che conta c'è una persona.
Le regole che il prodotto fa rispettare
Nessuna scrittura in Produzione senza una personail commit resta manuale
Chi avvia non apprované la UAT né la Produzione
Un update set per lavoroconfrontato con la destinazione
Dati personali mascheratiprima di ogni modello esterno
Clienti separati dal databaseRow-Level Security su ogni tabella
Registro a catenauna riga toccata rompe la catena
Come funziona
Un lavoro passa sempre dalle stesse quattro fasi, quelle che vedi nel prodotto: capire, progettare, costruire e provare, rilasciare. Scegli una fase: cosa fa, cosa lascia e chi decide.
Capire
L'analista dei requisiti legge il requisito, scritto in chat o in un documento, e ne ricava user story e criteri di accettazione in Gherkin. Se manca qualcosa fa le domande adesso, prima che si costruisca.
- Cosa produce
- User story, criteri di accettazione, domande aperte
- Chi decide
- Alle domande risponde un operatore
Scenario: P1 senza gruppo di assegnazione Dato un incidente con priorità 1 Quando lo salvo senza gruppo di assegnazione Allora il salvataggio si ferma E il campo gruppo diventa obbligatorio
Progettare
Il product manager ordina le story e fa il piano. L'architetto cerca sull'istanza e nella knowledge, e propone la soluzione con decisioni, alternative scartate e rischi. Ogni tabella e ogni campo che cita si verifica sullo schema dell'istanza.
- Cosa produce
- Piano e documento di soluzione, esportabile in Word
- Chi decide
- Un approvatore approva il design
✓ incident.priority integer, definito su task ✓ incident.assignment_group reference → sys_user_group ✓ incident.business_service reference → cmdb_ci_service ✓ cmdb_ci_service.owned_by reference → sys_user 4 simboli controllati, 0 inesistenti
Costruire e provare
Lo sviluppatore costruisce su Dev, in un update set dedicato al lavoro. Il validatore statico e il revisore controllano il codice: un problema bloccante lo rimanda indietro. Poi il tester scrive i test ATF dai criteri di accettazione e li fa girare su Dev; se uno fallisce, un controllo distingue l'errore del codice da quello del test, e il lavoro torna al punto giusto.
- Cosa produce
- Un update set su Dev, uno per lavoro, e i test ATF con l'esito
- Chi decide
- Nessuna persona: decidono i controlli e i test
SNForge/LAV-142, 8 modifiche + sys_ui_policy Gruppo obbligatorio in P1 + sys_script Avvisa il responsabile in P1 + sys_atf_test P1 rende obbligatorio il gruppo Suite ATF su Dev ✓ P1 senza gruppo non si salva ✓ P1 avvisa il responsabile del servizio 3 su 3 passati, esito allegato al lavoro
Rilasciare
Il redattore tecnico scrive BRD, FRD, piano di test e note di rilascio. Poi Test, UAT e Produzione, ognuna dietro il suo gate: prima di ogni decisione SNForge confronta l'update set con l'istanza di destinazione, controlla i prerequisiti e prepara la bozza di change request per il CAB. Su Produzione si ferma: il commit lo fa una persona, dentro ServiceNow.
- Cosa produce
- I documenti del lavoro, il confronto con la destinazione, la bozza di
change_request - Chi decide
- L'approvatore per Test e UAT, il release manager per la Produzione. Chi ha avviato il lavoro non approva UAT e Produzione.
La promozione fra Dev, Test e UAT è provata sul banco di prova; la prova su un Test e una UAT veri è la prossima.
● Dev costruito ● Test promosso, approvatore ● UAT promosso, approvatore ○ Produzione attende il release manager commit manuale, dentro ServiceNow
Da dove arriva il lavoro
Cinque porte, un solo percorso. Qualunque sia l'ingresso, il testo passa dalla mascheratura e il lavoro dalle stesse quattro fasi.
Schema: chat, documenti, il pulsante Chiedi a SNForge dall'istanza, l'API dei requisiti e il server MCP entrano in SNForge, che maschera i dati, fa lavorare agenti e controlli e registra tutto; poi il lavoro segue la catena di Dev, Test, UAT e Produzione con i suoi gate.
Chatdomande e requisiti, con le fonti citate
DocumentiPDF, Word, Excel e testo, mascherati al caricamento
Chiedi a SNForgeun pulsante sul record dell'istanza; la risposta torna come work note
API dei requisiti
POST /api/hooks/requirements, con la chiave dell'organizzazione: Teams, Slack, portaliServer MCP per Claudelegge schema, knowledge e lavori, e può avviare un lavoro
SNForge
- Mascheratura18 tipi di dato, prima dei modelli esterni
- Agenti e controlli10 agenti, 37 regole, test ATF
- Registro a catenaogni decisione e ogni scrittura
Poi la stessa catena di Dev, Test, UAT e Produzione, con gli stessi gate.
Il primo giorno su un'istanza
Prima di costruire, SNForge legge. Ecco cosa fa su un'istanza appena collegata: tutto in sola lettura, tranne i contratti, che scrive su SAM Pro solo dopo la tua conferma.
Ricognizione
Collega l'istanza e SNForge ne fa il profilo: release e patch, database, utenti e gruppi, plugin e applicazioni, installazioni recenti. Esce il documento tecnico in Word e PDF, con lo storico delle versioni.
«Fai la ricognizione»
Catalogo delle analisi
63 analisi in sola lettura, divise per modulo. Un clic le lancia, anche su Dev, Test e Produzione insieme, e l'esito porta il foglio Excel e il documento di consegna.
la scheda «Analisi» dell'istanza
Piano di upgrade
Quali record di serie il cliente ha modificato, quali torneranno di serie da soli e in che ordine riesaminarli verso la release di destinazione. Le ore non le inventa: le scrive chi chiede il piano.
il documento «Piano di upgrade»
Confronto fra istanze
«In Dev funziona, in Test no»: update set mancanti o arrivati a metà, versioni diverse dello stesso record di codice, proprietà, plugin e release. In cima la causa più probabile.
«Confronto fra istanze»
Sorveglianza notturna
Ogni istanza collegata, ogni notte, in sola lettura e senza niente da configurare. La mattina una riga per cliente: cosa è nuovo, cosa è peggiorato, cosa si è risolto.
la cronaca del mattino, in «Oggi» e per email
Contratti software
Carichi il contratto e lo legge soltanto il modello locale: importi e firme non escono dal server di SNForge. Rivedi righe e clausole, poi SNForge le scrive su SAM Pro; su Produzione prepara i file. L'archivio tiene i contratti letti e, per chi ha il permesso, confronta un'offerta con i prezzi già firmati.
la scheda «Contratti» e l'archivio
Il prodotto, com'è
Ritagli veri dal banco di prova, del 2 ottobre 2026. I clienti e le persone sono inventati, le pagine no; il costo dei modelli è tolto.
Una domanda vera, dall'inizio alla fine
Un consulente chiede come mostrare gli approvatori su una Business Application. Il flusso sta su un'istanza che SNForge non può vedere, quindi serve un passo passo. Prima di rispondere, la chat ha fatto tre cose:
- Ha cercato nella knowledgedue pagine della documentazione ufficiale sulle approvazioni, release Zurich
- Ha letto lo schema dell'istanzai campi di
sysapproval_approversu Aurora Dev:sysapprovalpunta a task, gli altri record passano dadocument_idesource_table - Ha verificato la fonte che citaF2 «Approval engines», confermata sulla pagina ufficiale Zurich
La risposta porta la Relationship con lo script refineQuery, i passi per configurarla e promuoverla, e chiude dicendo cosa ha verificato e cosa dice a memoria.
Codice che l'istanza riconosce
Un modello generico scrive ServiceNow a memoria, e a memoria inventa campi. SNForge cerca ogni tabella e ogni campo nello schema copiato dall'istanza del cliente, prima che il codice arrivi su Dev.
incidentda controllare4 rilievi, 2 bloccanti(function executeRule(current, previous) {
var gr = new GlideRecord('incident');
gr.addQuery('priority_level', 1);
gr.query();
while (gr.next()) {
gs.eventQueue('incident.p1.escalated', gr, gr.service_owner);
gs.log('P1 aperto: ' + gr.number);
}
})(current, previous);NF001bloccantesimbolo inesistente sull'istanza:incident.priority_levelNF001bloccantesimbolo inesistente sull'istanza:incident.service_ownerNF011gravegs.logè deprecato: usags.info/gs.warn/gs.errorNF090minoremanca il commento di testa con run_id SNForge, requisito di origine e data
Torna allo sviluppatore. Su Dev non arriva.
// SNForge LAV-142: avvisa il responsabile del servizio quando un incidente passa in P1
(function executeRule(current, previous) {
if (current.priority != 1 || previous.priority == 1) return;
var responsabile = current.business_service.owned_by;
gs.eventQueue('incident.p1.escalated', current, responsabile, current.number);
gs.info('[SNForge] P1 ' + current.number);
})(current, previous);incident.priorityinteger, definito su taskincident.business_servicereference → cmdb_ci_servicecmdb_ci_service.owned_byreference → sys_user
Va su Dev, nell'update set del lavoro.
I rilievi sono quelli che il validatore di SNForge restituisce per questi due frammenti, parola per parola.
Da dove viene lo schema
A ogni sincronizzazione SNForge copia dall'istanza le tabelle che descrivono la piattaforma. Il controllo non tira a indovinare: un nome o c'è, o non c'è.
sys_db_object sys_dictionary sys_choice sys_script_include sys_user_role sys_security_acl
Il gate dell'architetto
Anche il design passa lo stesso controllo. Se cita un campo che non esiste, l'architetto riceve l'elenco e riprova: tre tentativi in tutto. Poi il lavoro si ferma e dice quali simboli mancano, invece di costruire su un'ipotesi.
I dati del cliente restano del cliente
Istanze, requisiti e nomi delle persone non sono materiale da spargere in giro. SNForge è costruito partendo da qui.
Scrivinel tuo spazio
Maria Rossi (maria.rossi@cliente.example) chiede perché Luca Bianchi non riceve le approvazioni.
Parteverso il modello
⟦PERSONA_1⟧ (⟦EMAIL_1⟧) chiede perché ⟦PERSONA_2⟧ non riceve le approvazioni.
al modello esterno arrivano solo i segnaposto
Tornanella risposta
A Luca Bianchi manca il ruolo approver_user: aggiungilo e avvisa Maria Rossi.
La corrispondenza fra segnaposto e nomi veri resta in SNForge: il modello esterno non la vede mai.
Modello locale, di serie
Le domande sulla documentazione che non chiedono l'istanza le può rispondere un modello che gira sul server di SNForge, anche quando il modello esterno non c'è. I contratti software li legge soltanto lui: importi e firme non escono.
Clienti separati dal database
La separazione la fa Postgres, con la Row-Level Security forzata su ogni tabella. Un test fallisce se ne manca una.
Registro a catena
Ogni riga porta l'hash della precedente. Chi modifica o cancella una riga rompe la catena, e la verifica lo dice.
Numeri che puoi verificare
Niente percentuali di risparmio stimate. Sono fatti del prodotto, uguali per ogni cliente, con accanto il meccanismo che li rende veri; ogni conteggio ha data e fonte in misure.json.
-
0
scritture in Produzione senza una persona
Su Produzione SNForge prepara l'update set e si ferma. Il commit lo fa una persona, dentro ServiceNow.
-
5
ruoli, dal lettore all'amministratore
Ogni ruolo aggiunge qualcosa al precedente. Chi ha avviato un lavoro non ne approva la UAT e la Produzione, qualunque ruolo abbia.
-
18
tipi di dato mascherati prima di un modello esterno
Tredici sempre, cinque in più con il livello rafforzato. Il modello vede segnaposto come
⟦PERSONA_1⟧; i nomi veri tornano solo dentro SNForge. -
37
regole del validatore statico, senza modello
Ogni tabella e ogni campo del codice si cercano nello schema copiato dall'istanza del cliente. Le regole sono deterministiche: stesso codice, stesso esito.
-
10
agenti, e solo 2 scrivono sull'istanza
Lo sviluppatore scrive su Dev. Il responsabile del rilascio porta l'update set su Test e UAT, dopo l'approvazione. Gli altri otto non hanno il permesso di scrivere.
-
4.187
test automatici sul prodotto
Passati il 2 ottobre 2026 sulla versione in preparazione dopo la 1.5.2: permessi, separazione dei clienti, gate, mascheratura e testi nelle due lingue.
I moduli su cui lavora, oggi
L'elenco viene dal catalogo dei pacchetti del prodotto, non da una roadmap: per ogni modulo, lo stato e quello che c'è già. Quello che è ancora in prova lo dice.
IT Asset Management
3 moduli
-
Software Asset Management Pro
stabile
Dall'implementazione alla posizione di compliance, con fine vita e fine supporto dalla Content Library.
- 9 fasi di percorso guidato
- 13 analisi sull'istanza
-
Hardware Asset Management
in prova
Ciclo di vita dell'hardware dalla richiesta alla dismissione, e il dato che serve a SAM.
- 4 fasi di percorso guidato
- 2 analisi sull'istanza
-
Licensing dei publisher
in prova
Le regole di licenza di sette publisher, oltre a come ServiceNow le rappresenta.
- Microsoft
- Oracle
- SAP
- Adobe
- VMware
- Citrix
- IBM
- 36 procedure
- 2 analisi sull'istanza
Service Management
1 modulo
-
IT Service Management
stabile
Incident, Problem, Change e Request: implementazione, misura sull'istanza e procedure.
- 7 fasi di percorso guidato
- 7 analisi sull'istanza
Su ogni modulo
41 tipi di artefatto
- business rule
- script include
- client script
- UI policy
- ACL
- notifiche
- relationship
- catalog item
- transform map
- REST message
- e altri 31
La delivery non dipende dal pacchetto: ogni artefatto va nell'update set del lavoro. L'esempio in apertura è un incident.
Operations e dati
3 moduli
-
CMDB e CSDM
stabile
La salute del CMDB e l'adozione del CSDM, senza scrivere sul CMDB.
- 7 fasi di adozione del CSDM
- 11 analisi sull'istanza
-
ITOM e Discovery
in prova
Flow Designer, Discovery con pattern e MID Server, Agent Client Collector.
- 11 procedure
- da verificare su un'istanza
-
Sorgenti dati
stabile
Da dove arrivano installazioni e uso, e se la sorgente funziona ancora.
- SCCM
- Intune
- Jamf
- Agent Client Collector
- 2 analisi sull'istanza
- 7 procedure
Piattaforma
3 moduli
-
Amministrazione della piattaforma
stabile
Privilegi, modifiche, hardening, debito tecnico e upgrade, misurati sull'istanza.
- 18 analisi sull'istanza
- 9 procedure
-
Licensing ServiceNow
stabile
Quante licenze ServiceNow consumi oggi, con le definizioni di conteggio dell'istanza.
- 8 analisi sull'istanza
- 4 procedure
-
Fondamenta ServiceNow
stabile
Lo schema dell'istanza, letto prima di scrivere: tabelle, campi e choice si verificano lì.
- 1 analisi sull'istanza
- sempre attivo
stabile in prova sono lo stato che il catalogo dà a ogni pacchetto; in prova vuol dire beta. Ogni pacchetto scrive anche i suoi limiti.
Contati sul codice del 2 ottobre 2026, dopo la versione 1.5.2: catalogo dei pacchetti, percorsi guidati, registro delle analisi, procedure della knowledge, tipi di artefatto. La promozione fra Dev, Test e UAT è provata sul banco di prova; la prova su un Test e una UAT veri è la prossima.
Conosce l'istanza. Costruisce sullo schema. In Produzione decidi tu.
Per i team di delivery, per i consulenti con più clienti (uno spazio per cliente, con istanze, knowledge e regole separate) e per chi approva i rilasci.