Agentforce IT Service: Salesforce's Bid to Unseat ServiceNow in ITSM

Your VPN drops at 9 a.m., and so does everyone else's on the third floor. You open the IT portal, search a [knowledge article](/terms/knowledge-article) that does not match your problem, then file a ticket into a queue. It gets a number. Ninety minutes later a technician who has already seen this exact outage forty times this quarter picks it up and closes it. Multiply that by every employee on the floor, and you have measured the tax that traditional IT service management charges every working day.

That queue, that portal, that ticket number is the thing Salesforce spent 2026 trying to kill. Agentforce IT Service is Salesforce walking straight into ServiceNow's living room and claiming the $50 billion ITSM market as agentic territory. The pitch is blunt. Muddu Sudhakar, the SVP and GM running Agentic IT and HR Service, put it in one line: "The portal-to-ticket era is dead" (Salesforce Newsroom). This guide covers what the product actually is, how the architecture bet differs from ServiceNow, what the Summer '26 release added, and where the story still has holes.

What Agentforce IT Service actually is

Agentforce IT Service is a full IT service management platform built agent-first. It reached general availability in late 2025 and covers the standard ITSM disciplines you already know: incident, problem, change, and request management. On top of that sit autonomous agents that live where employees already work, meaning Slack, Microsoft Teams, email, web, and voice, rather than behind a separate self-service portal.

Underneath the agents are two pieces that decide whether any of this works: a Configuration Management Database (CMDB) and a Service Graph that maps dependencies across your infrastructure. Salesforce also ships more than 100 prebuilt connectors so the platform can read the systems it needs to reason about (Salesforce Ben). If you have run ServiceNow, none of those nouns are new. The CMDB, the change process, the dependency map are table stakes for enterprise ITSM. What is new is the front door.

The claim landed faster than most people expected. By February 26, 2026, Salesforce said more than 180 organizations had already selected Agentforce IT Service, roughly four months after it went live (Salesforce Newsroom). One named example, CoolSys, is replacing a legacy ServiceNow implementation outright. That is the headline Salesforce wanted, because it turns an abstract feature list into a concrete competitive story.

The portal-to-ticket era, and why Salesforce wants it dead

Start with what changes for the person with the broken VPN. The old model is a funnel: the employee describes the problem in a form, the form becomes a ticket, the ticket waits in a queue, a human triages it, and resolution happens somewhere down the line. Every step adds latency, and most tickets are repeats of tickets already solved.

The right side of that picture is the whole product thesis. The employee asks in the channel they already have open, and an agent resolves the request inside that conversation: reset the account, grant the access, restart the service, answer the policy question. No portal, no form, no number. The agent only reaches for a human when the request warrants it. Salesforce is explicit that the handoff is a design feature, not a fallback: if a request is highly complex or time-sensitive, a security breach for instance, Agentforce transfers the conversation to a person immediately (Salesforce Ben).

There is a second move hiding in here that matters more than the chat interface. The agent can act proactively. When a VPN problem starts hitting multiple users, the platform can detect the pattern and address it as one incident rather than forty tickets (Salesforce Ben). That is the difference between an IT desk that reacts to tickets and one that watches for problems. Whether it works at your scale depends entirely on the data underneath, which we will get to.

The architecture bet: one platform against two

Salesforce did not lead with features when it launched. It led with an architecture argument, and the argument is aimed straight at ServiceNow. Kishan Chetan, the EVP and GM for Service Cloud, framed it plainly: "Everything we've created lives on one unified platform," so data, configuration, agents, and workflows run across Slack, Teams, and other surfaces without living in separate systems (CX Today).

The distinction Salesforce is drawing is between one shared data-and-agent layer and the more common split where the employee-facing experience and the technician fulfillment platform are effectively two systems stitched together. In the one-platform version, the same agent that answers an employee has the same context an IT team member sees, because there is no seam to cross. In practice that context comes from Data Cloud, which unifies employee and infrastructure data so the agent reasons over a single picture rather than an API round-trip to somewhere else.

Is this a real advantage or a slide? Honestly, some of both. A unified data layer is a genuine benefit when it holds, because most ITSM pain is context that lives in the wrong place. But "one platform" is also the easiest thing in enterprise software to say and the hardest to prove at a customer's scale, especially when that customer already runs a decade of ServiceNow customization. Treat the architecture claim as the thing to test in a proof of concept, not the thing to take on faith.

What the Summer '26 release added

The launch platform was the opening move. The Summer '26 release, which shipped in June 2026, added the piece that makes the agent-first story concrete at scale: the IT Service Domain Pack. It delivers more than 50 specialized AI agents out of the box in Slack, Teams, and the IT Service Desk, built to detect intent and resolve employee needs across different specialist roles (Salesforce Newsroom).

That number matters for a specific reason. The hard part of any agent rollout is not building one agent, it is building the fiftieth. Most organizations that try to stand up their own agents stall after the first few because every new domain, whether access management, hardware, network, or software provisioning, needs its own actions, its own grounding, and its own guardrails. Shipping 50 of them prebuilt is Salesforce trying to move customers past the blank-page problem. You are meant to start from a working library and tune, not start from nothing.

Salesforce has not published a granular list of which specialist roles ship in the pack or exactly what each agent can do, so temper expectations. Out-of-the-box agents are a starting posture, not a finished implementation. The first thing your team will do with any of these is scope down what they are allowed to touch and wire them to your real systems of record. That work is the project. The prebuilt library just means you are not writing agent number one on day one.

The CMDB and Service Graph, which most demos skip past

Here is the part that will decide whether your rollout is a success or an expensive chatbot. The autonomous stuff, the proactive incident detection, the "resolve it in the conversation" promise, all of it runs on the quality of the CMDB and the Service Graph underneath. An agent can only reason about your environment as well as the map it is given.

If your configuration data is stale, if half your services are not modeled, if the dependency graph does not know that the payroll app depends on the VPN gateway that just failed, then proactive resolution degrades into confident guessing. This is the same trap that has swallowed ITSM projects for twenty years, and agents do not remove it. They raise the stakes on it, because now a bad map does not just slow a human technician, it teaches an autonomous agent to act on a wrong picture.

So the unglamorous prerequisite is the real work. Before you evaluate Agentforce IT Service on how well it chats, evaluate it on how it populates and maintains the CMDB, how its connectors discover your estate, and how the Service Graph stays current as your infrastructure changes. A polished agent on top of a hollow CMDB is a demo, not a deployment.

Salesforce versus ServiceNow: the honest scorecard

The reason this launch got covered at all is the matchup. ServiceNow effectively defined modern ITSM and owns the enterprise mindshare. Salesforce is the challenger here, which is a role it does not often play. So where does each side actually stand?

Salesforce's strongest cards are reach and starting posture. The company points to roughly 150,000 Salesforce customers and a Slack base near one million as latent demand it can convert, arguing there is a lot of unfulfilled appetite to sell into (Salesforce Ben). On the Service Cloud side specifically, Salesforce cites roughly 60,000 customers against ServiceNow's smaller footprint (CX Today). Its second card is that its agents were built in from the start rather than added to an engine designed in the ticketing era.

ServiceNow's cards are the ones incumbents always hold, and they are strong. Depth, maturity, and a decade or more of process customization that large IT organizations have built and will not casually throw away. The Register read the contest clean: the real winner of a ServiceNow-versus-Salesforce ITSM fight is AI itself, because both vendors are now racing to make agents the default interface, and pressure from a credible challenger tends to accelerate the incumbent (The Register). If you already run ServiceNow well, Agentforce IT Service is not an obvious rip-and-replace. If you are greenfield, or your ServiceNow install is a source of pain rather than pride, the calculus is different.

Where it bites, and what is still fuzzy

Three cautions before anyone signs anything.

First, pricing. Across the launch coverage, Salesforce did not publish clean public pricing for Agentforce IT Service, and the broader Agentforce move toward consumption and pay-per-resolution models makes IT service cost harder to forecast than a flat per-seat ServiceNow license. Get the specifics in writing from your account executive and model the consumption against your actual ticket volume before you commit a budget. An agent that resolves ten thousand requests a month is a different invoice than one that resolves a hundred.

Second, migration reality. The 180-organization number is real traction, but "selected" is not the same as "fully cut over from ServiceNow in production." Replacing an entrenched ITSM platform touches integrations, custom workflows, reporting, and a change-management process that dozens of teams depend on. CoolSys replacing ServiceNow is a strong proof point, and it is also one company. Ask for reference customers whose environment resembles yours in size and complexity, not just the flagship logo.

Third, the incumbent will not stand still. ServiceNow has its own agentic roadmap and a customer base with high switching costs. A challenger with better reach does not automatically win a market defined by process depth and integration inertia. The honest position in mid-2026 is that Salesforce has a credible, genuinely differentiated entry, strong early traction, and an unproven long-run displacement story. All three are true at once.

What to do now

If IT service is on your radar this year, run one scoping exercise before you take a single vendor demo. Pull last quarter's ticket data and sort it: what percentage of tickets are repeats of an already-solved problem, how many are simple access or reset requests a scoped agent could close, and how current is your CMDB really. That gives you two numbers that decide everything, the share of volume an agent could plausibly deflect, and the state of the data any agent would have to stand on.

Take those numbers into the evaluation. If your CMDB is a mess, fix that first regardless of vendor, because neither Salesforce nor ServiceNow can automate on top of a map that lies. If your deflectable volume is high and you already live in Slack, Agentforce IT Service earns a serious proof of concept. Scope it to one domain, one specialist agent, one real workflow, and measure autonomous resolution against your current queue before you talk about replacing anything.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.