DEV Community: Exploring Agentforce

Building a React CRUD App on Salesforce with GraphQL

Exploring Agentforce — Mon, 07 Sep 2026 14:59:12 +0000

How much plumbing does a React CRUD App on Salesforce actually need?

I started with a prebuilt SFDX project containing a React app, generated with the Salesforce CLI. It comes with the React boilerplate and required dependencies already set up (check here how to quickly generate SFDX project with React uiBundle data). I then connected the project to a Salesforce sandbox.

The goal was simple: build a small React UI that could read and update real Salesforce Cases.

Basically, to build the integration, you just need:

1. Generate the GraphQL schema

First, generate the Salesforce GraphQL schema:

npm run graphql:schema

The schema is essentially describes the objects you can access and the queries you can make in the org.

2. Define the GraphQL operations

Using the schema, define the GraphQL operations the UI needs.

For my Cases app:

Queries: Get Cases, Get Case details
Mutation: Update a Case

3. Generate TypeScript types

Next, use GraphQL Code Generator to generate TypeScript types from the Salesforce schema and the operations:

npm run graphql:codegen

This gives the React app type-safe definitions for query results, variables, and mutations without manually defining the data shapes.

4. Setup GraphQL client

To execute the queries and mutations, use the Data SDK (@salesforce/platform-sdk).

It includes a GraphQL client and handles authentication and CSRF token management.

5. Build the UI

From there, the AI coding tool handled most of the React implementation:

Cases → Case details → Edit → Save

And that's where things got interesting.

The interesting part isn’t just GraphQL or React individually. It’s how well the pieces fit together:

React is extremely good at building the UI.
GraphQL is extremely good at fetching the data you need, including related data — you can fetch an account, its related cases, contacts, and more in a single query.
AI coding agents are extremely good at generating the React boilerplate, GraphQL queries, and wiring the pieces together.

And Salesforce already provides the backend: the data model, relationships, authentication, permissions, validation, and APIs.

You can spend less time building the integration — and more time concentrating on UI/UX and deciding what data you want to show and how you want to show it.

Resources:
Fetch data with Data SDK

Debugging AgentScript: Three Ways to Find Compilation Errors

Exploring Agentforce — Tue, 25 Aug 2026 08:07:05 +0000

If you're working with AgentScript, you may run into a frustrating situation: the agent doesn't compile, but Agentforce Builder gives you a generic error message.

Sometimes the Problems tab in the new Builder shows an error, but it doesn't give you enough information to understand what went wrong.

There are a few ways to approach debugging. This is the workflow I currently use.

1. VS Code + Salesforce DX Extensions

If you're developing AgentScript in VS Code, the Salesforce DX extensions provide syntax checking directly in the editor.

Syntax issues are highlighted as you work, so VS Code is a good first place to check when something doesn't compile.

It's fast feedback and often enough to spot an obvious syntax issue before doing anything else.

2. Salesforce CLI validation

When VS Code doesn't give you enough information, I use Salesforce CLI validation.

Run:

sf agent validate authoring-bundle

The CLI will prompt you to select the AiAuthoringBundle you want to validate.

If validation fails, the output includes: the syntax error, a short description of the error, the relevant line number in the AgentScript file.

For me, this is currently the most reliable way to validate AgentScript syntax.

The useful part is that the CLI points you to the actual location of the problem instead of just telling you that the agent failed to compile.

3. Agentforce Builder AI Assistant

There is also another option directly in Agentforce Builder: the built-in AI assistant.

You can ask it to review your AgentScript. It can identify syntax errors and also suggest improvements to the code.

However, I wouldn't rely on it as the only validation method. There is no guarantee that it will find every syntax error, and its suggestions quality can vary.

My current workflow

When an AgentScript agent doesn't compile, I usually go through these three steps:

VS Code → quick feedback and syntax highlighting
Salesforce CLI → reliable validation and specific error locations
Builder AI Assistant → additional review and suggestions

Using all three together has been much more effective than relying on a single validation method.

How to Quickly Scaffold and Deploy a React App on Salesforce

Exploring Agentforce — Tue, 18 Aug 2026 08:32:20 +0000

Salesforce provides CLI templates that can quickly scaffold a React application with a ready-to-run React/Vite setup.

There are two approaches:

Generate a complete SFDX project with an internal React app.
Generate a React UI Bundle inside an existing SFDX project.

Both give you React boilerplate that you can run, explore, customize, and deploy. The main difference is how much Salesforce setup is included and what you need to do before the app is available in the org.

Prerequisites

You'll need:

VS Code
Salesforce CLI (sf)
Salesforce Extension Pack
A Salesforce org, such as a Trailhead Playground
Node.js

Check the CLI:

sf --version

Check your connected orgs:

sf org list

Set your default org:

sf config set target-org=my-org

Option 1: Generate a complete SFDX project

If you're starting from scratch, you can generate a complete project using the reactinternalapp template:

sf template generate project --name my-react-app --template reactinternalapp

This creates a new Salesforce DX project with the React application and the Salesforce metadata needed for an internal React app.

Install the dependencies and start the React app locally:

cd my-react-app
npm install
npm run dev

You now have a prebuilt React application that you can explore and modify.

Deploying the project

From the project root:

# Build the production bundle (run command from force-app/main/default/uiBundles/react-app-name)
npm run build
# Deploy the production bundle (run from the SFDX project root)
sf project deploy start --source-dir force-app

After deployment, assign the generated permission set to your user if required by the generated project - app appears in the App Launcher.

The advantage of this approach is that Salesforce gives you a more complete starting point. You're starting with an application rather than just a UI Bundle.

Option 2: Generate a React UI Bundle

This approach is useful when you already have an SFDX project and want to add a React application to it.

From the root of your existing project:

sf template generate ui-bundle --name ReactDemo --template reactbasic

The bundle is created under:

force-app/
└── main/
    └── default/
        └── uiBundles/
            └── ReactDemo/

Inside you'll find the React application.

Install the dependencies and run locally:

cd force-app/main/default/uiBundles/ReactDemo
npm install
npm run dev

This gives you the same basic experience you'd expect from a modern React/Vite application: start with working boilerplate and then build on top of it.

Deploying the UI Bundle

Go back to the SFDX project root and deploy the bundle:

# Build the production bundle (run command from force-app/main/default/uiBundles/react-app-name)
npm run build
# Deploy the production bundle (run from the SFDX project root)
sf project deploy start --source-dir force-app/main/default/uiBundles/ReactDemo

However, this is where the two approaches differ. The reactbasic UI Bundle gives you the React application itself, but you need additional Salesforce metadata to expose it as an internal application:

A CustomApplication under force-app/main/default/applications/
A reference from the application to the UI Bundle
A permission set that makes the application visible
Assignment of that permission set to your user

Once that setup is deployed and the permission set is assigned, the React application becomes available through the Salesforce App Launcher.

Which approach should you use?

If you're starting a new Salesforce project, the complete project template is the easier starting point. If you already have a Salesforce DX project and want to add React to it, use the UI Bundle.

Both approaches solve the same basic problem: get a working React application scaffolded quickly so you can start exploring and developing. **The difference is **where you start and how much Salesforce setup you have to do yourself.

How to Retrieve and Deploy AgentScript with Salesforce CLI

Exploring Agentforce — Sun, 07 Jun 2026 19:54:04 +0000

With Salesforce CLI, you can retrieve AgentScript metadata into a DX project, work with it locally in VS Code, and deploy changes back to your org.

Prerequisites

VS Code
Salesforce CLI
Salesforce DX Extensions
Agentforce org connected to Salesforce CLI (you can also connect Trailhead playground org, see this connection guide)

Step 1. Create a DX Project

sf project generate --name agentforce-demo
cd agentforce-demo

Step 2. Authenticate to Your Org


sf org login web --alias my-agentforce-org --instance-url https://your-org-name.develop.my.salesforce.com

Verify the connection:


sf org list

Set the default org:


sf config set target-org my-agentforce-org

Step 3: Find the Agent Name

To retrieve AgentScript metadata, you need the agent name. There are several ways to find it.

Option 1: Agentforce Builder

Open your agent in the new Agentforce Builder, and in the Agent Definition view find your agent Developer Name

Option 2: View Agents with Salesforce CLI

If an agent has at least one published version, it appears as Bot metadata:


sf org list metadata --metadata-type Bot

Example output:

Full Name
------------------
CC_Service_Agent
Sales_Agent
Support_Agent

Important: This command only lists agents that have a published version. Draft-only agents may not appear.

Option 3: List AgentScript Bundles

You can also list AgentScript bundles directly:


sf org list metadata --metadata-type AiAuthoringBundle

Example output:

Full Name
------------------
CC_Service_Agent
CC_Service_Agent_1
CC_Service_Agent_2

This command will list all versions of all agents your org (draft and published).

Step 4: Retrieve AgentScript Metadata

Retrieve a specific agent:


sf project retrieve start --metadata AiAuthoringBundle:Your_Agent_Name

For example: if your agent Developer Name is "My_Agent", the command will look like this:


sf project retrieve start --metadata AiAuthoringBundle:My_Agent

Retrieved metadata is stored in:

force-app/
└── main/
    └── default/
        └── aiAuthoringBundles/

The bundle contains the AgentScript configuration used by Agentforce Builder.

Step 5: Deploy Changes Back to the Org

After making changes locally deploy them back to the org:


sf project deploy start --metadata AiAuthoringBundle:Your_Agent_Name

Important: Draft vs Published Agents

⚠️ One detail that is not immediately obvious when working with Agentforce: only draft agents can be deployed, committed (published) agents are immutable. To deploy changes, first open Agentforce Studio and create a draft version of your agent, then you can deploy changes from VS Code. If you try to deploy to committed agent, you'll get an error message.

Action	Draft Agent	Published Agent
Retrieve	✅	✅
Inspect	✅	✅
Edit Locally	✅	✅
Deploy Changes	✅	❌

In practice, this means you can retrieve metadata from both draft and published agents, but deployment targets a draft version managed in Agentforce Builder.

Using Salesforce CLI makes it much easier to inspect AgentScript metadata, use version control, and work with Agentforce in a development workflow instead of only through the browser.

Useful links

Connect a Trailhead Org to Salesforce CLI guide.

Read more in the official documentation.

How to Connect a Trailhead Org to Salesforce CLI

Exploring Agentforce — Sun, 31 May 2026 14:45:05 +0000

Take Trailhead Learning beyond the browser

Salesforce Trailhead is a great way to learn Agentforce. You can level up this experience by connecting your Trailhead org to Salesforce CLI and working with AgentScript metadata locally in VS Code. Here’s a quick setup flow for connecting a Trailhead Agentforce org to Salesforce CLI 👇

Prerequisites:
• VS Code
• Salesforce CLI installed
• Trailhead org with Agentforce enabled

Step 1. Open your Trailhead org

Launch the Trailhead playground or developer org that you want to connect.

Step 2. Find your username

Profile → Settings

Step 3. Set password (if not set already)

Settings → Change My Password

Step 4. Connect org via CLI

Authenticate via browser, setting up alias for the org and providing your Trailhead org url:


# Authenticate with your Trailhead org

sf org login web --alias your-org-alias --instance-url https://your-org-name.develop.my.salesforce.com

Step 5. Verify connection

Confirm that the org was added successfully:


sf org list

Step 6. Set the default org

To avoid specifying the org in every command, set it as the default target:


sf config set target-org your-org-alias

Important: Use the Correct Login URL

Trailhead org URLs used for login usually look like:

https://your-org-name.develop.my.salesforce.com

NOT:
• login.salesforce.com
• develop.lightning.force.com

Once connected, you can retrieve AgentScript metadata locally in VS Code, experiment faster, and work with Agentforce in a more development-oriented workflow.