Top 5 Developer Announcements at TrailblazerDX 2025

Thinking back over what TDX has been throughout its history since 2016, there has never been a year where the theme was so single-minded. In case you hadn’t heard, it’s Agentforce.

You’d be forgiven if you thought there was nothing else to learn at TDX this year. The good news is, there’s more…

Spring ‘25 Redux

This major conference fell less than a month from the recent Spring ‘25 major release. As you might imagine, much of what’s being shared at the event points back to those recently released features. Salesforce Ben recently published the 6 Salesforce Spring ‘25 Updates for Developers. To recap, we discussed the following: 

• LWC Local Development for Desktop and Mobile
• Lightning Design System 2 (SLDS 2)
• Zip in Apex
• Dynamic Formula Evaluation in Apex
• ApexGuru 
• The retirement of:
  • API versions 21.0-30.0
  • Instance-based domain names
  • Salesforce Functions

If you haven’t already read about the details of those changes, you’ll definitely want to take a quick read before you continue here, especially because, for some, TDX brought additional clarity and details! Where there’s news about these, we’ll provide updates here. So, let’s dig in. 

Agentforce News for Developers

Yes, there was more than Agentforce. But let’s start there, because there were useful features announced for anyone incorporating Agentforce into their work today. Be sure to check out the new Agentforce Developer Guide for instructions on how to implement any of the currently GA features. 

1. Agentforce on Developer Edition Orgs

One of the core strengths of Salesforce’s approach to developers has always been the free Developer Edition org. Everyone has one. Many features that require additional license fees in standard Enterprise Edition orgs appear there for free, at allocations or limits big enough to learn how to use them, but not big enough to ever be practical for any real production usage. 

Since the inception of Salesforce’s big generative AI pivot, the DE org has been a barren wasteland, cut off from LLMs, RAG, and agents. Well, not anymore. 

Coinciding with day one of TDX, new Developer Edition orgs are now delivered with Agentforce enabled. Salesforce will rate-limit your Agentforce-enabled DE org to 150 LLM outputs per hour. You are also limited to a single data space with a capacity of 10GB of data. Given that a single call to the Atlas engine can touch several LLMs, it’s unclear at the moment whether that means a single 150 agent outputs or if one call to Agentforce consumes several of that allocation. But for the purposes of experimentation and learning, it still seems like it’s probably enough to suit most needs. 

While I’ve signed up for my new DE org, I’ve not yet had a chance to abuse it and see what that amount of inference and data will allow. But at first glance, this seems like an adequate, if not generous, set of limits for developers, admins, and other practitioners to work with as they test, learn, and master Agentforce. No word on how to get Agentforce in an existing DE org.

Ready to get your own Agentforce-enabled DE org? You need only head over to the standard DE org signup today and you too can get hands-on with Agentforce. 

2. Agent Tooling and Configuration

In the keynote, we were treated to several demos of agents, of course. The investment in tooling and features to help build agents is clear. Agent templates can help you bootstrap agents with common goals and features. If there is no template that suits, there is an AI assistant to help you bootstrap that agent. The bootstrapping of that agent may even include discovery and suggestions of features in your org that have been registered as actions, which would suit the business requirements of that new agent.

One very impressive aspect of this is that every mode of building, configuring, and deploying an agent seems to be supported by both developer-centric and admin-centric tools. Want to build an agent from the setup menu? No problem. Go for it. Prefer to do it from the CLI? You can do that too with the sf agent CLI plugin. Trying to understand the footprint of metadata that was created for an agent? The new DX Explorer catalogs the dependencies involved with a given agent through the UI. Or, of course, you can pull it down as standard metadata as part of a project. You can even run agent tests now, both from the CLI and from the UI. 

While some features are not yet GA, notably the Salesforce CLI plugin sf agent, these are all expected in the near term. 

3. The Agentforce API

Given the vast and rapidly changing landscape of generative and agentic AI, it’s hard to imagine every Salesforce customer will settle on a Salesforce-only approach. But if that does become your strategy, once you’ve done the work to deploy an agent, and if you want to surface that to other systems, you’ll want to access it via API. 

The Agentforce API is now live and available. It uses the server-sent events (SSE) HTTP standard. SSE is a long-running, one-way HTTP connection that is used to chunk progressive bits of a longer response. It’s perfect for a long-running agent that produces bits of inference at a time to provide users feedback on the progress of a running agent request. Although, there is also a synchronous mode that uses a standard single HTTP request if your API usage is agent-to-agent, which would be easier to implement. 

Being a long-standing feature of HTTP, SSE is well supported by many languages, such as JavaScript, Python, and Java. 

4. Action All The Things

When an agent gets to work, actions represent the work that can be done. Thus far, actions have been limited to either Apex or Flow. But this is all changing.

A lot of work has been underway to provide even more actions for your agents to take. Specifically, anything that can publish an OpenAPI Spec document. This means Apex REST APIs, Heroku APIs, MuleSoft APIs, and third-party external services are all available to use. Any of these can be ingested and made available to Agentforce as actions now, with the OpenAPI Spec document serving as the means of surfacing the human-language definition to the Agentforce framework.

In addition to these, agents will also soon be able to publish and subscribe to platform events.

To support this, there is also a new VS Code plugin to generate the OpenAPI Spec for Apex REST.

5. Agentforce for Developers

Work continues on improving agentic developer tools. Several presentations showcased Agentforce for Developers, the prompt-to-code VS Code plugin. In several cases, the demos didn’t come off – either the selected prompt seemed too unrealistic (to me) or the agent struggled to generate the desired output. 

However, there were certainly demos that looked like code generation is heading in the right direction. The most compelling one for me was the agentic conversion of Aura components into LWC. This is also not GA yet, but it did successfully create a Lightning Web Component. There was also a demo to generate a new LWC Jest test. Combining these two capabilities could make converting your old Aura code into LWC much easier in the future. These both deserve looking into further as they progress.

Lightning Out Revived

Lightning Out allows you to embed a piece of Salesforce UI in another web app. This requires that app to make an authenticated request to Salesforce, request and render that piece of Salesforce UI, and ensure that nothing bleeds between those two apps. It’s a powerful feature that allows you to embed Salesforce in web portals, webmail, and any other system that just needs a little bit of Salesforce in it.

You may have implemented and released a feature using Lightning Out. Apparently, thousands of orgs contain features implemented with Lightning Out, but it was never made beyond beta.

The Lightning UI team shared that this feature is scheduled to finally be made GA later this year! Implementation details will focus on security using an iframe, content security policy, and Shadow DOM. The architecture will be based on Lightning Web Runtime and will use a CDN and async loading of resources to ensure performance is optimal. Work is also underway to ensure it works with both SLDS and SLDS 2 and that there is a working event-based link between the host app and the hosted LWC UI.

Heroku AppLink

For over a year, we’ve been marking time on the end of Salesforce Functions. This short-lived feature, designed to provide elastic scalability to Salesforce orgs using Heroku-like infrastructure, held a lot of promise as a whole new way to provide runtime to Salesforce solutions. Sadly, it never gained traction.

Enter Heroku AppLink. This pilot feature shows great promise as a means to solve the elastic scale problem for Salesforce customers, but in ways that improve on the original Functions design. Functions were first-class members of the platform, with their own set of features in the Salesforce CLI for deployment to the cloud infrastructure that ran it.

AppLink takes a different approach. Specifically, if you solve the connection problem between Heroku and Salesforce, then there’s no reason you can’t have everything you would have had with Functions. So this is how AppLink works: the right tooling to connect Salesforce and Heroku.

The key pieces of functionality around AppLink are a Heroku Add-On and the heroku salesforce CLI commands. Once you add the plug-in, you can create your app, build it, add the add-on, deploy it to Heroku, and use heroku salesforce:connect to create the connection to a Salesforce org. Using heroku salesforce:import sets up metadata in the Salesforce org, including an external service.

Within the app itself, you now have a working connection to Salesforce, accessible via a Salesforce SDK. The Salesforce SDK makes it so that you can access the now connected org easily.

The more I consider how AppLink works, the more it really feels like a classic Heroku approach in that it makes a potentially irksome and lengthy process easy and elegant.

Revisiting Spring ‘25 Release

At TDX we learned some new details about two of the items that we discussed in the Spring ‘25 developer release article.

LWC Local Development

In the original 2019 LWC Local Development feature, it was a standalone component preview. Initially, the new GA version did away with that in lieu of the full application UI. Due to popular demand, the decision to do away with the single-component preview has been reversed. So, you can now run and test a component either in a standalone mode or in place in the full app UI.

API Version Retirement

While nothing is changing here as far as what is to be retired and when, the integration product team made a useful suggestion that’s worth remembering: there is a release update which can be turned on in your sandbox to trial API retirement. Turning on this feature disables the to-be deprecated API versions. Doing this early will allow you to test your readiness in advance of the eventual sunset of these API version. Do it today!

Generics Deprioritized

As a quick footnote, the Apex Roadmap session brought up a long-desired feature: generics. While this feature has been on the roadmap for a while and there is a plan for how to deliver them, it is a significant feature. Because of the current priorities of the product team, generics for Apex have now been removed from the roadmap and put into the long-term backlog.

Summary

This TDX brought massive amounts of change, and not all of it was Agentforce. If you have a favorite feature that you loved but we didn’t mention, be sure to find our social post about TDX and share it there.

Any thoughts? Leave them in the comments below!