Forem: Dipojjal Chakrabarti

Setup with Agentforce (Beta): The Admin Tool I Didn't Know I Needed

Dipojjal Chakrabarti — Wed, 29 Apr 2026 23:07:02 +0000

Setup with Agentforce (Beta): The Admin Tool I Didn't Know I Needed

How many times have you opened Setup, typed something into the Quick Find box, and then sat there for a second wondering if you spelled "Permission Set Group" correctly? I do this at least three times a week. After fifteen years of clicking through the same menus, my muscle memory still betrays me when Salesforce moves things around.

That's why I've been spending most of my evenings poking at Setup with Agentforce, the new beta feature that landed properly in Spring '26. It's basically a chat panel that sits inside Setup and lets you ask questions or request changes in plain English. I was skeptical at first because I've seen plenty of "AI inside the platform" demos that turn out to be glorified search bars. This one is different, and I think it's worth your time even if you only have a sandbox to play with.

What Setup with Agentforce Actually Does

Strip away the marketing language and here's the deal. Setup with Agentforce is a chat agent embedded into the Setup home page. You ask it things like "Does Priya Mehta have access to the Opportunity object?" or "Create a custom field on Account called Renewal Owner that's a lookup to User," and it does the work, with your approval before anything saves.

I've been using it to handle the boring parts of my job. User access audits, the kind where someone in support pings you in Slack and asks why a rep can't see a record. Normally that's a fifteen minute trip through Profile, Permission Sets, sharing rules, and role hierarchy. With the agent I just type the question and it walks me through the answer. I still verify what it tells me because it's beta, but it gets me 80 percent of the way there in seconds.

The other big use case for me has been formula debugging. There's now a Use Formula Assistant button that pulls up the agent inside the formula editor. I pasted in a nasty CASE statement that was returning the wrong account tier, and it identified that I had a stray comma flipping the logic. That alone is worth turning the feature on.

If you want a quick refresher on what permission sets versus permission set groups are, I keep a tab open to salesforcedictionary.com when I'm troubleshooting. Their definitions are short enough to scan during a call.

Turning It On Without Breaking Anything

The activation flow has a few prerequisites that aren't obvious if you skim the release notes. Here's what I had to do in my dev org, in order.

First, your org needs to be on Enterprise, Performance, Unlimited, or Developer Edition with Foundations or one of the Agentforce 1 SKUs. Foundations is free, so most orgs qualify. Then Data Cloud has to be enabled because the agent uses Data 360 for context, plus Einstein Generative AI needs to be on. None of these are huge lifts but they do mean you can't just flip one toggle.

For permissions, you need Customize Application and the Data Cloud User permission set to enable the feature. Then anyone who actually wants to use the agent needs the Use Setup with Agentforce permission, the Execute Prompt Template permission, and access to the Data 360 default data space. I made a permission set called "Agent for Setup Users" and bundled all of these together so I can hand it out without thinking.

Once you toggle "Turn On Setup with Agentforce (Beta)" and refresh, you'll see an "Ask Agent for Setup" button appear in the Setup home page. Click it, and the chat panel slides in from the right. The first time you use it, give it a simple read-only task like "list users created in the last 30 days" so you can see how it formats responses before you let it touch metadata.

Real Tasks Worth Trying First

I've kept a running list in my notes app of things the agent has handled cleanly versus things it stumbled on. Here's what I'd recommend trying in your sandbox during your first hour with it.

User access audits work great. "Why can't Marcus see this opportunity record?" returns a structured answer that walks through profile, role, sharing rule, and account team membership. It's better than my own checklist because it doesn't skip steps when I'm tired.

Custom object and field creation is solid for simple requests. I asked it to build a "Customer Health Check" custom object with five fields including a picklist and a formula, and it generated the metadata correctly. It even suggested making the formula field a dependent on another field I had already created, which I would have missed.

Flow drafting is where I have mixed feelings. The agent can scaffold a record-triggered flow if you describe what you want, but for anything beyond two or three elements I still prefer to drag things in Flow Builder myself. The agent's drafts are a decent starting skeleton but you'll want to review every decision element and fault path before activating.

Formula debugging, as I mentioned, is the killer feature for me. Paste in any formula that's misbehaving, ask "what's wrong with this," and it'll walk through the logic step by step. This alone has saved me probably an hour a week.

For sharing rules and permission set groups, the agent can read your current setup but I'd think twice before letting it create new ones in production without a human review. Sharing model changes have a habit of cascading in unexpected ways, and beta software plus org-wide defaults is a combination I'd rather not test on a Friday afternoon.

Things to Watch Out For

Because this is beta, and because we're talking about an AI agent that can modify your org, there are a few guardrails worth knowing about.

Every change the agent makes shows up in the Setup Audit Trail. This is non-negotiable for me. Before I gave anyone else on my team access, I confirmed I could trace every single create/update/delete back to a user and a prompt. If you're in a regulated industry or you have a strict change management process, talk to your IT folks before you let admins use this in production. The audit trail is there but you'll want to define how you'll review it.

The agent only takes actions you have permissions for. So if your junior admin uses it, they can't accidentally delete a permission set group they wouldn't have been able to delete manually. That's a relief, but it also means you should keep your permission set hygiene tight before you roll this out widely. If your team has been a little loose with Modify All Data, now is the time to clean that up.

There's also a context limit. Long, complex requests that touch multiple objects sometimes get truncated. I've found it works best when you break a big task into 2-3 prompts instead of one giant one. Think of it like working with a junior admin who's smart but needs scoped instructions.

If you need to look up the difference between concepts like Org-Wide Defaults and Sharing Rules while you're working through a tricky permissions question, salesforcedictionary.com has plain-language definitions for both. I've found it useful for quickly explaining concepts to junior admins on my team.

What This Means for the Admin Role

Every time a feature like this ships, someone in the comments asks if admins are about to be automated out of a job. I don't think so, but I do think the day-to-day is going to change.

The grunt work, like running access audits, building simple objects, debugging formulas, gets faster. That frees you up for the stuff that actually requires judgment. Designing a sharing model that scales with your business. Having the conversation with sales ops about why their proposed automation is going to break the lead routing for marketing. Sitting with a stakeholder and figuring out what they actually need versus what they asked for. None of that goes away, and frankly Agentforce can't do any of it.

What I do think changes is the bar for entry-level admin work. If you're three years in and your skills are mostly "I know where everything is in Setup," it's worth investing in the harder parts of the role. Data architecture, integration patterns, change management, security models. Those are the things that compound over a career, and they're the things AI agents are going to be slow to replace.

I've also started using the agent as a teaching tool with newer admins on my team. Instead of telling them how to do something, I have them ask the agent and then we discuss what it suggested and whether it's the right approach. It's been a surprisingly effective way to talk through tradeoffs. The salesforcedictionary.com glossary pairs nicely with this because we can pull up a term and discuss it on the spot.

Should You Turn It On in Production?

My honest answer: not yet, unless you're a small org with a tight admin team and good change management discipline. The feature is genuinely useful but it's also beta, which means it might change between releases, and there's no SLA on it. Set it up in a developer org or a sandbox first. Spend a couple of weeks running real tasks through it. Build your permission set strategy. Decide what categories of work you'll allow the agent to do and what you'll keep manual.

Then, when you do roll it out in production, start with the read-only stuff. User access lookups, formula debugging, metadata exploration. Once the team is comfortable with that, expand to write actions like custom field creation. Save sharing rule changes and flow creation for last, and even then, require a peer review before anyone activates anything the agent generated.

Have you tried Setup with Agentforce yet? I'd love to hear what's worked for you and what's frustrated you. Drop a comment with your experience, especially if you've found a use case I haven't thought about. And if you're still on the fence, set up a developer org tonight and give it twenty minutes. That was all it took for me to get hooked.

Agentforce for Flow GA: Build Salesforce Flows With AI

Dipojjal Chakrabarti — Wed, 29 Apr 2026 14:39:41 +0000

Agentforce for Flow GA: Build Salesforce Flows With AI

If you've ever stared at a blank Flow canvas at 4:55 PM on a Friday wondering how to translate a vague stakeholder request into a working record-triggered flow, you're going to want to pay attention. In Spring '26, Salesforce moved Agentforce for Flow into general availability, and it changes how I approach flow building day to day.

I've been using it on real client orgs for a few weeks now. It's not perfect, and it's not going to replace experienced admins. But it does shave a meaningful amount of time off the kind of flow building most of us do every week. Here's what I've learned, what works well, and where you should slow down before trusting the output.

What Agentforce for Flow Actually Does

Agentforce for Flow is a conversational assistant that lives inside Flow Builder. You describe a business process in natural language, and it generates the flow for you. Now in GA with Spring '26, it covers record-triggered, schedule-triggered, and screen flows. You can also use it to modify existing flows by typing prompts like "add an email alert when the case priority is high" instead of dragging elements around.

The bigger upgrade in this release is accuracy. The team called it out specifically as "Get More Accurate Draft Flows" and it ships GA, not beta. They also confirmed flow generation does not burn AI credits, which removes one of the main hesitations admins had about using the beta.

In practice, when you open Flow Builder you'll see an Agentforce panel on the side. Type something like "When a case is created with priority High, assign it to the Tier 2 queue and post a Slack message to the support channel" and it scaffolds the flow. Decisions, assignments, and the action you need are placed on the canvas with a highlight color so you can see exactly what was added.

If you're new to some of the terminology around record-triggered flows, scheduled paths, or invocable actions, salesforcedictionary.com has a solid plain-English glossary that I keep open in another tab when I'm onboarding junior admins.

How to Get Started in Spring '26

The setup itself is straightforward but there are a few prerequisites that tripped me up the first time. You need Agentforce enabled in your org, the Einstein Generative AI permission set assigned to anyone using it, and your Data Cloud usage approved if you want it to reference custom metadata. Most production orgs already have these in place by Spring '26, but sandbox refreshes can sometimes lose the assignments.

Once you're in Flow Builder, click the Agentforce icon and pick whether you want to draft a new flow or modify the current one. The trick I've found is being specific about objects and field API names when you can. "Update the Account" is fine, but "Update the Account.Customer_Tier__c field to Gold when total ARR exceeds 100000" generates something much closer to what you actually want.

A small but useful detail in Spring '26 is that the canvas now supports panning with arrow keys and mouse scroll. Combined with collapsible decision branches and on-canvas performance metrics showing run counts and status distributions, the whole experience of reviewing AI-generated flows is much less painful. You can spot a bottleneck or a misrouted decision branch in seconds instead of clicking through every element.

I'd recommend running the agent against a complex existing flow first, just to see what it picks up and what it misses. It's a cheap way to calibrate your expectations before you start trusting it on net-new builds.

Practical Use Cases I've Tried

The use cases where Agentforce for Flow has saved me real time are the ones I'd describe as "obvious but tedious." Building a scheduled flow that runs every Monday at 6 AM to recalculate a custom field on Opportunity. Adding a fault path with an email alert to an existing record-triggered flow. Translating a Process Builder migration backlog item into something modern. These are tasks I know how to do, but the agent does them faster.

Where it really shines is teaching. When a junior admin asks me how to handle a related-record update without violating bulkification, I can have them describe the requirement to Agentforce, then we walk through the generated flow together. They learn the patterns by reviewing what the AI produced, instead of fumbling through Trailhead modules in isolation.

A practical tip: keep your prompts focused on one transaction at a time. If you ask for a flow that does five unrelated things, the AI tries to cram them into one giant flow that's hard to maintain. Instead, prompt for modular subflows and link them yourself. The Salesforce admin team has been pushing this modular pattern for months and it's the right approach for an Agentforce-driven world. If you need a refresher on flow types, subflows, or what bulkification means, the salesforcedictionary.com entries on each of those terms are concise and accurate.

The other use case worth calling out is documentation. After Agentforce builds or modifies a flow, ask it to summarize what the flow does in plain English. Paste that into the Description field on the flow and your future self will thank you.

Where Agentforce for Flow Falls Short

It's not all sunshine. There are clear gaps you should plan around.

First, complex business logic with edge cases tends to get oversimplified. If you have a flow that needs to handle five record types differently with overlapping criteria, the AI usually picks the most obvious path and ignores the rest. You'll need to add the missing branches manually. Don't assume the first draft is complete.

Second, error handling is hit or miss. The agent does add fault connectors when prompted explicitly, but it won't add them by default unless you describe failure scenarios in your request. I now include "include fault paths and email the running user on errors" in almost every prompt as a habit.

Third, naming conventions are generic. The AI picks names like "Decision_1" or "Assignment_2" unless you specify otherwise. For any flow heading to production, rename every element to something descriptive. Auditors and the next admin who inherits your org will appreciate it.

Finally, the agent doesn't yet understand your org's custom code or managed packages well. If your business logic depends on a particular Apex class or a third-party package action, you'll likely need to add those invocable actions yourself.

What Comes Next for Flow Automation

The wider context here is that Salesforce is reshaping Flow into the connective tissue between agents and the platform. Modular flows are becoming the building blocks of agent actions, and the Agentforce Builder lets you wire flows directly into agent capabilities. So the skills you build with Agentforce for Flow today carry forward into agent design, which is where most large orgs are heading next.

If you're not already thinking about your flow strategy in terms of small reusable utility flows that an agent can call, now is the time. Massive end-to-end flows are becoming an antipattern. Plan for a future where every flow you build might be triggered by a human, a schedule, an API, or an autonomous agent.

For admins building their first agent, I'd suggest starting with a single utility flow exposed as an agent action, then expanding from there. It's a much safer learning path than trying to build a multi-step agent on day one.

Wrapping Up

Agentforce for Flow GA is one of the more useful additions in Spring '26 because it lowers the barrier to flow building without sacrificing the discipline that good automation requires. It's not magic, and you still need to know what you're doing, but it removes a lot of the busywork that used to slow down the build phase.

If you've used it on a real project, I'd love to hear what worked and what didn't. Drop your favorite prompt patterns or your funniest AI-generated flow fail in the comments. And if you're new to any of the Salesforce flow terminology in this post, salesforcedictionary.com is where I send people for quick definitions of things like invocable action, scheduled path, or fault connector.

Happy automating.

Salesforce Summer '26 Release: Top Features for Admins

Dipojjal Chakrabarti — Tue, 28 Apr 2026 23:05:29 +0000

Salesforce Summer '26 Release: Top Features for Admins

Summer '26 release notes dropped on April 22, and I'll be honest, this one feels different. After spending a few hours combing through the highlights, I think this release shifts how admins will spend their time day-to-day. Less clicking through profiles. More working with Agentforce. And finally, finally, a real Field Access tab.

If you haven't blocked time on your calendar to prep for the upgrade weekends in June, you'll want to do that soon. Sandboxes upgrade around May 9, and production orgs roll out the weekends of June 5, 12, and 13. That gives you about six weeks to test, retrain users, and update your documentation.

Here's what stood out to me from the Summer '26 release, and what I think you should focus on first.

The New Field Access Tab Is the Audit Tool We've Been Asking For

For years, auditing field-level security has been one of those tasks I tried to avoid. You'd have to bounce between profiles, permission sets, and permission set groups, take screenshots, build a spreadsheet, and pray you didn't miss anything. SOX audit season was a nightmare.

Summer '26 introduces a new Field Access tab at the bottom of every object in Object Manager. Open it, and you get a single consolidated view of every field on that object alongside a matrix showing exactly how access is granted across profiles, permission sets, and permission set groups. No more bouncing around. No more spreadsheets.

I tested it in a preview org last week. Pulled up the Account object, clicked Field Access, and within about ten seconds I had a complete picture of who could see what and why. For onboarding new admins or running compliance reviews, this is going to save hours.

A practical tip: even though the tab is read-only for viewing access, you can use it as a starting point to identify orphaned permissions. If a field has access granted through a permission set that no users are assigned to, you've found dead weight you can clean up.

Flow Gets a Big Round of Quality-of-Life Upgrades

Flow has been getting better every release for years now, but Summer '26 focuses on making flows actually maintainable, which is something the community has been asking about loudly. There are ten new Flow features in this release, and three of them stand out.

First, schedule-triggered flows can now have a configurable maximum batch size. The default has always been 200 records per batch, which works fine until you're processing a flow that hits limits at 150. Now you can override that. Drop it to 50 if you've got heavy logic, or push it higher if you're just doing simple field updates.

Second, error handling on record-triggered flows got smarter. You can finally catch and route errors without building a whole secondary flow to handle failures. This alone is going to save me from rewriting two production flows that I've been meaning to fix for months.

Third, Flow Builder has cleaner UI components and more readable data displays. It sounds like a small thing, but when you're staring at a flow with 40 elements trying to figure out what's happening, every bit of clarity helps. If you're new to Flow vocabulary, I'd recommend bookmarking salesforcedictionary.com as a quick reference for the terms that come up in release notes. It's saved me a few times when I hit jargon I didn't recognize.

Agentforce Stops Being a Sidecar and Starts Being Part of the CRM

Salesforce reports more than 12,000 customers have deployed Agentforce so far. That's a real adoption number, not a marketing fantasy. And Summer '26 is the release where Agentforce stops feeling like a separate product and starts showing up inside the surfaces admins and users already work in.

You'll see Agentforce inside Sales Cloud list views, in marketing authoring tools, and in service console workflows. For admins, this means a few things. You need to think about which agents your users actually have access to (more permission set work). You need to decide which actions agents are allowed to take on records, and you need to set guardrails before someone in sales tells an agent to mass-update opportunities.

I'd suggest doing three things this month. Spin up a sandbox with Agentforce enabled if you haven't already. Identify two or three workflows where agents could realistically help (lead qualification, case summaries, and meeting prep are common starting points). And read up on agent topic modeling, because that's how you control what your agents will and won't do.

If you're new to Agentforce, the terminology around topics, actions, and reasoning engines can be overwhelming. I'd start with the basics on salesforcedictionary.com to build a vocabulary before reading the deeper Trailhead modules. It made the documentation a lot easier to follow.

Web Console: A Browser-Based IDE Built Right Into Your Org

This one is for the developers and admin-developers in your org, but you should know about it because users will start asking questions.

Summer '26 introduces Web Console, a lightweight browser-based IDE built on VS Code for Web foundations. It's designed to replace the legacy Developer Console (which has been showing its age for a decade) and the unofficial Workbench tool that admins and devs have been propping up for SOQL queries and metadata work.

What I like about it: no installation required, available in all org types (including free and developer orgs), and you can write Apex, run SOQL, and customize the org from the same interface. What I'm watching: how it handles deployments and source control compared to the full Agentforce IDE, which is paid-only.

If you've been using Workbench for quick SOQL queries or to inspect API requests, start migrating those habits to Web Console now. The legacy tools aren't going away immediately, but the writing is on the wall.

Reporting Gets Two Row-Level Formulas Per Report

Last one, and it's a small change that's going to make a big difference for me. You can now add up to two row-level formulas in a single report. The previous limit of one formula per report has caused me to create custom formula fields on objects more times than I want to admit, just to get a calculation into a report.

With two formulas, you can do things like calculate the difference between two date fields and compute a percentage in the same report. Quick wins like deal age plus close probability, or invoice age plus collected percentage, are now doable without touching object-level metadata.

It's a quiet feature, but quiet features that reduce admin overhead are exactly what I want from a release.

How to Prep Your Org Before June

Here's the rough plan I'm running this month.

Block time the week of May 9 to log into your preview org and walk through the new Field Access tab on your most critical objects (Account, Contact, Opportunity, Case). Document anything that looks off. Pull a list of your record-triggered and schedule-triggered flows. Identify which ones could benefit from custom batch sizes. Test them in sandbox with the new error handling.

Audit your Agentforce setup. Even if you haven't deployed agents yet, decide on the permission set groups you'll use to govern access when you do. Communicate with your developers about Web Console. If your team has been using Workbench, set a target date to migrate. And update your release readiness documentation. New features mean new screenshots and new training notes for your end users.

If you maintain a glossary or onboarding doc for new admins on your team, this is a good moment to refresh it. I keep a personal cheat sheet of new terminology each release, and the team glossary at salesforcedictionary.com is where I cross-check definitions when I'm building it.

Wrapping Up

Summer '26 isn't a flashy release with one giant headline feature. It's a quietly substantial one that fixes long-standing pain points and integrates Agentforce more deeply into daily workflows. The Field Access tab alone is worth the upgrade for me. The Flow improvements close gaps I've been working around for years. And Agentforce becoming part of the regular CRM surface means admins need to start treating agent access the same way we treat data access.

If you're building a release readiness checklist, those five areas are where I'd start.

What features are you most excited about in Summer '26? Drop a comment with your top three and how you're planning to roll them out. I'm especially curious to hear how teams are governing Agentforce access. There's no playbook yet and we're all figuring it out together.

7 Salesforce Data 360 Mistakes That Sink Projects

Dipojjal Chakrabarti — Tue, 28 Apr 2026 14:39:58 +0000

7 Salesforce Data 360 Mistakes That Sink Projects

If you've watched a Data 360 rollout go sideways, you already know the pattern. Six months in, the credits are burning faster than expected, the unified profiles look weird, and somebody upstairs is asking what exactly they're paying for.

I've been through enough of these now to spot the trouble before it shows up in a status meeting. The funny thing is, the failures rarely come from the technology itself. The connectors mostly work. The identity resolution engine actually does its job. What breaks projects is the stuff that happens (or doesn't happen) before anyone touches a Data Stream.

Here's a rundown of the mistakes I see again and again, plus what to do instead. If any of the terms below sound unfamiliar, salesforcedictionary.com keeps a running glossary of Data 360 vocabulary that's worth bookmarking before your next planning session.

1. Building Without an Outcome in Mind

The first mistake almost everyone makes is treating Data 360 like a data lake. The thinking goes: "Let's pull in everything we have, get it unified, and then figure out what to do with it." Don't.

Data 360 charges credits for ingestion, processing, and activation. Every Data Stream you set up adds to your monthly bill. If you can't trace each source back to a specific use case (a segment, an activation, a feature inside Agentforce), you're paying for storage and processing that delivers zero ROI.

The fix is boring but it works. Pick two or three concrete use cases first. Hot-account scoring for SDRs. Churn-risk segments for retention. Cross-sell triggers for service. Then ingest only the data those use cases actually need. You can always add more sources later, and you probably will.

2. Treating the Data Model Like It's Reversible

Once you ingest data and map it into Data 360 objects (Individual, ContactPoint, Engagement, and so on), you've made decisions that are hard to walk back. The model isn't a draft. Re-modeling means re-ingesting, which means double the credits, double the time, and a long conversation with your project sponsor.

I've seen teams skip the modeling phase because they assume they can fix it later. They can't. Or rather, they can, but the cost is brutal.

Spend real time on the Customer Information Model before you connect anything. Map out which source fields go where. Decide what counts as a Party, what's a Profile, and which records are worth merging into a single unified record. Get a data architect involved if you don't have one in-house. The hour you spend on a whiteboard saves a week of cleanup later.

3. Ingesting Every Field "Just in Case"

This one shows up everywhere. Someone in the kickoff meeting says, "let's just bring it all over and decide what we need later." Two months later, the org has 400 fields ingested across 12 streams, half of them blank, and the credit consumption chart looks like a hockey stick.

Each field you bring in costs storage. Each row costs ingestion credits. Each transformation costs processing credits. None of that is free, and it adds up faster than people expect.

Be ruthless during scoping. If a field doesn't directly serve a documented use case, leave it out. You can add it in a later sprint if a real need emerges. The cost of adding one field later is small. The cost of carrying 200 unnecessary fields for two years is not.

4. Ignoring Identity Resolution Until It's Too Late

Identity resolution is what makes Data 360 worth the price tag. It's how a customer who shows up as j.smith@acme.com in Marketing Cloud and Jennifer Smith in Service Cloud becomes one unified profile. Get it wrong and your activations send the wrong message to the wrong person, and trust in the platform evaporates fast.

Common identity mistakes include relying on email as the only match key (people change emails), not handling household-level matching for B2C use cases, and forgetting about anonymous web visitors who later become known customers.

Before you ingest a single record, write down your match rules. What's the primary identifier? What are the fallback rules? How do you handle conflicts when two sources disagree? Test the rules against a sample dataset and actually look at the unified profiles before you scale up. The work is unglamorous but it pays off every single day the platform runs.

5. Skipping Data Hygiene Before Ingestion

Data 360 doesn't clean your data. It harmonizes it, but garbage in still equals garbage out. If your CRM has 30% duplicate accounts, test contacts using test@test.com, and inconsistent country codes, those problems travel straight into your unified profiles.

I worked on a project where the team was confused why their unified customer count was wildly inflated compared to actual customers. Turned out the source CRM had years of accumulated test records and duplicate contacts that nobody had cleaned up. The fix wasn't in Data 360. It was a six-week data cleanup project in the source systems.

Run a data quality assessment on every source before you connect it. Standardize formats. Dedupe what you can. Tag and exclude test records explicitly. It feels like wasted time until you see how much cleaner your activations work afterward.

6. Forgetting About Permissions and Sharing

This one sneaks up on teams that come from a Sales Cloud admin background. Data 360 has its own permission model. You need specific permission sets for connectors, for the Data 360 home app, for segment creation, and for activation targets. If you don't assign them right, ingestion silently fails or users see empty screens with no clear error message.

The Salesforce help docs cover this, but the gotcha is the order. Some permissions need to be granted before a feature appears in Setup. Others apply to specific connector types only. If you're new to Data 360 permissioning, the Data 360 reference on salesforcedictionary.com has a quick rundown of the permission sets you'll actually need.

Plan permissions during your pre-ingestion phase, not as an afterthought. Document which roles get which access. Keep it tight. Data 360 holds unified customer data, which often has tighter compliance requirements than your source systems do.

7. Activating Before You've Validated

The last mistake is the one with the highest blast radius. You finish ingesting, you build a segment, and somebody pushes "activate" to send the segment to Marketing Cloud Engagement, which fires off an email to 50,000 customers.

Then you find out the segment had a logic error. Or the unified profiles weren't fully resolved. Or the same person got the email three times because the dedupe rules weren't doing what you thought they were doing. Now you're explaining yourself to legal and the brand team simultaneously.

Always run an activation against a test audience first. A handful of internal email addresses, a couple of test phone numbers. Look at what got sent, who got it, how many copies. Compare your segment count in Data 360 against what actually showed up in the destination system. Differences usually point to mapping or identity issues that are way easier to catch on 10 records than on 50,000.

What to Do Differently

The pattern across all seven mistakes is the same. Teams treat Data 360 like a tool you can configure on the fly, when really it's an architectural commitment. The decisions you make in the first 30 days shape what's possible (and affordable) for the next 30 months.

If you're starting a new implementation, do these three things in order. Pick two or three concrete use cases and write them down. Design your data model and identity rules on paper before you connect anything. Bring in clean source data from systems you trust.

Everything else flows from those three steps. Skip them and you'll probably end up on this list yourself.

One more thing. If you're hitting Data 360 vocabulary you don't recognize during planning sessions (Data Stream, Calculated Insight, DMO, Activation Target, Segment Membership), salesforcedictionary.com is a quick way to look up terms without wading through release notes every time.

Have you run into one of these mistakes, or a different one I missed? Drop a comment with what tripped your team up. I'm always interested in hearing what people are wrestling with in real implementations, especially the stuff that doesn't show up in vendor case studies.

Salesforce Data Cloud Zero Copy: A Practical Guide

Dipojjal Chakrabarti — Mon, 27 Apr 2026 23:07:03 +0000

Salesforce Data Cloud Zero Copy: A Practical Guide

If you've spent any time around Salesforce Data Cloud over the past year, you've probably heard the phrase "zero copy" thrown around at every Dreamforce keynote, partner webinar, and LinkedIn thought leader post. At first I rolled my eyes a bit. Every cloud vendor has its buzzwords, and "zero copy" sounded like another one. But after working with it on a couple of real customer projects, I'll admit it: this is actually one of the more interesting things Salesforce has shipped in the data space, and most teams aren't using it the way they should be.

So let's go through what zero copy actually is, when you should use it, and the parts the marketing pages tend to skip over.

What Zero Copy Really Means in Data Cloud

Zero copy data federation lets Data Cloud (now also called Data 360 in some places) read data sitting in your Snowflake, Databricks, BigQuery, or Redshift warehouse without first ETL-ing that data into Salesforce. The data physically stays in the source system. Data Cloud queries it in place.

That's the whole pitch. No nightly extract jobs. No duplicate copies. No reconciliation when the warehouse number disagrees with the Data Cloud number because someone's pipeline broke at 2am.

In traditional CDP setups, you'd ingest your customer data from your warehouse into the CDP, transform it, then activate it. Each step is a copy of the data. With zero copy, Data Cloud effectively becomes a query layer on top of your existing warehouse for the federated tables, and only stores its own metadata about how those tables map to your customer profile.

If you're new to some of these terms, the team over at salesforcedictionary.com has a pretty solid glossary that covers Data Cloud objects, DMOs, and the federation concepts in plain English. Worth bookmarking if you're getting up to speed.

The Two Flavors: Query Federation vs File Federation

This is where I see most people get confused. Zero copy isn't one feature, it's two, and they behave differently.

Query federation is the original version. Data Cloud sends a SQL query to your warehouse, the warehouse runs the query and returns the result. Your warehouse does all the compute. That means you're paying for warehouse credits every time someone in Data Cloud runs a calculated insight, segment, or activation that touches a federated table.

File federation is the newer approach, which uses open table formats - Apache Iceberg, the Iceberg REST Catalog, and Parquet files sitting in S3 or Azure. Data Cloud reads the Parquet files directly. Your warehouse isn't even in the loop for the read. Right now this works with Snowflake, Databricks, IBM, and any generic Iceberg catalog.

In practice, if your data team already publishes Iceberg tables (and a lot of modern data platforms do), file federation is faster, cheaper, and more flexible. If you're an all-in Snowflake shop and don't want to deal with Iceberg, query federation is the friendlier path. The downside of file federation is the setup is more involved - you've got catalog credentials, storage credentials, and a few extra steps to get right.

When Zero Copy Is the Right Call

I've found zero copy works best in three situations.

The first is when you've already got a mature data warehouse with curated customer data. You've spent two years building dbt models, you've got data quality checks running, and your analytics team is the source of truth. Re-ingesting all of that into Data Cloud is a waste. Federate it.

The second is governance and residency. If you have data that legally cannot leave your warehouse - certain healthcare data, EU records under GDPR localization rules, or data that's contractually scoped - zero copy lets Data Cloud reason over the data without actually moving it. That's a much shorter conversation with your legal team than explaining a new copy of the data living in Salesforce's tenant.

The third is cost. Storage in Data Cloud isn't free, and large historical fact tables - clickstream, transactions, telemetry - are expensive to keep duplicated. Federate the cold and warm data, ingest only the hot data you actively need to score or segment on.

When Zero Copy Will Bite You

Now the part the marketing slides leave out. Zero copy has real limitations and you need to know them before you architect around it.

Audience and segmentation latency. As of right now, only a limited number of Data Cloud audiences can include BYOL (bring-your-own-lake) datasets, and those audiences only refresh every 12 hours. If your use case is real-time activation - "send a journey when this customer's account balance changes" - federation isn't the answer for that signal. Ingest it.

Query volume ceilings. Some customers have hit ceilings around the multi-million-record mark when querying federated datasets. Your warehouse can handle a billion-row scan. Data Cloud's federated query planner is more conservative. Test with realistic volumes before you commit your architecture to it.

Feature gaps. A bunch of Data Cloud features assume the data lives natively in Salesforce. Identity resolution, certain calculated insights, some Einstein features - they may not work, or work fully, on federated DMOs. The gap is closing every release, but check the current state for your specific use case.

Latency sensitivity. Even file federation has a network hop. If you're trying to do millisecond-level lookups for an Agentforce agent or a real-time Marketing Cloud journey, native ingestion is still faster. Federation is great for analytical and batch-style activations, less great when a customer is sitting on a page waiting.

Getting It Set Up

The actual setup is more straightforward than the documentation makes it sound. Here's the rough sequence I run through:

In your warehouse, create a service user with read-only access to the tables you want to expose. Don't reuse a human's account, and don't grant more than you need.
In Data Cloud Setup, go to Data Federation and create a new connection. Pick the source type (Snowflake, Databricks, etc.) and provide the credentials.
Choose query or file federation based on what your warehouse supports and what your team is comfortable operating.
Map external tables to DMOs (Data Model Objects). This is the step where you tell Data Cloud "this Snowflake table called prod_analytics.customers_v2 is a Customer DMO, and these columns map to these standard fields." Spend time here. Bad mappings will haunt you for months.
Validate with a small dataset before you point any segments or insights at it. Run a calculated insight, check the results, compare to a query you ran directly in the warehouse. Numbers should match.

A small tip: name your federated DMOs with a prefix like FED_ so it's obvious to admins down the line which DMOs are native and which are federated. When something behaves weirdly six months from now, that prefix is going to save someone an afternoon of confused debugging.

How This Plays With Agentforce

Worth flagging because it's the question I get most often. If you're building Agentforce agents that need customer context, federated data is queryable through the same DMOs your agent topics reference. The agent doesn't know or care whether the data is native or federated. It just sees the DMO.

That said, remember the latency point above. If your agent is in a real-time conversation, you don't want it stalling for two seconds while a federated query runs against a warehouse that's busy with an analytics workload. Either pre-aggregate the data your agent actually needs into a native DMO, or ingest the latency-sensitive fields and federate the rest.

If you're new to how Agentforce reads from Data Cloud or how DMOs feed into agent topics, salesforcedictionary.com has a few useful entries on the agent side of the architecture too. The terminology between the two products can get tangled and a glossary helps.

A Quick Decision Framework

Here's how I think about whether to federate or ingest a given dataset:

High volume, low latency requirement, lives in warehouse already? Federate it. File federation if your warehouse supports Iceberg, query federation otherwise.
Real-time activations, Einstein scoring, or identity resolution? Ingest it. The feature support and latency are better natively.
One-time historical lookback, regulatory data, or analytics-style segmentation? Federate. You'll save storage cost and avoid duplicating the source of truth.
Mixed? That's most real customers. Ingest the hot signals, federate the cold history. You don't have to pick one for the whole org.

What's Next

Zero copy is going to keep maturing. The early version was query federation only with Snowflake. We now have Iceberg-based file federation, multiple warehouse support, and reverse-direction sharing where Salesforce data shows up in Snowflake and Databricks too. The next 12 months are going to be about closing the feature parity gaps - making sure things like identity resolution, more Einstein models, and faster audiences all work transparently against federated data.

If you're standing up Data Cloud right now, my honest advice: don't default to ingesting everything. Start with a federation-first mindset, identify the small set of fields that genuinely need to live in Data Cloud for latency or feature reasons, and federate the rest. You'll have a leaner, cheaper, and more maintainable architecture for it.

Have you tried zero copy on a real project yet? Hit any of the limitations I mentioned, or others I missed? Drop a comment - I'm curious how teams are actually using it in production versus how the slides suggest they should be.

For more Salesforce terminology, definitions, and quick reference guides, check out salesforcedictionary.com - it's become my go-to lookup when onboarding new team members onto the Data Cloud stack.

Salesforce Data 360 Zero Copy: How It Actually Works

Dipojjal Chakrabarti — Mon, 27 Apr 2026 14:40:02 +0000

Salesforce Data 360 Zero Copy: How It Actually Works

If you've spent any time in Salesforce conversations this year, you've probably heard "Zero Copy" thrown around like everyone already knows what it means. I've sat in meetings where architects nodded along confidently, only to corner me afterward and ask, "wait, so are we still copying the data or not?"

Fair question. The marketing language around Data 360 (the new name for Data Cloud) doesn't always make it obvious what's happening under the hood. So in this post, I want to walk through what Zero Copy actually does, when it makes sense to use it, and a few gotchas I've run into when integrating Data 360 with Snowflake and Databricks.

If you stumble on a term you don't recognize while reading this, salesforcedictionary.com has a pretty solid glossary that I bookmark for quick lookups during projects.

What Zero Copy Actually Means

Let's get the definition out of the way. Zero Copy is a federation pattern that lets Data 360 query data sitting in external warehouses like Snowflake, Databricks, Google BigQuery, or Amazon Redshift without first ingesting it into Data 360 storage.

That's the technical version. The plain version: instead of running a nightly ETL job to drag a 200-million-row orders table from Snowflake into Data 360, you just point Data 360 at the table. When someone runs a segmentation or insight that needs that data, Data 360 reaches across, pulls what it needs in real time, and returns the result.

A lot of folks ask if "Zero" really means zero. Mostly yes, but not always. Some Zero Copy patterns push the query down to the source warehouse and bring back only the result set. Others materialize a small subset on the Data 360 side for performance. The federation method you pick determines which one happens, and that decision matters more than the marketing makes it sound.

The Three Federation Patterns

Salesforce documents three flavors of Zero Copy, and they each trade off freshness, performance, and cost differently. I've used all three on different projects, and the choice usually comes down to how the source data behaves.

The first is direct query federation. Data 360 sends the query straight to Snowflake or Databricks, the source warehouse runs it, and the results come back. No data lands in Data 360 at all. This is great for low-volume, low-latency use cases like an operational dashboard that needs to reflect what happened ten seconds ago. The downside is you're paying compute on the source warehouse every single time the query runs. If you have a popular dashboard, that bill adds up quickly.

The second is Apache Iceberg-based federation. Data 360 reads Iceberg tables directly from cloud storage, and either the source warehouse or Data 360 itself can serve as the query engine. This is the sweet spot for analytical workloads where you want the data fresh-ish (maybe a few minutes old) but you don't want to keep paying source warehouse compute for every query.

The third is outbound sharing, which flips the direction. You expose enriched Data 360 tables back to Snowflake or Databricks so analytics teams can query unified profiles or calculated insights without copying that data into their own warehouse. I've seen this used a lot when a customer's data science team lives entirely in Databricks and just wants access to clean, harmonized customer profiles built in Data 360.

When Zero Copy Is Actually The Right Move

Here's where I'll push back a little against the hype. Zero Copy isn't always the right pattern. I've watched teams default to it because it sounds modern, then end up with worse performance and higher costs than a traditional ingestion would have given them.

Zero Copy shines when:

The source data is huge and updated constantly. If you have a clickstream table in Databricks that gets a million rows an hour, copying it into Data 360 makes no sense. Federate it and let Databricks handle the heavy lifting.

The data needs to stay where it is for governance reasons. Some companies have data residency rules that won't let certain data leave specific regions or platforms. Zero Copy keeps it in place while still making it usable.

You only need a slice of the data. If your segmentation only ever touches purchases from the last 90 days, federating beats ingesting five years of history you'll never use.

You want to avoid duplicate truth. The classic problem with copying data is that the moment you copy it, both copies start drifting. Different teams update different versions, and reconciling becomes a nightmare. Zero Copy sidesteps that.

On the other hand, traditional ingestion still wins when:

The source data is slow or unreliable. Federating against a warehouse that takes 30 seconds to return basic queries will make every Agentforce action that depends on it feel broken.

You need the data offline or for backup-style use cases. Zero Copy is live-only. Lose connectivity to Snowflake and your federated data is gone.

You're running tight loops. If a Flow needs to read the same record fifty times in a single execution, ingesting once and caching is way faster than fifty federated queries.

How To Actually Set It Up

The setup is more straightforward than I expected the first time I did it, though there are a few steps that aren't obvious.

For Snowflake, you'll start by creating a Snowflake account in Data Cloud Setup, then authenticating with either a service account or OAuth. Once that's connected, Data 360 can browse the Snowflake schemas you've granted it access to. You pick the tables you want available and Data 360 creates a Data Lake Object pointing at each one. From there you map fields, set the primary key, and the table is queryable from Data 360 like any native object.

Databricks works similarly but uses Unity Catalog under the hood. You'll authenticate, point Data 360 at the catalogs and schemas you want, and Data 360 will read the Delta tables (which are Iceberg-compatible thanks to the Uniform feature). One thing worth knowing: if the Databricks tables aren't already exposed through Unity Catalog with proper permissions, you'll be debugging access errors for a while. Get the Databricks admin involved early.

Google BigQuery and Amazon Redshift follow the same shape, though Redshift has some quirks with how it handles federated queries that can make some operations slower than you'd expect.

Real Gotchas From The Field

A few things I wish someone had told me before my first Zero Copy project.

Latency is real and not always small. A federated query that takes 800 milliseconds in isolation might take 4 seconds when it's part of an Agentforce action that chains three other lookups. Test the user-facing experience, not just the query timing.

Cost attribution gets murky. When Data 360 federates to Snowflake, the compute hits the Snowflake bill, not the Salesforce one. Your Salesforce admin sees fast queries; your data team sees their warehouse bill creep up. Have that conversation before launch, not after.

Calculated insights and segments behave differently. Some Data 360 features work with federated data exactly like they would with ingested data. Others have restrictions. Check the documentation for whatever feature you're using - I've been burned by assuming a feature works the same and finding out it doesn't support federated sources at all.

Schema changes upstream will break you. If your Snowflake team renames a column, your Data 360 mappings will silently fail. Build a process to communicate schema changes across both teams. This isn't a Zero Copy problem specifically, but federation makes it more painful because there's no ingestion job that fails loudly to tip you off.

If terms like Data Lake Object, Calculated Insight, or Unified Profile are tripping you up, salesforcedictionary.com has plain-language definitions for most of them. I find it useful when onboarding new people to a Data 360 project.

What This Means For The Average Salesforce Team

If you're an admin or developer who hasn't touched Data 360 yet, Zero Copy probably isn't the first thing you need to understand. Get comfortable with the basics first - Data Streams, DMOs, Identity Resolution, that kind of thing. But once your team starts asking how to bring in data from the warehouse without doubling your storage costs, Zero Copy is the answer you'll want in your back pocket.

The trend across the platform is clear: data should live where it makes the most sense and be accessible from wherever it's needed. Zero Copy is Salesforce's bet that nobody wants to keep moving petabytes around. So far, that bet looks right.

I'm curious what other folks are running into with Zero Copy in production. Are you seeing the latency hit I mentioned, or has your experience been smoother? Drop a comment and let me know what your setup looks like. And if there are other Data 360 concepts you'd like me to break down, I'm taking requests.

Want a quick reference for any term in this post? salesforcedictionary.com keeps the definitions short and project-focused, which I appreciate when I'm in the middle of something and just need a refresher.

Connected Apps Are Going Away. Here's What's Next

Dipojjal Chakrabarti — Sun, 26 Apr 2026 23:06:53 +0000

Connected Apps Are Going Away. Here's What's Next

If you've built any kind of Salesforce integration in the last decade, you've almost certainly used a Connected App. They're the unsung plumbing behind OAuth flows, mobile apps, middleware connectors, and a thousand other integrations. And starting with the Spring '26 release, you can't make new ones anymore.

That's not clickbait. As of January 2026, every Salesforce org has the ability to create new Connected Apps disabled by default. If you click the button to make one, you'll get blocked unless Salesforce Support specifically turns the capability back on for your org. Existing Connected Apps still work, and managed-package Connected Apps still work, but the message is loud and clear: the platform is moving on.

The replacement is something called an External Client App, or ECA, and I've been migrating a few orgs over the past couple of months. It's not a one-click swap, and there are a few gotchas worth knowing before you start. Here's what I've learned.

What Actually Changed in Spring '26

For years, Connected Apps were the only real option for defining how an outside system talks to Salesforce. The architecture worked, but it had baggage. Connected Apps were tied to first-generation packaging, the metadata model was clunky, and security defaults were generous in a way that didn't age well. If you've ever inherited an org with thirty mystery Connected Apps in it, half of them with "Admin approved users are pre-authorized" turned on, you know what I mean.

External Client Apps are Salesforce's answer. They were introduced in earlier releases as an opt-in alternative, but Spring '26 is the moment they became the default path forward. The headline change is that creating new Connected Apps is now blocked by default, which is Salesforce's way of nudging admins, devs, and ISVs onto ECAs without ripping the rug out from under existing integrations.

A few practical things to know. First, this only blocks the creation of new Connected Apps. Anything you already have keeps running. Second, if you absolutely need to create a new Connected App for some legacy reason, you can open a case with Support and ask them to enable it. Third, packaged Connected Apps that come from the AppExchange are unaffected, so you don't need to panic about that managed package you installed in 2019.

If you're newer to the platform and these terms are blurring together, I'd point you to salesforcedictionary.com for plain-English definitions of OAuth flows, named credentials, JWT bearer tokens, and the rest of the auth vocabulary you'll bump into during a migration.

Why External Client Apps Are Better (Mostly)

I'll admit I was skeptical at first. Salesforce loves rebranding things, and I half-expected ECAs to be Connected Apps with a new coat of paint. They're not. There are real architectural differences that matter.

The big one is second-generation packaging. ECAs were built from day one to play nicely with 2GP, which means ISVs can ship them as part of unlocked or managed-2GP packages without the workarounds Connected Apps required. If you build for AppExchange, this alone is worth the migration effort.

The second difference is that ECAs separate the app definition from the runtime policies. With Connected Apps, the OAuth scopes, IP restrictions, and refresh-token behavior were all bundled together. With ECAs, the metadata is split across multiple types - the app itself, OAuth settings, OAuth policies, and global settings - so you can update one piece without redeploying the whole thing. It feels more like modern infrastructure-as-code.

Third, the defaults are tighter. New ECAs are not available to users by default. You have to explicitly grant access through profiles or permission sets, which is how it should have worked from the start. Salesforce also pushed harder on the "refresh token valid until revoked" pattern, which is what most real integrations need anyway.

The "mostly" in my section header is because there are still rough edges. The migration tool doesn't cover SAML-only Connected Apps in every scenario, and if you're using canvas apps or some of the older mobile-related features, you'll want to test thoroughly. ECAs are also not available in every edition tier yet, so check before you start planning.

How to Migrate Connected Apps to External Client Apps

Here's the part most people care about. Salesforce shipped a built-in migration tool, and it works for most local Connected Apps. By "local" I mean Connected Apps that live in your org and weren't installed through a managed package.

The basic flow looks like this:

Go to Setup, type "App Manager" in the Quick Find box, and open it.
Find the Connected App you want to migrate. There's now a row-action option called "Migrate to External Client App."
Click through the wizard. It'll create a new ECA with the same OAuth settings, scopes, and callback URLs.
Update the App Authorization policy on the new ECA. The default is "Admin approved users are pre-authorized" but for most integrations you'll want to set "Refresh token is valid until revoked" so your tokens don't expire and break things at 2 AM on a Sunday.
Test your integration against the new ECA's Consumer Key and Secret in a sandbox before you cut over in production.
Once you're confident, update your middleware, mobile app, or service to use the new credentials, then deactivate the old Connected App.

A few things I learned the hard way. The new ECA gets a different Consumer Key and Consumer Secret. You cannot reuse the old credentials, which means every system that authenticates against the old Connected App needs an update. If you have integrations scattered across MuleSoft, custom Node services, third-party connectors, and a Heroku app someone built five years ago, make a list before you start so nothing gets missed.

Also, certificate management is its own conversation. ECAs use the same digital certificates and JWT bearer flow as Connected Apps, but Salesforce has been pushing harder on shorter rotation cycles and proper key management. If you're using a self-signed cert from 2018 because "it still works," now's a reasonable time to fix that.

For ISVs distributing apps through AppExchange, the migration story is different and a bit more involved. You'll want to read the External App Management documentation specifically for packaging, because the steps for moving a managed-package Connected App to a packaged ECA aren't the same as the local migration.

What This Means for Admins and Architects

If you're an admin who doesn't write code, you might be wondering whether this affects you. It does, but probably less than you think.

The day-to-day stuff stays the same. Users still log in. Single sign-on still works. The Salesforce mobile app still works. What changes is what happens the next time someone asks you to set up a new integration. You'll be creating an External Client App instead of a Connected App, and the screens look different, and the permissions model is a little stricter.

For architects, the picture is bigger. ECAs are part of a broader push toward what Salesforce calls "inbound governance" - giving orgs better visibility into who's calling their APIs, with what scopes, and how often. There's a new External Client App Usage report that shows you token activity per app, which is genuinely useful for spotting integrations that have gone rogue or that nobody can remember setting up.

If you're planning roadmaps right now, I'd recommend three things. Inventory your Connected Apps, prioritize the ones with the most token traffic or the most security exposure, and migrate those first. Don't wait for a forced sunset announcement, because Salesforce has been clear that "End of Support" is the destination, even if the timeline is fuzzy.

For folks studying for certifications, this is also fair game on the Platform Developer II and Identity & Access Management Designer exams. The Salesforce glossary at salesforcedictionary.com has been a useful reference when I've been refreshing on OAuth terminology and security concepts for exam prep.

A Few Things I'd Watch Out For

Before I wrap up, a quick list of things that have bitten me or people I work with during ECA migrations.

The "Available for Customer Users" setting doesn't carry over the same way in every case. If you have a Connected App used for Experience Cloud or Customer Community auth, double-check the user access settings on the migrated ECA.

Named Credentials that reference a Connected App by Auth Provider need to be updated to point at the new ECA. This is easy to forget because the Named Credential UI doesn't make it obvious that the underlying Auth Provider has changed.

If you have automated tests that hit Salesforce APIs, your CI pipeline probably has the old Consumer Key in a secret somewhere. Update those secrets before you decommission the old Connected App or you'll be debugging a green build that suddenly turns red.

Lastly, monitor token activity for at least a couple of weeks after cutover. The new ECA Usage report is your friend here. If something is still authenticating against the old Connected App, you'll see it, and you can chase down the missing system before you turn the old app off.

Wrapping Up

Spring '26 isn't the end of Connected Apps, but it's the end of Connected Apps as the default. External Client Apps are the path forward, and the sooner you start migrating, the less painful it'll be when Salesforce eventually pulls the plug on the old way. The migration tool handles most of the work, but the credential rotation, named-credential updates, and downstream integration testing are still on you.

If you've already migrated some of yours, what tripped you up? Drop a comment below. And if there are specific Salesforce terms you'd like to see explained more clearly, salesforcedictionary.com keeps growing a glossary of platform vocabulary that I find myself sending to teammates regularly.

Happy migrating.

Agentforce for Flow: My Honest Take After Two Months

Dipojjal Chakrabarti — Sun, 26 Apr 2026 14:39:58 +0000

Agentforce for Flow: My Honest Take After Two Months

If you've been holding off on touching Flow Builder because the Agentforce branding sounded like marketing fluff, I get it. I felt the same way when Spring '26 dropped. But after spending the last couple of months rebuilding flows with Agentforce for Flow on three different orgs, I have some opinions worth sharing.

Short version: this is the biggest shift to Flow Builder since the move away from Process Builder. Long version is below.

What Agentforce for Flow Actually Is

Agentforce for Flow is the rebranded and rebuilt successor to Einstein for Flow. Salesforce shipped it as generally available in the Spring '26 release, and it does two main things. First, it drafts brand new flows from a plain English description. Second, and this is the part that surprised me, it can modify existing flows in place. You open the Agentforce panel inside a flow you already built, type something like "add a decision element that routes high-value opportunities to the enterprise queue," and it makes the change for you to review.

The other thing worth flagging up front: it doesn't burn through your generative AI credits. That's a big deal because it means you can experiment without watching a meter tick down. I've used it dozens of times a day on one client org and credit consumption has stayed flat.

Getting It Turned On

You'd think this would be a one-click toggle, but there are a few prerequisites that tripped me up the first time. Here's what you actually need:

You need Data 360 (the new name for Data Cloud, which I keep forgetting) provisioned and enabled in your org. You also need Einstein generative AI turned on at the org level. If you're on a sandbox refreshed before Spring '26, you might also need to manually enable the Agentforce panel under Setup. Trailhead has a maintenance module covering the platform admin cert that walks through the exact steps, but honestly the path is just Setup, then search "Agentforce," then click through the enablement screens.

One gotcha: in some orgs the Agentforce panel doesn't appear inside Flow Builder until you've built at least one new flow with the AI drafting feature. I don't know why this is, but I've seen it on two separate clients. If the panel is missing, draft a throwaway flow first and then go back to your real one.

If you ever get tangled up in the new naming conventions across Data Cloud, Agentforce, and the rebranded Sales Cloud (now Agentforce Sales), I keep salesforcedictionary.com open in a tab. The terminology shifts every release and a quick reference saves a lot of head-scratching when stakeholders start throwing acronyms around.

How I Actually Use It Day to Day

Here's the workflow I've settled into. I no longer start a flow by dragging elements onto the canvas. I open Flow Builder, click "Let AI Help You Build," and describe the flow in two or three sentences. Something like:

"When an Opportunity stage changes to Closed Won, create a follow-up Task assigned to the Account Owner due in 7 days, and post a Chatter message to the deal team channel."

Agentforce drafts the whole thing. Most of the time the structure is right. The decision logic is right. Field mappings are right about 80% of the time, and that 20% is where I earn my paycheck. The AI doesn't know that your org calls the field "Deal_Team__c" instead of "Account Team," so you fix that and move on.

For modifications to existing flows, the Agentforce panel is a genuine time saver. Last week I had a 47-element flow that needed a new branch added for a specific record type. Old me would have spent 30 minutes carefully wiring connectors. New me typed "add a branch for the Partner record type that sends a different email template" and had it done in under two minutes. I still reviewed every connector before activating, but the grunt work was gone.

The Spring '26 release also added the ability to collapse branching elements on the canvas, which pairs really well with this. Big flows used to look like spaghetti. Now you can collapse the branches you're not working on and focus.

Where It Falls Short

I want to be fair here because I think a lot of the launch coverage has been too rosy.

Agentforce for Flow doesn't always pick the most efficient pattern. I've had it generate Get Records, Loop, Decision, Update Records sequences when a single fast field update or a Filtered Collection would have been cleaner and faster. If you're not careful, you'll end up with flows that work but hit governor limits the moment a bulk operation runs. I review every generated flow with bulkification in mind before I activate.

It also struggles with subflows. When I asked it to build a screen flow that called an existing autolaunched subflow, it kept trying to inline the logic instead of using the subflow I already had. I had to explicitly tell it "use the existing subflow named X" to get the right output.

And if you've got a complex schema with a lot of custom objects and similarly named fields, you'll get hallucinated field references. Always check that every field in the generated flow actually exists.

The Salesforce Admins blog put it well in their Spring '26 roadmap post: AI reduces the technical barrier but doesn't replace architecture skills. If you don't know what good flow design looks like, Agentforce will happily generate bad design for you very quickly.

What This Means for Your Career

I had a long conversation with a junior admin last week who was worried that AI flow building was going to make their skills obsolete. I don't think that's the right read.

What I see happening is that the floor has gotten higher and the ceiling has gotten higher too. The boring repetitive flows are now drafted in seconds, which means more of an admin's time goes to things AI can't do well: gathering requirements from stakeholders, understanding the business context, designing for scale, and reviewing for governance. Those are the skills that will pay off in 2026 and beyond.

If you're studying for the Platform App Builder or Advanced Admin certs, the Spring '26 maintenance modules now include questions on Agentforce for Flow specifically. You can't skip learning it. And if you're trying to brush up on the new vocabulary, the glossary at salesforcedictionary.com covers most of the new Agentforce terms in plain language, which I've found useful when explaining changes to non-technical stakeholders.

Practical Tips From the Trenches

A few things I've learned the hard way that might save you some pain:

Be specific in your prompts. "Send an email when a case closes" gets you a generic flow. "Send the 'Case Resolution Survey' email template to the Contact on the Case when Status changes to Closed and Origin is Web" gets you something usable.

Always check the Start element. Agentforce defaults to "A record is created or updated" with no entry conditions, which is fine for testing but absolutely not what you want in production for performance reasons. Add the entry conditions every time.

Test with bulk data before activating. The AI doesn't think about 200-record triggers. You have to.

Use the "Show Versions" feature aggressively. Every time you let Agentforce modify an existing flow, save a new version first. If the modification breaks something, rolling back is a one-click operation. I've had to roll back twice in two months and both times I was glad I had the version history.

Document the prompts you used. Drop them in the flow's description field. When someone asks why the flow was built a particular way six months from now, that prompt is a better explanation than any comment you'd otherwise write.

Should You Switch Everything Over?

No. And anyone telling you otherwise is selling something.

The flows you have running in production today are working. Agentforce for Flow is a tool for new development and for targeted improvements to existing flows. It is not a reason to rebuild your stack. I'd suggest using it on your next net-new flow, getting comfortable with the patterns, and only then deciding whether older flows are worth refactoring.

If you want to go deeper, Salesforce shipped a Trailhead superbadge specifically on Advanced Flow for Agentforce that's worth the time. And the broader salesforcedictionary.com reference is helpful when you hit a term you don't recognize, which still happens to me weekly.

Wrapping Up

Agentforce for Flow is the most useful new admin feature I've used in the last two release cycles. It's not magic, it's not a replacement for understanding flow architecture, but it absolutely changes the speed at which a competent admin can ship automation. If you haven't tried it yet, your homework for the week is to build one new flow using the AI drafting feature and compare it to how you would have built it manually.

What's your experience been? Have you found it more useful for new flows or for modifying existing ones? Any prompt patterns that have worked well for you? Drop a comment below, I'd love to compare notes.

Agentforce for Flow: A Practical Admin Guide

Dipojjal Chakrabarti — Sat, 25 Apr 2026 23:06:29 +0000

Agentforce for Flow: A Practical Admin Guide

If you've spent any time in Flow Builder, you know the feeling. You stare at the canvas, you know exactly what the business wants, and then you spend the next hour dragging elements around, naming variables, and double-checking decision logic. I've been there more times than I can count.

That changes with Agentforce for Flow. It's the upgraded version of what we used to call Einstein for Flow, and in Spring '26 it became generally available with a much bigger toolkit. You describe what you want in plain English, and the AI builds the flow for you. Then you tweak it, test it, and ship it.

I've been building with it for a few weeks now and I want to walk you through what's actually useful, where it falls short, and how to get clean output instead of spaghetti automation.

What Agentforce for Flow Actually Does

The headline feature is Flow Generation V2. You open Flow Builder, click into the Agentforce panel, and type something like "When a high-value Opportunity closes won, send the Account Owner an email and create a follow-up Task for one week out." A few seconds later you get a draft flow with the trigger, decision, action, and resource elements wired up.

It does three big things well:

First, it drafts new flows. Record-triggered, scheduled, and screen flows are all supported. You describe the business process and Agentforce assembles the structure.

Second, it modifies existing flows. Open the panel inside any active flow and tell it what to change. "Add a check for Opportunity Amount over fifty thousand before sending the email." It moves elements, adds new ones, and rewires the connectors.

Third, it explains what a flow does. If you inherit a complicated flow from a previous admin, you can ask Agentforce to summarize it. This alone has saved me hours of clicking through nodes trying to figure out what someone built two years ago.

The kicker: this doesn't burn generative AI credits. It's included. That's a meaningful detail because a lot of admins were holding back on Einstein for Flow in earlier versions because of credit consumption questions.

How to Write Prompts That Actually Work

The number one mistake I see people make is treating Agentforce like a magic wand. You type "make a flow for sales" and you get something useless. The quality of what comes out depends entirely on what you put in.

I think of prompting Agentforce like writing requirements for a junior admin. The clearer you are, the better the output. Here's the structure I use:

State the trigger explicitly. "When an Opportunity is updated and Stage changes to Closed Won..."
List the conditions. "...and Amount is greater than $50,000 and Type equals New Business..."
Spell out each action in order. "First, send an email to the Account Owner using the 'High Value Win' template. Second, create a Task with subject 'Schedule QBR' due in 7 days assigned to the Account Owner. Third, post a Chatter message to the #big-wins group."
Mention any error handling you want. "If the Account Owner is inactive, route to the Sales Operations queue instead."

That's it. The more your prompt reads like a clear set of instructions, the cleaner the draft. Vague prompts produce vague flows. I've started keeping a notepad of prompt templates for the kinds of automation I build most often, and it shaves real time off every project.

If you want to brush up on the underlying terminology before you start prompting, salesforcedictionary.com has solid plain-English explanations of trigger types, flow elements, and the bulkification concepts that come up when you're reviewing AI-generated work.

The Review Workflow Nobody Talks About Enough

Here's the part that gets glossed over in every demo: AI-generated flows need a human review pass. Not because Agentforce is bad at its job, but because there are org-specific conventions and platform best practices the AI doesn't know about.

My checklist looks like this:

Naming. AI picks generic names like "Decision_1" or "varAmount." I rename everything to match my org's standards. Pick a convention - prefix or suffix, snake_case or PascalCase - and stick to it.

Bulkification. This is the big one. The AI sometimes generates flows that work fine for one record but fall apart when triggered in bulk. Check that you're not making SOQL queries inside loops. If you see a Get Records inside a loop, refactor it.

Error handling. Agentforce doesn't always add fault paths. Add them where they matter, especially around DML operations and external callouts.

Order of execution. Make sure the flow respects when validation rules, workflow rules, and other automation will fire. The AI doesn't always think about this.

Test in debug mode. Run the flow with sample data before activating. Run it again after any change. I cannot stress this enough.

The pattern I follow: generate, review, refine, test, then activate. Skip the review step at your peril.

Building Modular Instead of Monolithic

One thing that's shifted in how I build automation since Agentforce arrived: I'm thinking smaller. The old instinct was to cram everything into one giant record-triggered flow. That worked, but it made everything brittle.

The better pattern is modular flows. Build small, focused autolaunched flows that do one thing well, then call them from your main flows or from agent actions. This matters more than ever now because the same utility flow you write for an automation can be reused as an Agentforce agent action. Build once, use everywhere.

Some examples of modular flows worth building:

"Find the right queue for this case" - takes a Case ID, returns a Queue ID
"Calculate territory pricing" - takes Account and Product inputs, returns adjusted price
"Get next business day" - takes a date and country, returns the next valid business day
"Send templated notification" - takes a recipient, template name, and merge data

When Agentforce drafts a flow that needs one of these, you can refactor the result to call your existing utility flow instead of inlining the logic again. Cleaner, more testable, easier to maintain.

If you're new to the modular flow concept and want a quick refresher on what counts as an autolaunched versus a record-triggered flow, the entries on salesforcedictionary.com cover the differences without burying you in jargon.

What's Coming Next and Why It Matters

Agentforce for Flow is part of a broader shift in how Salesforce is approaching automation. Flows aren't just for triggered logic anymore - they're becoming the building blocks that AI agents use to take action on behalf of users.

This has practical implications for how you should be thinking about your automation strategy:

Document your flows well. Use descriptions and labels that make sense out of context. Agents will be reading these to decide which flow to call.
Keep input and output variables clean. If a flow returns weird data structures, agents will struggle to use it.
Think about which flows could be exposed as agent actions. Not every flow needs to be, but the ones that represent reusable business operations probably should be.
Stay current on release notes. Spring '26 added a lot, and Summer '26 already has more flow features in pilot. The platform is moving fast.

I've found the admins who lean into this shift early end up with cleaner orgs and a lot less rework down the line. The ones who treat AI features as gimmicks end up rebuilding their automation when the next major release lands.

Try It This Week

Pick one flow you've been putting off building. Open Flow Builder, click into the Agentforce panel, and write a clear prompt. Generate the draft, review it against the checklist above, test it, and ship it. You'll be done before lunch.

Then pick a flow you already built and didn't love, open it, and ask Agentforce to refactor a piece of it. See how it handles the modification. That's where you'll really feel the difference.

What's the first flow you're going to try this on? Drop a comment and tell me what you're automating - I'm curious what use cases people are picking up first.

LWC Complex Expressions in Spring '26: What's New

Dipojjal Chakrabarti — Sat, 25 Apr 2026 14:40:35 +0000

LWC Complex Expressions in Spring '26: What's New

If you've been writing Lightning Web Components for any length of time, you've probably written a one-line getter just to format a date, build a CSS class string, or check whether two values match. I know I have. Dozens of them. Maybe hundreds.

Spring '26 changes that. Salesforce shipped Complex Template Expressions as a beta feature, and it's the kind of update that quietly changes how you build components day to day. You can now write actual JavaScript expressions inside your HTML templates: ternary operators, math, string concatenation, logical operators, all of it. No more getter graveyard cluttering up your .js files.

I want to walk through what's actually new, what it looks like in practice, what's still off-limits, and a few opinions on when to reach for it (and when not to).

What the LWC Template Could Do Before

Up until Spring '26, LWC templates were intentionally simple. You could bind a property, call a getter, use lwc:if for conditional rendering, and that was about it. If you wanted to do anything beyond {firstName}, you had to drop into JavaScript and write a getter.

Want to display a total with tax? Getter. Want to show "Equals" or "Not equals" based on two values? Getter. Want to concatenate a first and last name? You guessed it, getter.

Here's what that looked like in practice:

// myComponent.js
export default class MyComponent extends LightningElement {
    quantity = 5;
    price = 10;
    taxRate = 0.08;

    get totalWithTax() {
        return (this.quantity * this.price) * (1 + this.taxRate);
    }
}

<!-- myComponent.html -->
<template>
    <p>Total: {totalWithTax}</p>
</template>

For one value, fine. For ten of them, you've got a JavaScript file full of trivial computations, and finding the actual business logic gets harder. The original design philosophy was sound: keep templates dumb, keep logic testable. But in practice it created friction for the simplest UI work.

If you want a refresher on getters, properties, and how reactive bindings work in LWC, the glossary at salesforcedictionary.com has solid breakdowns that I find myself sending to junior devs more often than I'd like to admit.

What Complex Expressions Actually Let You Do

Here's the same component rewritten with complex expressions:

<!-- myComponent.html -->
<template>
    <p>Total: {quantity * price * (1 + taxRate)}</p>
</template>

That's it. The getter is gone. The arithmetic happens right where it's displayed.

The supported expression set covers most of what you'd reach for in a typical template:

Arithmetic: {price * quantity}, {count + 1}, {100 - discount}
String concatenation: {firstName + ' ' + lastName} or template literals like {`Hello, ${userName}!`}
Ternary operators: {isActive ? 'Active' : 'Inactive'}
Nested ternaries: {score >= 90 ? 'A' : score >= 80 ? 'B' : 'C'}
Logical operators: {isAdmin && canEdit} or {primary || fallback}
Comparisons: {value === expected ? 'Match' : 'No match'}
Method calls on bound values: {name.toUpperCase()} or {message.length}

You can also use these expressions in the lwc:if directive, which means you can finally write things like <template lwc:if={count > 5}> without a getter named isCountGreaterThanFive.

A Real Example: Status Badges Without Getters

Let me show a slightly more interesting use case. Say you've got an opportunity component and you want to render a status badge with the right color based on stage and probability. Before Spring '26, you'd write three or four getters: one for the label, one for the icon, one for the variant, one for the title attribute.

With complex expressions, your template can carry that logic inline:

<template>
    <lightning-badge
        label={stage === 'Closed Won' ? 'Won' : stage === 'Closed Lost' ? 'Lost' : 'Open'}
        icon-name={probability > 75 ? 'utility:success' : probability > 25 ? 'utility:warning' : 'utility:error'}
        variant={probability > 50 ? 'success' : 'warning'}>
    </lightning-badge>

    <p lwc:if={amount > 100000}>High-value opportunity</p>
</template>

The JavaScript file just holds the data. The template handles presentation. That's the split a lot of us have wanted for years.

I'll be honest though: this can absolutely get out of hand. A six-level nested ternary in a template is going to age like milk. Salesforce's own guidance is to keep complex business logic in JavaScript methods and use template expressions only for presentation. I'd second that. If you find yourself reaching for the comma operator in a template, stop and write a getter.

The Limitations and the Beta Asterisk

A few things to keep in mind before you go refactoring your whole org.

It's still a beta. Salesforce explicitly says don't use complex template expressions in production. Beta features can change behavior or get pulled. If you're shipping to a customer org tomorrow, hold off. If you're prototyping or working in a sandbox, go for it.

Not every JS expression is allowed. You can't use assignment (=, +=), increment/decrement (++, --), new, delete, comma operator, or anything that mutates state. The point is to compute display values, not to run side effects from your template. That's a feature, not a bug.

No statements, only expressions. You can't write if/else blocks, for loops, or var declarations inside {...}. Use lwc:if and lwc:for:each for control flow.

Performance is the same. The LWC compiler still produces optimized rendering code under the hood. Complex expressions don't add re-renders or change how reactivity works. If a property the expression depends on changes, the expression re-evaluates. That's it.

Tooling support is improving. As of Spring '26, the official LWC extension for VS Code understands complex expressions and gives you syntax highlighting and basic error checking. ESLint rules from @lwc/eslint-plugin-lwc are getting updates to lint these too.

When to Use Complex Expressions vs. Getters

Here's my rough rule of thumb after a few weeks of playing with this in sandbox.

Reach for an inline expression when the logic fits on one line, when it's pure presentation (formatting, simple math, label selection), when you're computing a value used only in one place, and when the expression won't need a unit test.

Stick with a getter when the logic spans multiple lines or branches, when you need to call it from multiple places, when it encodes a business rule worth testing, or when a future dev would benefit from the named abstraction.

For example: {amount.toLocaleString('en-US', { style: 'currency', currency: 'USD' })} works inline, but if you're using that in fifteen places, a getter named formattedAmount reads better and is easier to change in one spot. If you ever need a quick reference for terms like "getter," "reactive property," or any of the other LWC vocabulary that comes up here, salesforcedictionary.com keeps a clean glossary.

How to Try It in Your Sandbox

Spring '26 hits sandboxes starting January 9, 2026, and rolls to production on February 13 and February 20. To play with complex expressions:

Spin up a Spring '26 sandbox or a scratch org with the right API version (62.0 or higher).
In your .html file, just start writing the expressions. There's no flag to flip and no @api decorator to add.
Run the Local Dev Server if you're working locally, since it now supports the new expression set.
Watch the browser console. The compiler will warn loudly if you use an unsupported expression like = or ++.

If you want to learn this hands-on, build a small "shopping cart line item" component. It's a great test bed: total with tax, conditional discount label, formatted currency, status icon based on stock level. You'll touch every kind of expression in about thirty minutes. For broader Spring '26 terminology and feature definitions, salesforcedictionary.com is a handy bookmark.

Wrapping Up

Complex template expressions aren't going to revolutionize how you architect a Salesforce app, but they will quietly delete a lot of busywork from your daily LWC writing. The getter graveyard shrinks. Templates become more expressive. Component files get easier to read.

Just remember: it's still a beta as of Spring '26, so production deployments need to wait. Use it in sandboxes, prototypes, and demos. Watch the release notes for GA. And resist the urge to write nested ternaries that read like regex.

What features from Spring '26 are you most excited about? Are you already using complex expressions in your components, or holding off until GA? Drop a comment below, I'd love to hear how other teams are approaching it.

Setup with Agentforce: The Admin Tool That Saves Clicks

Dipojjal Chakrabarti — Fri, 24 Apr 2026 23:06:38 +0000

Setup with Agentforce: The Admin Tool That Saves Clicks

If you've spent more than a year as a Salesforce admin, you know the feeling. Someone pings you in Slack: "Can you give Maria the same access as Tom?" Easy ask. Twelve clicks later, you're still hunting for the right permission set group and wondering why you became an admin in the first place.

That's the exact pain Salesforce is going after with Setup with Agentforce, the beta admin assistant that landed in open beta and got serious upgrades in the Spring '26 release. I've been kicking the tires on it in a sandbox for the past few weeks, and I want to walk you through what it actually does, what it doesn't, and how to get it running without tripping over the permission requirements.

What Setup with Agentforce Actually Is

Setup with Agentforce is an AI agent that lives inside the Salesforce Setup menu. You open a chat panel from any Setup page and tell it what you want to do in plain English. It then executes the task, or asks you to confirm before it does. Think of it as a co-admin sitting next to you that knows where every Setup screen lives and can click through them faster than you can.

The thing that surprised me first time I tried it: when a task gets complex, the chat panel expands into a full-screen canvas. So if you ask it to "create a custom object called Project Risk with fields for severity, owner, and target close date," it doesn't just dump a wall of text. It shows you a preview of what the object and fields will look like. You hit Apply or you ask it to change something. That preview-before-apply pattern is what makes it feel safe to use.

For context, Salesforce launched this partly in response to admin complaints about how cluttered Setup had gotten over the years. If you've ever tried to find the Object Manager in a 400-permission-set org, you know what they're talking about. For folks just getting started with Salesforce terminology, salesforcedictionary.com has clear definitions of permission sets, profiles, and the rest of the security model that ties into all of this.

The Permission Stack You Need First

Here's where most people get stuck on day one. Setup with Agentforce isn't a free toggle. You need a specific stack of permissions before it'll even show up. I'll lay them out in the order you should grant them:

The "Use Setup with Agentforce" user permission. This is the gate.
The "Execute Prompt Template" permission, because the agent runs on prompt templates under the hood.
Access to the Data 360 default data space. Yes, even if you're not actively using Data 360 for analytics yet, the agent reads metadata through it.
The Data Cloud User permission set assigned to whoever is using the feature.
Whatever permissions the underlying task needs. The agent can only do what the user has rights to do, which I'll come back to in a minute.

That last one is the one I want to highlight. Setup with Agentforce respects your existing permission model. If a user without Manage Users tries to ask the agent to clone a user, the agent will tell them no. It's not a backdoor, it's a productivity layer. Which is the right design choice, even if it occasionally trips up admins who forget they're testing as a non-admin user.

If you're still building your mental model around how all these pieces fit together, the security and access glossary at salesforcedictionary.com walks through each layer of the Salesforce permission stack in plain language.

What It Can Actually Do Today

I want to be honest about scope. Setup with Agentforce is not a magic wand. It's good at a specific set of admin tasks, and clumsy or unhelpful for others. Here's what I've found it does well:

User management: Cloning users is a real time saver. You say "clone John Smith but change the email and profile to Sales User Lite," and it shows you the new user record before you save. It can also freeze users, build lists of users by permission criteria, and walk you through user access troubleshooting. That last one is useful because it'll explain why a user can't see a record, which beats clicking through three different setup pages to figure it out.

Permission sets and permission set groups: It can create them, assign them, and explain what each one grants. I had it generate a permission set for a new "Field Tech" role and it correctly bundled object permissions, field-level access, and a couple of system permissions I would have forgotten.

Data model changes: Custom objects and fields. This is where the preview canvas earns its keep. You describe the object, you see what's about to be created, you tweak the data types or picklist values, then apply.

Formula troubleshooting: This was the unexpected win. I pasted in a 30-line formula that was returning a NULL when it shouldn't have, and the agent walked me through the IF chain and pointed out where I was missing a comparison. It's not perfect, but it saves the back-and-forth of asking on the Trailblazer Community.

Setup navigation: Honestly, sometimes I just use it to find pages. "Take me to Login Hours for the Standard User profile" is faster to type than to click through.

What It Won't Do (Yet)

A few honest limitations worth knowing about before you sell this internally.

It doesn't deploy metadata between orgs. So it's not a replacement for change sets or your DevOps pipeline. It can build things in the org you're in. That's it.

It doesn't write Apex. There's a separate set of tools called Agentforce Vibes for code generation. Setup with Agentforce stays in the declarative lane.

It can stumble on org-specific terminology. If you've named your custom object "Account_c_Old" and your custom field "X_Discount_Pct_c_v2," don't expect it to magically know what those mean from context. You still need to be specific.

It also doesn't replace your understanding of Salesforce. I want to be clear about this because I've heard a few junior admins say things like "I don't need to learn permission sets, the agent will do it." That's wrong. The agent is a better keyboard, not a better brain. You still need to know what a permission set group is and when to use one, otherwise you'll ask it to do the wrong thing very efficiently.

Getting Your Team Onto It Without Chaos

If you're going to roll this out to other admins on your team, a few things I'd recommend based on what worked for us:

Start in a sandbox. Yes, the agent confirms before doing anything, but you want everyone to see the confirmation flow before they're working in production. The first time a peer admin says "wait, I didn't mean for it to do that," you want it happening in a sandbox.

Build a short list of approved use cases for the first month. We started with three: clone users, create permission sets, troubleshoot formulas. Once everyone got comfortable with those, we expanded to custom objects. Trying to use everything at once leads to inconsistent habits.

Track what people are using it for. The Setup audit trail captures actions taken through the agent the same way it captures manual actions. Pull that report after two weeks and see what your team is leaning on. You'll learn where your real bottlenecks were.

Make sure your data security review includes the agent. If your org is in a regulated industry, your security team will want to know what data the prompts touch. Read the Trust and Compliance documentation before you flip it on for production users. The basics of how Salesforce protects org metadata are decent reading, and you can find quick definitions of terms like "trust layer" and "Einstein Trust Layer" over at salesforcedictionary.com if your team isn't familiar.

The Bigger Picture for Admins in 2026

Setup with Agentforce isn't really a single feature, it's the front edge of a shift in how admin work gets done. Salesforce has talked openly about wanting admins to spend less time on rote configuration and more on solution design. Whether you buy that pitch or not, the tooling is moving that direction. We've also got Agent Builder for custom agents, Setup Powered by Agentforce for the actual configuration agent we just covered, and Agentforce Vibes for the code-leaning crowd.

If you've been on the fence about learning Data Cloud and the broader Data 360 platform, consider this another reason to start. Almost every new admin productivity feature in 2026 sits on top of that foundation. Even when you're not running marketing analytics, the agent uses Data 360 as its metadata layer. You don't have to be an expert, but you should know what a data space is and how identity resolution works at a high level.

I'm cautiously optimistic about Setup with Agentforce. It's not going to replace experienced admins. It is going to compress the time it takes to do the boring 60% of the job, which means we get to spend more time on the hard 40% that actually requires judgment.

Try It and Tell Me What Breaks

If you're already in a Spring '26 org and you have the right permission stack, give it twenty minutes this week. Try cloning a user, creating a permission set, and troubleshooting a formula. Notice where it saves you time and where it gets in your way.

Drop a comment with what you tried and what worked. I want to hear the weird edge cases. Specifically, I want to know if anyone has used it to manage sharing rules at scale, because that's the next thing I'm going to test and I'd love to compare notes.

If you're still figuring out the basics of Salesforce admin work, bookmark salesforcedictionary.com. It's a clean reference for terminology you'll run into as you work through Setup, especially around the security model and Data Cloud concepts that Setup with Agentforce leans on.

What's the first task you'd hand to a Setup agent?

Agentforce for Flow: What Admins Need to Know in 2026

Dipojjal Chakrabarti — Fri, 24 Apr 2026 14:40:46 +0000

Agentforce for Flow: What Admins Need to Know in 2026

Picture this: you open Flow Builder, type "send a follow-up email three days after an Opportunity hits Closed Won, but only for deals over $50K," and the thing just builds itself. That's not a pitch slide anymore. That's Agentforce for Flow as of Spring '26, and if you're an admin who hasn't tried it yet, you're going to want to clear an afternoon.

I've been building flows since the Process Builder days, and I'll tell you straight up - this is the biggest shift in admin tooling I've seen since Lightning. But it's not magic, and there are some real caveats you should understand before you start selling your team on it.

What Agentforce for Flow Actually Does

At its core, Agentforce for Flow lets you describe an automation in plain English and have AI draft the flow structure for you. Record-triggered, scheduled, or screen flows are all fair game. You tell it the business intent, it generates a starting skeleton, and you refine from there.

The feature first landed in beta and matured through the Winter '26 and Spring '26 releases. What caught my attention most wasn't the initial draft generation though, it was the Flow Summarization button. You click it inside the Agentforce panel, and AI reads your entire flow and generates a natural-language description of what it does. Then you can push that summary straight to the Flow's description metadata with one click. If you've ever inherited a org where flows are named "Flow_2_v3_FINAL" with no description, you know why this matters.

One thing I want to call out: Agentforce for Flow does NOT consume generative AI credits. That's a genuine surprise given how Salesforce has been pricing other Agentforce capabilities. If you want to brush up on how credits, consumption models, and the different Agentforce licenses work, salesforcedictionary.com has short, plain-English definitions for most of the terminology you'll bump into.

Getting Started Without Getting Burned

Here's the honest part most tutorials skip. AI drafts are good at 70% of the job and mediocre at the last 30%. If you're expecting to prompt once and ship to production, you're going to have a bad time.

My process for a new flow now looks something like this:

First, I write the prompt with specific field API names, not just field labels. "When Account.Industry equals Healthcare" gets me a better draft than "when the account is a healthcare account." The AI picks up label ambiguity in weird ways, especially in orgs with duplicate label names across objects.

Second, I always review the decision logic. Agentforce tends to build decision elements with slightly overbroad criteria. I've had it generate a flow where the default outcome path would have triggered on records it shouldn't have. Nothing broken, just not tight enough. Tighten your criteria.

Third, I run the flow in debug mode before I activate anything. This isn't new advice, but with AI-generated flows it's especially important because you didn't build the thing yourself, so you don't have the same mental model of every branch.

The Salesforce team at Apex Hours put it well - Agentforce isn't plug and play. You need clean data, clear processes, and solid prompt design. Messy org, messy results.

Flow Summarization Alone Is Worth the Switch

I'll stop talking about drafting for a second because the other feature people sleep on is summarization. If you manage an org with more than 50 flows, you know the documentation problem. Somebody built a beautiful automation in 2023, left the company, and now nobody knows what the thing does without clicking through every element.

Agentforce can read a flow and write a summary that explains it in words a human can understand. Not a generic "this flow updates records" blurb, but an actual description of the branches, the entry criteria, the outcome paths. I ran it against a flow one of our old contractors built and got back a summary that was more accurate than the description he'd originally written himself.

Some shops are now making "run the summarizer before merging" part of their flow deployment checklist. That's a good habit. Future you will thank present you.

Custom Actions: Where Flow Meets Agent

One place Agentforce and Flow overlap in a different way is custom actions. When you build an Autolaunched Flow with specific inputs and outputs, you can expose it as an action that an Agentforce agent can call. This is how you extend an agent beyond the standard library.

A few things I learned the hard way:

Define your inputs and outputs before you save. Once you publish the action, you cannot change the interface. You can update the logic inside, but the contract with the agent is locked. This is the number one gotcha for admins moving from standard flow work to agent actions.

Write your action descriptions like you're writing for a junior colleague. The agent reads the description to decide when to call the action. Vague descriptions get inconsistent agent behavior. "Updates the contact" is bad. "Updates the Contact's Last Called date and logs a Task when a user indicates they spoke to the contact by phone" is good.

Keep actions single-purpose. If you find yourself building a flow with twelve input variables and five decision branches based on which input is populated, that's actually two or three actions, not one. The agent handles it better, and so do you when something breaks.

For the full terminology around agent actions, tools, topics, and context - which is its own vocabulary - the Salesforce dictionary keeps those definitions short and current with each release.

Limitations You Should Know Up Front

A few things Agentforce for Flow doesn't do well yet, based on my own trial and error:

Complex nested logic trips it up. If your flow needs five levels of decision branching with compound criteria, the draft is going to miss things. Build the skeleton yourself and use AI for the simpler subflows.

Legacy field references are hit or miss. If your org has fields created before 2018 with odd API names, the AI sometimes can't resolve them correctly. This has gotten better each release, but it's still something to watch.

External callouts are mostly out of scope. Don't expect Agentforce to draft an HTTP callout for you. You can describe one, and it'll generate a placeholder, but the actual configuration still requires you to do the legwork with Named Credentials and External Services.

Performance on flows that query large data sets can be deceiving in preview. Always test with realistic volumes. A flow that works in a sandbox with 200 records might behave very differently against 2 million. This isn't specific to AI-drafted flows, but since people tend to trust AI output more than their own first drafts, the gotcha bites harder.

Should You Use It Right Now?

If you're an admin managing a mid-sized org with a decent volume of flow work, yes. Start small - draft a couple of simple scheduled flows and use the summarizer on your existing inventory. You'll recover the time investment within a week.

If you're a solo admin at a small shop, also yes, but be deliberate. The risk isn't that Agentforce will break something. The risk is that you start trusting output you didn't fully understand. Read every element before you activate.

If you're on a team that's still using Workflow Rules for most automation, honestly, start there. Migrate to flows, get comfortable with flow patterns, then layer in Agentforce. Skipping steps means you don't have the mental model to debug what the AI gives you.

Certification-wise, this matters too. The Platform Administrator exam was updated to include more Agentforce content, so if you're studying for or renewing that cert, expect questions on agent actions, guardrails, and the Einstein Trust Layer. A quick scan through the Salesforce Dictionary glossary is a decent way to front-load the vocabulary before you hit the deeper Trailhead modules.

Wrapping Up

Agentforce for Flow is the first AI tool in the admin stack that I've actually kept using after the first two weeks. That's a higher bar than it sounds. Most of what I see in AI tooling is impressive in a demo and annoying in daily work. This one earns its keep, mostly because it respects the admin workflow instead of trying to replace it.

My honest take: treat it like a very fast but slightly junior teammate. It gets you to 70% faster than you would alone. The last 30% is still your job, and that's fine.

What's your experience with Agentforce for Flow been? Are you using it for drafting, summarization, or both? Drop a comment below, I'm curious what patterns other admins have landed on. And if there's a specific prompt or use case that's working well for you, share it. This is still new enough that we're all figuring out the best practices together.