Release3
01 · Batched in the right order.
Update sets are grouped into a release and sequenced by dependency — so nothing lands before what it needs.
Deploy
Sequence and promote every update set from one canvas.
Batch multiple changes, sequence every update set in the right order, and promote across instances from one canvas — with conflicts surfaced before you release. All driven from chat.
14.2%
Release the warranty claim change to acme-test — check for conflicts first.@ for records · / for commands
Build
acmedevProject
acmedevProject Batched 3 update setsOrdered by dependencyReady
Readiness checkVersions match · 2 conflicts resolvedPassed
ATF re-run12 / 12 passedPassed
Deploy to acme-testWaiting for your approvalApprove
Built for the platform
3,000+typed ServiceNow tools~230expert skill packsHundredsof health checks8acceleratorsISO 27001 certifiedPer-user OAuthApproval on every changeLands in your update setsATF on every build
What you can ask Deploy to do.
Sequence every update set, batch multiple changes, and promote across instances from one canvas — in the right order, with conflicts surfaced before you release. All driven from chat.
Batch · Asset return rollout3 update sets
1 · Asset return — data modelu_asset_return · 6 recordsReady
2 · Asset return — fulfilment flowdepends on 1 · 5 recordsReady
3 · Asset return — portaldepends on 2 · 3 recordsReady
devtestprod
Deploy
Batch these and ship them in the right order
Group related changes into a batch and Phyllis works out the order they have to ship in — respecting dependencies between update sets so nothing lands before the thing it relies on. One batch, sequenced, ready to promote.
Pre-flight · batch 72 fixed
sys_script · Validate return datenewer version already in testConflict
→ Merged, kept the newer conditiondiff reviewed · ATF re-run 6 / 6Fixed
sys_ui_policy · Return reason mandatorysame record in two update setsConflict
→ Collapsed into update set 3one owner · no duplicateFixed
Deploy
Is this batch safe to promote?
Before anything reaches your next instance, Phyllis checks the batch for collisions, missing dependencies and records newer on the target — then she holds or resequences so you promote knowing exactly what will land, and what won't.
Pre-flight · target: prodAwaiting approval
Instance ScanClean
ATF12 / 12 passed
Conflicts0 open
Rollback planAttached
Promote to prod?Platform owner
Approve & promoteReject
Deploy
What if it breaks in prod?
Nothing promotes blind. Phyllis previews the update set against the target, scans for conflicts and missing dependencies, and stages a rollback path — every promotion waits on your approval, so a bad change never reaches production unseen.
How Deploy works. Step by step.
Readiness · acme-testOK
02 · Conflicts surfaced first.
Preview conflicts are found and resolved, and the release versions are checked on the target before anything moves.
acme-testacme-prod
03 · To test, on your approval.
Approve in chat and watch a live progress card. Production is promoted from your Deployments page.
Dev to test from chat. Production stays yours.
Buildacme-dev
✓3 update sets complete
✓Instance Scan clean
✓ATF 12 / 12
From chat · on approval
Test / UATacme-test
✓Readiness check passed
✓Release versions match
✓Live progress card
Deployments page
Productionacme-prod
·Your change process
·Your approvers
·Your window
Phyllis releases to test and UAT from chat. Production is promoted from your Deployments page, under your change process — by design.
One canvas, every environment.
Sequence and batch update sets, surface conflicts before they bite, and promote across instances in the right order — all driven from chat.
Conflicts surfaced before release
Promoted across instances in order
Batch · Asset return rollout3 update sets
1 · Asset return — data modelu_asset_return · 6 recordsReady
2 · Asset return — fulfilment flowdepends on 1 · 5 recordsReady
3 · Asset return — portaldepends on 2 · 3 recordsReady
devtestprod
Deploy, across the platform.
PLAT-301: Vendor Risk Register App6 records
Vendor assessment table + fieldsTableCreate
Risk-tier mandatory form ruleUI PolicyCreate
Auto-assign Critical business ruleBusiness RuleCreate
Escalate to Critical buttonUI ActionCreate
Ready to deploy?6 records — 6 to create
Approve & DeployRejectEsc to go back
Platform
Custom apps that ship themselves — modelled, automated, secured, and staged for approval.
Phyllis builds and extends complete custom applications — any data model, automation or access model — grounded in your live instance and staged for your approval.
Read the use caseCS-318: Billing Dispute Case Type6 records
Billing Dispute case recordCase TableCreate
Case type registrationCase TypeCreate
New to Closed lifecycleState FlowCreate
Platinum tier assignment ruleAssignment RuleCreate
Ready to deploy?6 records — 6 to create
Approve & DeployRejectEsc to go back
CSM
Implement CSM
Case types, health scoring, success plays, risk definitions — the full customer success framework, built and staged.
Read the use caseINT-118: Jira Outbound Integration5 changes
OAuth authentication profileAuthenticationCreate
Jira outbound connectionConnectionCreate
Create-ticket and status methodsHTTP methodCreate
Portable connection aliasConnection aliasCreate
Ready to deploy?5 changes — 5 to create
Approve & DeployRejectEsc to go back
Integrations
External systems that connect, retry, and stay in sync — without hand-built plumbing.
Phyllis builds and extends your entire integration layer — any connection, credential or retry rule — grounded in your live instance and staged for your approval.
Read the use caseDeploy, answered.
Can Phyllis deploy to production?
Not from chat. Phyllis releases to test and UAT from chat, on your approval. Production is promoted from your Deployments page under your change process.
How are conflicts handled?
Preview conflicts are surfaced and resolved before the release moves, and the release versions are checked on the target.
What order do update sets go in?
By dependency — Phyllis sequences the batch so nothing lands before what it needs.
Is there a record of what moved?
Yes. Every release shows its progress live, and approvals are recorded in the audit log.
The rest of the lifecycle.
One teammate from the first question to a promoted, tested change.
CMDB health scorecardcmdb_ci · 48,213
68of 100
CriticalDuplicate servers across SCCM and Discovery2,114 CIsFix with Phyllis
Analyze
Ask your instance anything
Phyllis grounds herself in the full context of your ServiceNow instance — its tables, ACLs, flows, update sets, configurations, and dependencies. Every answer is evidence-backed and traceable to the records it came from.
Explore AnalyzeImplement ITSM · 24 storiesITSM-101
ITSM-102Incident categories & assignment rulesDone5
ITSM-103Major incident workflowReady8
ITSM-104Change CAB approvals by riskReady5
ITSM-105Problem → known error handoffPlanned3
ITSM-106SLA definitions for P1–P4Draft3
Plan
From a sentence to a sprint-ready backlog
Say “I want to implement ITSM” and Phyllis returns sequenced stories with priorities, points, and acceptance criteria — synced both ways with Jira or ServiceNow Agile 2.0.
Explore Plansys_script · P1 network auto-assign+6 −0
1(function executeRule(current, previous) {
2 if (current.priority != '1') return;
3 var onCall = new OnCallResolver().forGroup('Network Ops');
4 if (!onCall) return;
5 current.assigned_to = onCall.user;
6 gs.eventQueue('network.p1.page', current, onCall.user);
7})(current, previous);
Update setFeature: P1 network auto-assign
ATF12 / 12 passed
Develop
The whole change, built in your instance
Phyllis develops on the platform — from tables, business rules, flows, and ACLs to the records behind them — then verifies and tests every change.
Explore Develop
