Salesforce AI Agents: 5 Workflows Beyond Agentforce

Key takeaways
• A Salesforce AI agent reads and acts on Salesforce records with AI. You can buy Salesforce's Agentforce, or build your own over the REST API.
• Building your own wins when the agent has to reason across systems Salesforce doesn't own, Gong call signals, Slack policy, not just chat inside the CRM.
• The safe pattern: the agent reasons, but a deterministic, audited app executes every write. Nothing auto-sends; a human approves each action.
• Salesforce triggers are mostly polling-based, and per-transaction governor limits (100 SOQL / 150 DML) plus a 24-hour API allocation bound how often and how broadly the agent runs.

What a Salesforce AI agent is (and how it differs from Agentforce)

A Salesforce AI agent is a piece of software that uses a large language model to read Salesforce records, decide what to do, and take an action, scoring a lead, summarizing an opportunity, or drafting a follow-up. It reaches your data either through Salesforce's built-in Agentforce or through the Salesforce REST API. The difference that matters is where the agent runs and what else it can see.

Agentforce is Salesforce's own agent layer. It lives inside the CRM, is configured with clicks and prompts, and is excellent at conversational, in-CRM tasks at scale, a service agent answering customers, or a sales assistant a rep chats with in the flow of work. If your workflow starts and ends inside Salesforce, Agentforce is the straightforward choice.

Build-your-own is the alternative when the agent has to reason over systems Salesforce doesn't own. An agent over the REST API can join pipeline data with Gong call sentiment and Slack policy, run on your own schedule, and route every write-back through a layer you control. You give up the in-CRM chat surface; you gain cross-system reach and full control over identity, audit, and approval. The rest of this article is about that second path.

• Agentforce
• • Best for: Salesforce-only, in-CRM conversational chat at scale (service, in-flow sales assist)
  • Where it runs: Inside Salesforce
  • Cost model: $2/conversation or Flex Credits (~$0.10/action), see FAQ
  • Lock-in: Tied to Salesforce platform and licensing
  • Identity & audit: Salesforce-native identity and event monitoring; audit stays inside Salesforce
    
• AI Agent on Major Connected to Salesforce
• • Best for: Cross-system, scheduled, human-approved revenue workflows that span Salesforce, Gong, and Slack
  • Where it runs: Outside Salesforce, over a custom Salesforce MCP created by Major
  • Cost model: Salesforce API is included in your edition; you pay for build + runtime
  • Lock-in: Low, you own the agent logic and the connectors are configured once at the org level
  • Identity & audit: Run-as-invoker OAuth (the app calls Salesforce as the run's user); every write is an app-mediated, logged query with an audit entry exportable to your SIEM

When an AI agent over Salesforce actually helps

An agent over Salesforce earns its place when the CRM holds the records but the signal, or the action, lives somewhere else. If everything you need is already inside Salesforce, Agentforce or a Flow will usually do. The five workflows below all cross a boundary Salesforce doesn't own.

If you're weighing the same pattern on a different CRM, see our companion guide on AI agents for HubSpot.

Five use cases, by connector

• Opportunity-lifecycle agent, flags at-risk open deals by combining stage age, activity, and call sentiment, then drafts an AE follow-up. Connectors: Salesforce + Gong + Slack.
• Lead scoring agent, reads new Leads and recent touches, scores fit and intent, and writes a priority back to the record for routing. Connectors: Salesforce + enrichment source.
• RevOps pipeline digest, every morning, summarizes what moved, what slipped, and what needs attention, and posts it to a RevOps channel. Connectors: Salesforce + Slack.
• Account research agent, before a QBR or renewal, pulls account history and recent interactions and assembles a briefing for the owner. Connectors: Salesforce + Gong + docs source.
• Contract-close nudge agent, watches late-stage Opportunities and reminds owners of missing steps before close, drafting the nudge for approval. Connectors: Salesforce + Slack.

What you need to build one

Three things: a way into Salesforce's data, an agent to hold the reasoning, and a controlled layer to perform the writes. The data layer is the Salesforce REST API.

The Salesforce REST API in 200 words

You authenticate with OAuth 2.0, typically a connected app and an authorization flow that returns an access token, so the agent never holds a raw password. Your records are exposed as SObjects: every standard and custom object (Opportunity, Account, Lead, Task) has REST endpoints for create, read, update, and delete on individual records.

To read across records you use SOQL (Salesforce Object Query Language) via the query endpoint, a SQL-like syntax for filtering and joining related objects. When you need several operations in one round trip, the Composite resources let you batch multiple requests, or chain dependent ones, in a single call to save against your API allocation.

Before you run, check the /limits endpoint. It reports your org's remaining daily API calls and other allocations, so an agent can back off before it hits a wall. Read the auth and resource model in Salesforce's own REST API documentation rather than third-party summaries.

Pros and cons of the Salesforce API

What's good: it's mature, well-documented REST; SOQL is expressive; the API is included in your Salesforce edition, so there's no extra per-call licensing to read your own data; and OAuth plus connected apps give you real, revocable identity.

What will bite you: most off-the-shelf Salesforce triggers are polling-based, they run on an interval (for example, every few minutes) rather than firing instantly. (Instant, webhook-style variants exist but need extra setup like field-history tracking.) So state the cadence your agent runs on and don't expect real-time reactions. You're also bound by Salesforce's daily API request allocation, for Enterprise Edition it starts at 100,000 requests per rolling 24-hour period and scales with your provisioned licenses, and by per-transaction governor limits of 100 SOQL queries and 150 DML statements. Together these cap how often and how broadly the agent can run, so batch with SOQL and Composite and schedule deliberately.

A worked example: the Opportunity-Lifecycle Agent

What it does

Every weekday morning around 07:00 local, this agent finds open Opportunities that have sat in their current stage past a threshold, checks recent Gong calls on those accounts for warning signs, and decides which deals are at risk. For each one it drafts a follow-up for the account executive and posts a Slack approval card. Nothing is written to Salesforce until a human approves.

How the steps wire together

The build is a short ordered pipeline. The final write is the important part: it is an app query, not a raw agent action.

1. Scheduled trigger. A daily schedule fires on weekday mornings (~07:00 local). Salesforce triggers are polling-based, so this cadence, not an instant webhook, is how the agent runs.
2. SOQL pull. Query open Opportunities past a stage-age threshold, plus their Account and recent Activity, in as few SOQL calls as possible to respect governor and daily limits.
3. Enrich with Gong. For those accounts, pull recent call signals and sentiment from Gong, context Salesforce doesn't hold.
4. Reason. An LLM weighs stage age, activity, and call sentiment to flag at-risk deals and draft a concise AE follow-up and next step.
5. Slack approval. The agent posts an approval card to the deal owner in Slack with the draft and the proposed next step. The human approves, edits, or rejects.
6. On approval, call a typed Major app. Only after approval does the agent call a Major-built app, "Log Opportunity Next-Step" (inputs: opportunity_id, next_step, due_date), which performs the deterministic Salesforce write-back, a Task and a Chatter note. The agent never writes to Salesforce directly; the write is a typed, logged app query.

Every outbound action, the Slack send and the Salesforce write, runs through the scoped app and is gated by human approval. Nothing auto-sends.

What governance the agent needs

• Run-as-invoker OAuth. A shared agent calls Salesforce as the user who started the run, so Salesforce sees the right identity and RBAC mirrors upstream.
• Least-privilege scope. Read Opportunity, Account, and Activity plus Gong transcripts; the app writes Tasks and Chatter only; no delete.
• RBAC at the query layer. Permissions are enforced on the query itself, not bolted on after.
• Version pinning and rollback. The app is versioned; a bad change rolls back on one path.
• Audit per action. Every action lands as a logged query with an audit entry, exportable to your SIEM.

What this agent doesn't do: it doesn't replace the rep, it doesn't change stages or send email on its own, and it never makes raw, unaudited writes. It reads, reasons, and proposes; the human approves; the app executes within its scope.

Build this in Major

You just read the whole agent: the schedule, the SOQL pull, the Gong enrichment, the reasoning, the Slack approval, and the typed app that writes back. Major lets you build internal apps and the AI agents that act through them, with SSO, RBAC, and audit logs handled at the platform layer. The agent reasons; the app executes, both on one identity model, one audit trail, and one rollback path.

Connectors like Salesforce, Gong, and Slack are configured once at the org level by IT, not wired per app, so credentials live in one place and a rotate-or-revoke applies everywhere. That foundation, data and storage, integrations, security and governance, runtime and hosting, is handled once, so every generated app inherits it and ships production-ready.

This isn't theoretical. Harris Technology runs this class of cross-system reporting in production, weekly sales meetings and quarterly business reviews powered by Major, pulling from their Salesforce CRM and other systems and even generating the presentation, built and maintained by non-engineers, precisely because that L1–L4 foundation is owned once at the org level. Read the Harris Technology case study.

Want the same pattern on another system? See AI agents for Notion for another worked example.

Build your Salesforce AI Agent on Major today