Agentforce Grid: running AI on ten thousand records without writing a batch job

You can get an Agentforce agent to read one support transcript and draft a knowledge article in about thirty seconds. Everyone has done that demo. The problem starts at the next question the room asks: can you do that for the last quarter’s 40,000 transcripts? Because the honest answer, until recently, was “yes, but not in this tool.” You’d write an Apex batch, wire a prompt template into it, handle governor limits and callout chunking, and babysit a job that runs for an hour. Or you’d export a CSV, run it through something outside the platform, and re-import — losing the grounding, the trust layer, and the audit trail on the way out and back.

That gap — between a brilliant single-record AI task and the same task run across a whole object — is exactly where most AI-at-scale ambitions quietly die. Agentforce Grid is Salesforce’s answer to it: a spreadsheet-shaped workspace where each row is a record and each column is a step, and you run your existing prompts, actions, and agents across thousands of rows in one pass. It shipped as an open beta in the Winter ‘26 timeframe, and it’s the missing back-office half of the Agentforce story — the batch counterpart to the conversational agent. This post is what it actually is, the three column types that do the work, the compounding trick that makes it more than a mail merge, and the credit math you need to model before you press run.

The one-off problem, stated plainly

A conversational agent is a great interface for one user with one request in one moment. It is a terrible interface for “apply this judgment to every open opportunity older than 90 days.” Nobody wants to have 6,000 individual chats. The work is real, but it’s bulk work — and bulk work wants a bulk surface.

The instinct is to reach for Flow. Flow is the right tool when the logic is deterministic: if amount > X and stage = Y, do Z. It stops being the right tool the moment a step requires judgment — read this transcript and decide which of eleven themes it belongs to; look at these three fields and write a one-line risk rationale a human would agree with. That’s an LLM call, and threading an LLM call through a scheduled Flow across tens of thousands of records, with results that feed the next step, is a lot of plumbing to build and own.

Grid collapses that plumbing into a grid you can see. As the Salesforce team frames it, Grid delivers two capabilities that a one-off prompt can’t: bulk execution — run the same step across every row at once — and compounding workflows — let each column build on the columns before it. Those two ideas are the whole product.

What Grid actually is

Grid borrows the interface everyone already knows. A workbook contains worksheets; a worksheet is a table of rows and columns. The reframe for AI is what each axis means:

• Rows are jobs. Each row is one record — an opportunity, a case, a contact, a Data 360 profile — and every row runs independently through the same pipeline of columns.
• Columns are steps, evaluated left to right. The worksheet processes like a formula sheet: column A resolves, then B (which can reference A), then C, and so on across the row.

You populate rows by importing records natively from CRM or Data 360 — pick an object and the fields you want, or paste a raw SOQL query to pull exactly the set (including related lists) you mean to operate on. Each returned record becomes a row. That’s the part that quietly matters: Grid reads from standard Salesforce objects and Data 360 data model objects directly, so you’re not exporting anything. The data — and the governance around it — stays on-platform. If you’ve been following the Data 360 grounding story, Grid is where that unified data becomes something you can operate on in bulk, not just query.

The three column types

Every column is one of three kinds. Learning the difference is learning the tool.

1. Data columns. These pull information in. A data column queries a standard object or a Data 360 DMO, runs a SOQL lookup, or grabs a related list — the same way you seeded the rows, but now as an enrichment step mid-worksheet. Use them to bring a related account’s industry, a contact’s last three cases, or a profile’s calculated insight into the row so a later column has something to reason over.

2. Action columns. These do things. An action column can calculate a formula, run one of your existing Agentforce actions, or update the source record. That last capability is the one that turns Grid from an analysis toy into an operations tool — and the one that deserves a second look before you run at scale (more below). This is where the output of the AI columns gets written back to Salesforce.

3. AI columns. These apply judgment. An AI column can run an inline prompt you type right there, invoke one of your existing prompt templates, or run one of your existing Agentforce agents against the row. This is the reuse story that makes Grid worth adopting: the prompt template you already built and grounded for a live agent, or the agent itself, runs unchanged across ten thousand rows. You don’t rebuild your AI logic for batch — you point batch at the logic you already trust.

Put concretely, a “turn support transcripts into FAQ candidates” worksheet might look like this, left to right:

Row source:  SOQL → Cases closed last quarter with a transcript
Col A (Data): pull the transcript text from the related conversation record
Col B (AI):   prompt template "classify into one of 11 support themes"
Col C (AI):   inline prompt "write a one-sentence customer-facing question this case answers"
Col D (AI):   agent "draft a 120-word KB answer grounded on our help library"
Col E (Action): formula → flag rows where Col B = "billing" for human review
Col F (Action): update record → write the draft to a custom field for editorial approval

Six columns, one pass, every closed case in the quarter. The RevOps and support examples Salesforce leads with — turning thousands of transcripts into FAQ drafts, bulk-updating stale opportunities without nagging account executives, scoring and routing high-value leads without a manual CSV round-trip — are all this same shape: import a set, enrich it, judge it, write the result back.

Compounding is the part that isn’t a mail merge

If Grid only ran one prompt per row, it would be a nicer Data Loader. The reason it’s more is that columns compound. Column D in the example above drafts an answer, but it can only do that well because Column A fetched the transcript, Column B classified the theme, and Column C distilled the question. Each step’s output is available to every step to its right. You’re not running one AI call per row; you’re running a small, legible pipeline per row, and you can see the intermediate results in the cells rather than debugging a black-box batch job from its logs.

This is the same discipline that separates a reliable agent from a plausible one: make the intermediate reasoning visible and testable before you scale it. We’ve argued the same point about document grounding and about testing agents before production — perfect the logic on a small, visible sample, then run it across the corpus. Grid bakes that order into the interface. Build the worksheet on 20 rows, read the cells, fix the column that’s wrong, then import the full set.

Where Grid fits — and where it doesn’t

Grid is not a fourth thing competing with Flow, Apex, and agents. It’s a different shape of work. A quick placement:

• Conversational, one record, real time → an Agentforce agent. A customer or employee in a chat.
• Deterministic, event-driven, no judgment → Flow. Record-triggered automation where the rules are fixed.
• Bulk, judgment-heavy, run-on-demand → Grid. “Apply this AI step to this whole set, now.”
• High-scale, low-level, or complex transactional logic → Apex. When you’ve outgrown the low-code surfaces entirely.

The decision that used to send you to Apex — “I need an LLM in a loop over a large object” — is now often a Grid decision instead. That’s the practical shift. If you’ve mapped your automation choices with our Flow, Apex, or Agentforce guide, add Grid to the “bulk generative work” branch.

One more placement worth stating: Grid pairs naturally with Data 360. The rows can be Data 360 DMOs, which means the unified, resolved profile — not the raw, duplicated CRM record — is what your AI columns reason over. If your org is still deciding whether it needs Data Cloud under Agentforce at all, our dependency map is the place to start; Grid is one more reason the answer tilts toward yes for data-heavy bulk work.

The credit math nobody models until the invoice

Here’s the gotcha, and it’s an arithmetic one. Grid runs on Flex Credits, the same consumption currency as the rest of Agentforce — and the meter turns on per AI or action column, per row. That multiplies fast. A worksheet with three AI columns run across 40,000 rows is not 40,000 billable operations; it’s closer to 120,000, before you count data lookups and record updates. The mail-merge mental model (“one run”) is exactly the wrong one for forecasting the bill.

Salesforce clearly saw this coming, because Grid ships with a built-in Billing Calculator that gives you a real-time, credits-per-row estimate before you run at scale. Use it. It is the single most important button in the tool, and the discipline is simple: build and validate on a 20-row sample, read the calculator’s per-row number, multiply by your real row count, and decide whether the full run is worth it before you press go. If you want the underlying mechanics of how Flex Credits are priced and consumed, we cover the Agentforce credit model in detail — and the ROI calculator is a sane place to sanity-check whether a given bulk job pays for itself.

The failure mode to avoid is the one we see with every consumption-metered feature: someone builds a worksheet that works, imports the entire object “to be thorough,” and discovers the cost after the fact. Filter your row set at the source. You almost never need every row — you need the ones that changed, the ones in a stage, the ones missing a field. A tight SOQL WHERE clause is a cost control, not just a convenience.

Governance: it writes to your records

Read this part twice, because it’s the one that bites. An action column can update the source record, which means a worksheet you run is a bulk write against production data. The blast radius of a wrong formula or a mis-grounded AI column isn’t a bad chat message — it’s thousands of records changed at once. Treat a Grid run like a deployment, not like a query.

The guardrails are the ordinary ones, applied with more care:

• Sandbox first. Build and run the full worksheet in a sandbox against representative data before it touches production. The same sandbox discipline you’d apply to a metadata change applies here.
• Permissions still gate everything. Grid operates as a user; field-level security, sharing, and object permissions constrain what a column can read and write. It is not a bypass. Scope the running user deliberately.
• Stage the write. Where you can, have the AI columns write to a draft or review field and gate the final update behind a human or a separate approval step, rather than overwriting the live field of record in the same pass. The FAQ example above does this on purpose — it writes to an editorial-approval field, not straight to published knowledge. This is human-in-the-loop design, applied to batch.
• Keep the sample. The visible intermediate cells are your audit trail for why a row got the value it did. Don’t delete the worksheet the moment the run finishes.

What “beta” means for your plan

Grid is in open beta, and that word carries real caveats. Beta features can change shape between releases, may carry usage limits that shift, and are not the thing to bet a quarter-end process on this month. The right posture is to pilot: pick one genuinely bulk, genuinely judgment-heavy job — the transcript-to-FAQ backlog, the stale-opportunity cleanup, the lead-scoring pass you keep doing by hand — build it on a sample, model the credits, and run it once end to end in a sandbox. You’ll learn more about whether Grid fits your operations from one real worksheet than from any amount of reading, this post included.

Takeaways

• Grid is the batch surface for AI, not a new agent. Rows are records, columns are steps, and the whole worksheet runs left to right, per row, in one pass.
• Three column types do the work: data columns pull information in, AI columns apply judgment (reusing your existing prompt templates and agents), action columns write results back — including updating the source record.
• Compounding is the value. Each column builds on the ones before it, and the intermediate cells are visible, so you debug a pipeline instead of a black-box batch job.
• Model the credits before you run. Cost scales with AI/action columns × rows. Use the built-in Billing Calculator, validate on a sample, and filter your row set at the source.
• A run is a bulk write. Sandbox first, respect permissions, stage the write behind review, and treat a Grid execution with the seriousness of a deployment.
• It’s beta. Pilot one real job; don’t yet hang a critical recurring process on it.

The through-line of the whole Agentforce story in 2026 is that the unit of work keeps getting bigger — from a single prompt, to an agent, to a team of agents, and now to a whole object processed at once. Grid is that last step made visible. The teams that get value from it will be the ones who treat it like what it is: a powerful bulk-write tool with an LLM in the loop, priced by the cell.