Skip to content
SNForge

Agents build. You decide what reaches Production

SNForge is agentic delivery for ServiceNow. It takes a requirement all the way to Production: solution, update set, checks, ATF tests and promotions from Dev to Test, UAT and Production. Agents do the repetitive work. A person stands behind every decision that matters.

Request a demo See how it works
sn_forge Test customer/LAV-142 runningwaiting for a personin Production
A sample run, from requirement to Production. It stops there until a person decides.

Delivery time doesn't go into the code

It goes into requirements to clarify, update sets to piece together, tests to write and promotions to prepare. SNForge takes that part and does it the same way every time.

  1. TodayRequirements get clarified in the first UAT round.

    With SNForgeThe analyst asks the questions before anything is built.

  2. TodayUpdate sets are pieced together by hand, and something gets left out.

    With SNForgeOne update set per run, compared with the target instance.

  3. TodayATF tests get written at the end, if there's time left.

    With SNForgeTests come from the requirement and run on the instance.

  4. TodayPromotions are prepared from memory.

    With SNForgeEvery environment has its gate: who decides, what's missing, what's already tested.

How it works

A run starts from a requirement, written in chat or in a document, and always takes the same five steps. Each one leaves a trail you can read back.

  1. Requirement

    The analyst extracts goals, constraints and acceptance criteria, and asks what's missing before anything is built.

    Decided by whoever started the runAcceptance criteria

  2. Solution

    The architect proposes the solution from the instance's real schema and the module's knowledge, and states the risks.

    Decided by an approverSolution document, exportable to Word

  3. Build

    The developer builds on Dev in a dedicated update set. The reviewer checks the code and the customer's rules.

    Done by agents, with checkssys_update_set, one per run

  4. Verification

    ATF tests come from the requirement and run on the instance. The results stay attached to the run.

    Done by agents, with checkssys_atf_test, with results

  5. Promotion

    Test, UAT and Production, each behind a human gate, with a comparison against the target instance and a draft change request for the CAB.

    Decided by approver and release managerchange_request, draft for the CAB

Whoever starts it doesn't approve it. The person who started a run can't approve its promotion to UAT or Production. And nothing is written to Production without a person.

What's inside

One workspace per customer, with its instances, its knowledge and its runs.

Chat with cited sources

Questions about the platform and the customer's instance, with a source for every answer. On the instance, read-only.

Agentic runs

From requirement to update set, one update set per run. The cost of every run and every model call is recorded.

Checks and ATF tests

Code review, customer rules and ATF tests generated from the requirement, with results attached to the run.

Customer documents

Solution document and draft change request for the CAB, exportable to Word.

Modules such as SAM Pro

Ready-made procedures and analyses for modules such as SAM Pro, with measurements read from the instance.

Portfolio and approvals

All customers in one view: pending decisions and for how long, this week's releases, instance health.

Italian and English

Interface and messages in both languages, for teams working with different customers.

Customer data stays the customer's

Instances, requirements and people's names aren't something to scatter around. SNForge is built starting from there.

Anonymization toward an external model: names and addresses become placeholders, and go back in place in the answer.

You writein your workspace

Maria Rossi (maria.rossi@cliente.example) asks why Luca Bianchi isn't getting approvals.

Sentto the model

⟦PERSONA_1⟧ (⟦EMAIL_1⟧) asks why ⟦PERSONA_2⟧ isn't getting approvals.

the external model only gets placeholders

Backin the answer

Luca Bianchi is missing the approver_user role: add it and let Maria Rossi know.

The mapping between placeholders and real names stays in SNForge: the external model never sees it.

  • Local model for the knowledge

    Knowledge questions can stay on a model running inside the infrastructure, without leaving it.

  • Customers kept apart by the database

    Every row belongs to one customer, and the database itself enforces the separation.

  • Production protected

    Human gates on Test, UAT and Production. Whoever starts a run doesn't approve it, and the commit to Production stays manual.

  • Hash-chained log

    Every decision and every write to the instance goes into a hash-chained log that can't be altered afterwards.

  • Clear roles

    Each person sees and does only their part.

    viewer operator approver release manager administrator

For people who work on customer instances

Delivery teams

Less repetitive work between requirement and update set, more time for solution choices.

Consultants with several customers

One workspace per customer, with separate instances, knowledge and rules, and a portfolio that holds them together.

Release managers and the CAB

Every promotion arrives with its tests, the comparison with the target and a draft change request.

Let's look at a real case

Thirty minutes on a test instance: a requirement, the solution, the update set and the chain all the way to Production.

Request a demo Already have access? Sign in

Or write directly to info@snforge.com.