DEV Community: Dipojjal Chakrabarti

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.

Setup with Agentforce: An Admin's Honest First Look

Dipojjal Chakrabarti — Thu, 23 Apr 2026 23:06:57 +0000

Setup with Agentforce: An Admin's Honest First Look

Look, I've been admining Salesforce orgs for a long time, and I can tell you the Setup menu has not aged well. You know the drill. Someone pings you on Slack: "Hey, can Emily see that new Accounts list view?" Twenty minutes later you've clicked through three profiles, two permission sets, one permission set group, and you're still not sure. Spring '26 changed that conversation, and I wanted to write up what I've actually seen so far.

Setup with Agentforce went into beta with the Spring '26 release, and honestly, it's the most interesting admin feature I've touched in a while. It's not perfect. But the premise of just chatting with Setup instead of spelunking through menus actually works better than I expected.

What Setup with Agentforce Actually Is

Setup with Agentforce is an AI assistant embedded directly on the Setup home page. Instead of navigating through tabs, you type what you want in plain English. "Does Emily White have access to the Accounts object?" Or "Create a custom field on Opportunity called Renewal Risk with a picklist of High, Medium, Low." The agent figures out what Setup tools to pull up, shows you the relevant information, and if you're making changes, it asks you to confirm before it does anything.

It's in beta right now, which means you have to toggle it on manually. In Setup, search for "Setup with Agentforce" and flip the switch. Then refresh your browser. If you want other admins on your team to use it, you'll need to create a permission set with the "Use Setup with Agentforce" system permission and assign it to them. Standard pattern, nothing weird.

The Permission Audit Use Case

This is the one that sold me. Let me paint the picture. Someone in sales ops messages you because a specific user swears they can't see a particular opportunity. You go through the usual steps: check the user's profile, check assigned permission sets, check the role hierarchy, check sharing rules, check OWDs. Maybe there's a territory management rule involved. By the time you've traced it, thirty minutes are gone.

With Setup with Agentforce, I just type "Why can't Jake see Opportunity 0063k0000012345?" and the agent walks me through it. It checks object-level access, field-level security, sharing settings, and gives me a plain-English explanation of where the block is. Sometimes it's OWD, sometimes it's a permission set missing, sometimes it's a manual share that never got created. I still have to do the work of fixing it, but the diagnosis time drops from thirty minutes to about thirty seconds.

You can also ask questions like "Which users have the Customize Application permission?" and get a real list back. If you've ever been in a security audit and had to produce that report, you know how painful it usually is. If you need a quick refresher on what permissions like these actually mean, salesforcedictionary.com has solid definitions that new admins on my team have found helpful.

Creating Objects and Fields Without Clicking Around

The other workflow I use Setup with Agentforce for almost daily is data model tweaks. I used to dread requests like "can you add five fields to Contact for our new onboarding checklist?" because even simple field creation involves a lot of clicking. Object Manager, new field, type, label, length, help text, field-level security for each profile, add to the page layout.

Now I type something like: "On Contact, create five checkbox fields: Welcome Call Done, Docs Sent, Training Scheduled, First Login, 30 Day Check-in. Add them all to the page layout." The agent shows me what it's about to build, waits for my approval, and then does it. The confirmation step matters, because I've had moments where it misinterpreted what I wanted (once it tried to create the fields on Lead instead of Contact because my phrasing was ambiguous). But that's fine, you just say no and rephrase.

It handles formulas too, which is where I've had the most fun. "Fix this formula" is a real command you can use. You paste in a broken formula, it tells you what's wrong and suggests a fix. For admins who aren't formula wizards, this alone is worth enabling the beta.

What It Can't Do (Yet)

I want to be straight with you because the Salesforce marketing team will tell you this thing does everything. It doesn't. Here's what I've run into.

It can't deploy metadata between sandboxes. If you're using change sets or a DevOps tool like Gearset or Copado, you still do that work manually. Setup with Agentforce is an in-org assistant, not a release management tool.

It doesn't do complex Flow building well. Simple stuff like creating a basic record-triggered flow with one decision and one update works. But anything with loops, collection filters, or subflows tends to need manual cleanup. I treat it as a starter, not a finisher.

It also gets confused by custom terminology. If your org calls Accounts "Clients" and you ask a question using that word, the agent sometimes doesn't connect the dots. This will probably improve as the model sees more orgs, but for now, use the actual API names when you're asking precise questions.

And like every AI feature, it occasionally hallucinates. I caught it once trying to reference a field that didn't exist in the org. The confirmation prompt saved me, but be skeptical and verify.

How This Fits With the Broader Agentforce Story

Setup with Agentforce is one piece of the bigger Agentforce 3 picture that Salesforce rolled out with Spring '26. There's also Agentforce Builder for creating production agents, the Command Center for monitoring agent health across your org, and Agentic Enterprise Search that pulls context from over 200 external sources.

If you're new to all this terminology, it can feel like drinking from a firehose. I've been pointing newer admins to salesforcedictionary.com when they ask what terms like "agent action," "topic," or "atlas reasoning engine" actually mean. Having a clean glossary beats trying to piece together definitions from six different release notes.

The through-line is that Salesforce is pushing admins and devs toward building and managing AI agents as a core competency. Setup with Agentforce is kind of the training wheels version. You learn how to talk to an agent, learn what makes a good request, learn when to override the agent's suggestion. That intuition transfers when you go build customer-facing agents with Agentforce Builder later.

Getting Started This Week

If you want to try this out and haven't yet, here's what I'd do. First, turn on the beta toggle in a sandbox, not production. You want to see how it behaves before you unleash it on real users. Second, create a dedicated permission set and assign it to yourself and maybe one other admin who likes to experiment. Don't roll it out to your whole team on day one.

Third, pick three real tickets from your queue and try solving them with Setup with Agentforce instead of clicking around. Pay attention to where it helps and where it gets in your way. My experience was that permission questions and simple field creation were immediate wins, while anything involving sharing rules or Flow logic needed babysitting.

Fourth, check the Setup Audit Trail after a day or two. Every change the agent makes gets logged just like a manual change, so you can review what actually happened. That audit trail is your safety net if someone asks "who added this field?" and the answer is "the agent, at my request."

Fifth, give feedback. Salesforce is iterating on this fast and the beta period is when admin feedback actually shapes the final product. The in-product feedback button works, and so does the IdeaExchange.

The Bigger Picture

I'm cautiously optimistic about Setup with Agentforce. It's not going to replace admins, and the marketing framing that suggests it might is a little silly. What it does is remove the most tedious parts of the job so you can spend more time on the work that actually requires judgment. Data model design, security architecture, process optimization, user training. That's the stuff that takes a real human who understands the business. For reference material while you're getting up to speed on new Spring '26 concepts, salesforcedictionary.com keeps a running glossary that's been useful to me.

The clicks I'm saving on "does this user have access" and "add a field to this object" are clicks I get back for the harder work. I'll take that trade every day.

If you've been running Spring '26 for a few weeks and you have not tried Setup with Agentforce, this is your reminder to toggle it on. And if you have tried it, drop a comment below and let me know what's worked and what hasn't. I'm curious whether other admins are seeing the same wins and the same rough edges I am.

External Client Apps in Salesforce Spring '26: A Practical Migration Guide

Dipojjal Chakrabarti — Thu, 23 Apr 2026 14:39:18 +0000

External Client Apps in Salesforce Spring '26: A Practical Migration Guide

If you're an admin or developer who's been putting off learning about External Client Apps, Spring '26 just made that decision for you. As of the Spring '26 release, Salesforce disables the creation of new Connected Apps by default in every org. You can still flip a setting to create them short term, but the writing is on the wall. External Client Apps (ECAs) are the future, and the sooner you get comfortable with them, the less painful the migration will be down the road.

I've been working through ECA setups for a few clients over the past few months, and I want to share what I've learned. This isn't marketing fluff. It's the stuff I wish someone had told me before I started clicking around Setup trying to figure out why my OAuth flows kept failing.

Why Salesforce Built External Client Apps

Connected Apps have been around for over a decade. They work, but they carry a lot of baggage. If you've ever tried to package a Connected App and distribute it across multiple orgs, you know what I mean. The metadata model is inconsistent, the security controls are scattered, and the packaging story never really came together the way it should have.

ECAs are Salesforce's answer. They use second-generation managed packaging, which is the same modern framework that powers most new Salesforce development work. They're more secure out of the box because they follow a "closed by default" model. That means the app literally cannot do anything in your org until you install it and explicitly grant permission. No more orphaned Connected Apps sitting in Setup that some admin created three years ago and forgot about.

The other big shift is that ECAs make inbound and outbound governance a lot cleaner. You get clearer separation between who's publishing the app, who's installing it, and what the app is allowed to do in each org. For anyone managing integrations across multiple environments, this alone is worth the effort.

If you're still getting up to speed on the terminology around OAuth flows, token exchange, and scopes, I've found the glossary at salesforcedictionary.com useful for quick lookups during setup. It's saved me from going down Wikipedia rabbit holes more than once.

What's Actually Changing in Spring '26

Let me be specific about what's happening, because the messaging from Salesforce has been a little scattered.

Starting with Spring '26, new Connected Apps can no longer be created by default. Existing Connected Apps keep working. They're not deprecated yet, and you don't have to migrate them tomorrow. But Salesforce has made it clear that ECAs are the long-term model, and new feature work is happening on the ECA side.

There's also a separate but related change: as of February 16, 2026, you can no longer send session IDs in outbound messages. You have to use OAuth instead. This affects anyone who was using the old session ID pattern for outbound integrations, and it's worth auditing your org for any remaining references.

One important limitation to know about before you start migrating: ECAs don't support the Username-Password OAuth flow. If you have integrations that depend on it, you're stuck on Connected Apps until you either change your auth flow or Salesforce adds support. Push notifications are also not supported on ECAs yet. So before you plan any migration, check what your existing Connected Apps actually do. You might find you can't migrate some of them at all right now, and that's okay.

How to Create an External Client App

The setup process is similar to Connected Apps but not identical. Here's the basic flow I use:

In Setup, type "External" in Quick Find and click on External Client App Manager. Then click New External Client App. You'll enter a display name and an API name (the API name is what you'll reference in code and metadata, so pick something you won't regret).

Enable OAuth and configure your callback URL. This is the URL that receives the authorization code after a user authenticates. If you're building a server-side integration, this might be an endpoint on your application. For a single-page app, it could be a redirect URI you've registered.

For OAuth scopes, you'll typically want some combination of: api (manage user data via APIs), web (manage user data via web browsers), refresh_token (maintain the session), and lightning (access Lightning apps). Don't just check every box. Grant only what the integration actually needs. This is one of the security wins of ECAs, and it's also just good practice.

Once you save, head to Policies and configure who's allowed to use the app. Setting Permitted Users to "Admin approved users are pre-authorized" is usually what you want for internal integrations, because it forces you to assign a permission set before any user can actually use the app. That way, you control exactly who can authenticate, and you have an audit trail.

The Migration Playbook I Use

If you have more than two or three Connected Apps in your org, don't just start migrating randomly. Get organized first.

Step one is inventory. Go to App Manager in Setup and list every Connected App you have. For each one, figure out: what integration is it for, who owns it, is it still in active use, what OAuth flow does it use, and does it rely on any ECA-unsupported features (like Username-Password or push notifications).

You'll probably find two or three apps that nobody knows about. That's normal. Check the login history for each Connected App to see if anyone has actually authenticated against it in the last 90 days. If not, you might be able to just retire it without migrating.

Step two is prioritize. Start with new integrations. Any new integration work should use ECAs from the start. Then migrate your highest-risk or highest-value apps. Highest-risk means apps with broad scopes or admin-level access. Highest-value means the integrations that drive revenue or support critical business processes.

Step three is the actual migration. For each Connected App, create an equivalent ECA with the same OAuth settings. Update your integration code or configuration to point at the new ECA's client ID and secret. Test thoroughly in a sandbox first. I cannot stress this enough. OAuth errors are miserable to debug in production, and every integration has its own quirks.

Once the ECA is working in production, you can remove or disable the old Connected App. Don't do this in the same deployment window as the ECA rollout. Give yourself a couple of weeks to confirm nothing's broken before you pull the trigger.

Common Pitfalls to Watch For

A few things I've run into that cost me time:

Callback URL mismatches are the top cause of OAuth errors. If your callback URL in the ECA doesn't exactly match what your client sends, authentication fails with a generic error that doesn't tell you why. Double-check the URL, including trailing slashes and HTTPS.

Permission sets matter more than they used to. Because ECAs use a closed-by-default model, forgetting to assign the permission set to the user will produce login errors that look like the auth flow is broken. It's not. It's just that the user isn't permitted to use the app.

Scoped tokens behave differently. If you've been relying on the behavior of the old Connected App token system, test carefully. The way refresh tokens and access tokens interact under the ECA model is slightly different in some edge cases.

If you hit a term you don't recognize during all of this, salesforcedictionary.com is a decent quick reference for OAuth and identity concepts in the Salesforce context. I keep it open in a tab when I'm doing heavy integration work.

What This Means for Your Team

For admins, the biggest shift is that you need to understand ECAs well enough to audit them and grant the right permissions. The "closed by default" model means you'll be involved in every integration decision, which is a good thing, but it does mean more tickets if your team isn't prepared.

For developers, ECAs are the new default. Learn the metadata format, get comfortable with deploying them via SFDX, and update your team's integration templates. The Trailhead modules on External Client Apps are a solid place to start if you want a hands-on walkthrough.

For architects, this is a chance to clean up years of accumulated integration debt. Use the migration as an excuse to document what integrations exist, retire the ones nobody's using, and standardize your patterns going forward. You may not get another opportunity like this for a while.

The Bottom Line

Spring '26 isn't forcing you to migrate all your Connected Apps overnight, but the direction is clear. ECAs are the future, and the earlier you start building muscle memory around them, the smoother the eventual full migration will be. I'd suggest picking one low-risk integration to migrate this month just to go through the process end to end. You'll learn more from one real migration than from reading 10 blog posts (including this one).

If you've already started your ECA migration, I'd love to hear what surprised you. Drop a comment below with what you ran into, what worked, and what you wish you'd known before starting. And if you're just getting started and have a specific question, ask away. I'll try to answer what I can.

Salesforce Headless 360: Run Your CRM Without a Browser

Dipojjal Chakrabarti — Wed, 22 Apr 2026 23:05:41 +0000

Salesforce just dropped one of its biggest architectural shifts in years at TrailblazerDX 2026, and honestly, it caught a lot of us off guard. It's called Headless 360, and the pitch is simple: run Salesforce without ever opening a browser.

If that sounds wild, stick around. This is going to change how you think about CRM development.

What Exactly Is Headless 360?

Here's the short version: Salesforce took its entire platform - CRM, Data Cloud, workflows, business logic, all of it - and made every piece available as an API, an MCP (Model Context Protocol) tool, or a CLI command. No GUI required.

Think about that for a second. Instead of clicking through the Salesforce interface to update a record, run a flow, or pull a report, an AI agent can just call the right API and get it done. The browser becomes optional.

This isn't some minor enhancement. Salesforce is essentially saying, "Our platform is now infrastructure." It's the same data, the same security model, the same business rules - but instead of humans navigating screens, AI agents interact with everything programmatically.

For those who want to brush up on terms like MCP or API-first architecture, salesforcedictionary.com has solid definitions that break these concepts down without the jargon overload.

Why This Matters for Developers

If you're a Salesforce developer, this is where it gets really interesting. Headless 360 shipped with more than 60 new MCP tools and 30+ preconfigured coding skills. These give external coding agents - tools like Claude Code, Cursor, Codex, and Windsurf - direct, live access to your entire Salesforce org.

That means metadata, data, workflows, and business logic are all accessible to your AI coding assistant. You can describe what you want built in plain English, and these agents can actually read your org's schema, understand your existing code patterns, and generate solutions that fit your specific setup.

This also connects to the new DevOps Center MCP, which brings deployment workflows into the same agent-accessible layer. So it's not just about writing code anymore. It's about the full lifecycle - build, test, deploy - all orchestrated through agents when you want it to be.

One of the more practical use cases I've seen discussed is automated testing. Imagine an agent that reads your Apex classes, generates test methods based on your actual business logic, and deploys them to a scratch org for validation. That's not theoretical anymore. The infrastructure is there.

The Agentforce Experience Layer (AXL)

Alongside Headless 360, Salesforce announced the Agentforce Experience Layer, or AXL. This one is for anyone who's ever had to build the same UI component for three different platforms.

AXL lets you define an experience once - the schema, layout, actions, everything - and it renders natively across multiple surfaces. We're talking Slack, Microsoft Teams, mobile apps, and even third-party AI interfaces like ChatGPT and Claude. Build once, run anywhere.

The real benefit here is that your agent logic and your presentation layer are now separate. You can update how an agent works without touching the UI, or redesign the UI without rewriting your agent logic. For architects, this is a massive win because it cuts down the front-end overhead significantly.

Say you build an approval workflow for expense reports. With AXL, that same workflow shows up as interactive approval cards in Slack, a native component in your Salesforce mobile app, and a conversational flow in Teams. One definition, multiple surfaces. That's genuinely useful.

If you're new to concepts like experience layers and MCP tools, I'd recommend checking out the Salesforce terminology guides on salesforcedictionary.com to get oriented before going deeper on the documentation.

AgentExchange: The New Unified Marketplace

Salesforce also merged AppExchange, Slack Marketplace, and the Agentforce ecosystem into a single destination called AgentExchange. It consolidates about 10,000 Salesforce apps, 2,600+ Slack apps, and 1,000+ Agentforce agents into one searchable, AI-powered marketplace.

The consolidation makes practical sense. Instead of hunting through three separate marketplaces to find tools for your org, you search once. AgentExchange includes integrated billing, semantic search, and one-click activation. Salesforce even backed it with a $50 million AgentExchange Builders Initiative to help partners build and monetize on the platform.

For admins and architects evaluating solutions, this simplifies procurement quite a bit. You can find an agent, a Slack app, and a managed package all in one place, compare them side by side, and activate with unified billing.

What About Agentforce Vibes 2.0?

One more thing from TDX that's worth covering: Agentforce Vibes IDE got a major upgrade. Previously known as Code Builder, it's now a browser-based, cloud-hosted VS Code environment that launches directly from Setup.

The 2.0 version adds multi-model support - Claude Sonnet and GPT-5 alongside Salesforce's own models - and it understands your org's metadata, schema, and existing code patterns. So when you ask it to generate an Apex trigger or build a Lightning Web Component, it doesn't give you generic boilerplate. It gives you code that actually fits your org.

Even better, every Developer Edition org now gets free access to Agentforce Vibes IDE with Claude Sonnet 4.5 as the default coding model, plus Salesforce-hosted MCP servers. If you haven't spun up a dev org recently, now is a good time.

Real Results Already Showing Up

This isn't just hype. Some companies are already seeing real results with these agent-first patterns. Engine, a travel management platform, reported that their AI agent "Eva" now handles 50% of customer chat cases autonomously, cutting average handling time by 15%. No human ever opens a CRM tab for those interactions.

That's the promise of Headless 360 in action. The CRM data and logic are still there, still governed, still secure - but the interaction happens through agents instead of through a browser window.

What Should You Do Right Now?

If you're a developer, start exploring the MCP tools. Spin up a Developer Edition org and try connecting an external coding agent to your Salesforce environment. The learning curve isn't steep, but the sooner you get comfortable with these patterns, the better positioned you'll be.

If you're an admin, pay attention to AXL and AgentExchange. The way you evaluate and deploy solutions is about to change, and understanding how agents interact with your org's data will be valuable.

And if you're an architect, Headless 360 is probably the most significant thing to come out of TDX in years. Start thinking about which of your current integrations could benefit from an agent-first approach.

The Salesforce platform is evolving from something you log into to something that works for you in the background. That's a big shift, and it's happening fast.

For more Salesforce terminology explained in plain language, visit salesforcedictionary.com.

What are your thoughts on Headless 360? Are you already experimenting with MCP tools? Drop a comment - I'd love to hear what you're building.