Most Agentforce use-case lists are useless.

They’re written by people who’ve watched the keynote and nothing else, so you get “AI-powered customer engagement” and “intelligent lead nurturing” and other phrases that mean nothing when you sit down to actually build the thing. What you want to know is narrower: what an agent can do today, what it needs access to, and where it falls over.

So here’s the list I’d give a colleague. Ten processes, roughly ordered from safest to hardest. Each one includes the part nobody mentions.

1. Order status and shipping enquiries

The obvious one, and it stays at the top because it’s still the best first project. High volume, low risk, clean success metric.

The agent reads the enquiry, looks up the order, checks fulfilment status in your ERP, and replies. If the shipment’s late, it can proactively offer whatever remedy your policy allows.

The catch: your order data probably lives outside Salesforce. Without a working integration with your ERP or WMS, the agent has an opinion and no facts. Sort the pipe first.

2. Appointment scheduling and rescheduling

Field service, healthcare, professional services, anywhere a calendar and a customer collide.

An agent can check technician availability, respect skill matching, honour service territories, and rebook without a human touching it. Rescheduling, in particular, is a good candidate because it’s high-friction for customers and low-value for staff.

The catch: availability data has to be accurate in real time. If your techs update their calendars at the end of the day, the agent will book people who aren’t free.

3. Password resets and account access requests

Boring, constant, and a large chunk of tier-one volume in most B2B software companies.

The agent verifies identity against whatever your policy requires, triggers the reset, and confirms. It also knows when not to act on a request from an unverified channel and should escalate, not proceed.

The catch: this one is a permissions question dressed up as a service question. An agent that can reset credentials is a privileged actor. Getting the running-user model right here is the whole job, and it’s exactly the kind of design decision worth taking to an experienced Salesforce Consulting company before you build rather than after your first incident.

4. Lead qualification and routing

Inbound leads arrive, and someone has to decide whether they’re worth a rep’s time. That decision is usually made by scoring rules that were tuned in 2019 and never revisited.

An agent can read the enquiry text, enrich against Data Cloud, check for an existing account, apply your qualification criteria, and route. It handles the messy middle cases that rule-based scoring simply drops.

The catch: you need to write down your qualification criteria properly. Most sales orgs can’t. “We know a good lead when we see it” is not an instruction an agent can follow.

5. Quote generation and approval routing

CPQ is where a lot of deals go to die. Reps wait on approvals; approvers wait on context.

An agent can assemble a quote from a described requirement, apply the right price book, flag discounts that exceed thresholds, and route to the correct approver with a summary of why the discount is being requested. That last bit, the summary, is where it beats a Flow.

The catch: pricing logic is often the most bespoke code in a Salesforce org. Expect to write custom Apex actions to expose it. This is where firms doing Salesforce Development Services get pulled in, because standard actions won’t reach a pricing engine someone wrote seven years ago and left undocumented.

6. Contract and renewal management

Renewals are predictable, which makes them automatable, which makes it strange that so many are still chased manually.

The agent tracks upcoming expiry dates, checks usage or consumption data, drafts the renewal quote, and flags at-risk accounts where usage has dropped. It can also answer internal questions about contract terms by reading the document itself.

The catch: document grounding is only as good as your document hygiene. If contracts are attached inconsistently or stored in a shared drive that nobody has indexed, the agent has nothing to read.

7. Employee onboarding

Not a CRM process at all, which is precisely the point.

New hire starts. The agent creates accounts across systems, assigns the right permission sets, schedules orientation, sends the equipment request, and answers the hundred small questions every new joiner has about policy. Most of that is reachable via MuleSoft and Slack.

The catch: HR processes are cross-system by nature. The agent is the easy part; connecting to your HRIS, ITSM, and identity provider is the project.

8. Case triage and escalation

Different from case deflection. Here, the agent isn’t trying to resolve the case; it’s trying to route it correctly and enrich it before a human picks it up.

It reads the case, classifies it, checks entitlement and SLA, pulls the customer’s recent history, attaches a summary, and assigns it to the right queue. The human agent opens a case that’s already been prepared.

The catch: this quietly changes how your service team works. If people are used to doing their own triage, you’ll get resistance. Change management is a real line item.

9. Inventory and supply reconciliation

Stock discrepancies, backorder handling, supplier follow-ups. Deeply unsexy, expensive when it goes wrong.

An agent can monitor stock levels against demand signals, flag anomalies, draft supplier communications, and update affected orders. Teams at firms like DianApps have pointed out that the value here comes less from the agent’s cleverness and more from finally having one place where the data is unified which is a fair reading of most agentic wins, honestly.

The catch: requires Data Cloud doing real work. Without unified inventory data, you’re automating a guess.

10. Financial close support and revenue operations

The hardest on this list, and the one I’d approach most carefully.

Agents can chase missing documentation, reconcile line items against records, flag anomalies for review, and prepare summaries for finance. They should not be making journal entries unsupervised.

The catch: anything touching money movement or regulated reporting needs a human in the loop, an audit trail, and a very tight action scope. Do this one last, if at all.

The pattern underneath the list

Read those ten again and you’ll notice the catches rhyme.

Nearly every one comes down to the same three things: is the data actually available, is the permission model actually designed, and have you actually written down the rules you follow. The agent is not the bottleneck. It never is.

That’s also why the ordering matters. Start at one, get the plumbing right, and processes seven through ten become tractable. Start at ten because it looks impressive in a board deck, and you’ll spend six months discovering that your inventory data has four sources of truth.

FAQ

Which of these should we build first?

Whichever one has the cleanest data, not the biggest ROI. Your first agent project is really a data and permissions project wearing a costume. Pick something small enough that when it fails, and it will, early on, nobody important notices.

Can one agent handle several of these?

Technically, yes, via multiple topics. Practically, keep them separate at first. A single agent with twelve topics is very hard to debug when it picks the wrong one.

Do we still need Flow and Apex?

Absolutely. Agents call them. Deterministic automation isn’t going anywhere. If a process has no ambiguity, a Flow is cheaper, faster, and easier to test than an agent. Use agents where judgment is required, not everywhere.

How do we know it’s working?

Define the metric before you build. Deflection rate, time-to-resolution, and escalation rate are the usual three. If you can’t state the number you’re trying to move, you’re not ready to build.