Salesforce Builder Central is a workspace inside Salesforce where admins and builders describe an app or an agent in plain language and have it built, previewed and deployed from one place. Salesforce announced it on September 14, 2026, and it is in beta. Before you assign it to anyone, settle a short list of questions about access and review. A tool that builds metadata in your org touches your change process whether or not you planned for that.
This guide gives you seven checks to run before your team uses Builder Central, in the order most admins will meet them. It is written for admins who run an org alone or with a small team and need to decide how a new builder fits the process they already have. The Cirra AI page for Salesforce admins describes how admins hand routine configuration to an AI client while they keep the judgment calls.
Builder Central is in beta, so details will move. The facts below come from Salesforce's own announcement, product page and Trailhead module as of October 22, 2026. Confirm each one in Salesforce Help for your release before you act on it.
What Builder Central does today
Salesforce describes Builder Central in its announcement as a single workspace where you manage environments and build by conversation, with deployment included. From that workspace you can configure testing and live environments, activate features, apply security best practices and clean up orgs. You can also describe an idea in plain language and have it turned into a working app or agent.
The Trailhead module on Builder Central walks through the build flow. You describe the app, review a plan, approve the build and see a live preview. You then refine it in a property panel or by asking the Build Agent in chat, and deploy it to a sandbox. From one description, Builder Central generates the app's objects, pages, flows and an agent. Metadata visualizations show the data model, the agent, the flows and the permission set as interactive diagrams, and a temporary preview org opens in a new tab so you can test against real metadata.
The beta covers creating apps and agents, visualizing metadata and deploying to a sandbox with one click. Salesforce says it plans to add build and deployment capabilities, including capabilities from Setup with Agentforce, as Builder Central moves toward general availability. Salesforce's announcement and product page give no general availability date and no pricing.
The seven checks at a glance
Each check has one question to answer and one thing to keep as evidence. The sections after the table explain each one.
| Check | Question to answer | What to keep |
|---|---|---|
| 1. Terms and cost | Who has read the beta terms, and what usage do you expect? | A note from the contract owner |
| 2. Edition and activation | Does your edition qualify, and have you tried activation in a sandbox? | The activation steps you confirmed |
| 3. Who gets access | Which named people need the permission set? | An access list with a review date |
| 4. Path to production | Which release route carries a finished build to production? | The route, the validator and the approver |
| 5. Review of output | Does the generated metadata meet your standards? | A review record per build |
| 6. Data exposure | Do test users see only what they should? | Test results for each persona |
| 7. Ownership | Who maintains what it builds? | Descriptions, a change log row and an owner |
Check 1: Read the beta terms and decide what usage you expect
Trailhead describes Builder Central as a pilot or beta service that you use at your discretion under beta terms. It also says the service uses generative AI, which can produce inaccurate responses, and that the entitlements consumed by services that are not generally available give rise to no refund or credit rights. Salesforce's announcement states no pricing.
Ask whoever owns your Salesforce contract to read the beta terms before you assign the permission set. Write down what you expect your team to use in the first month so a surprise on the entitlement side does not land on the admin.
Check 2: Confirm your edition and the activation steps in a sandbox
Salesforce's Builder Central page lists Lightning Experience on Enterprise, Performance and Unlimited editions, plus Developer Edition with Foundations or the Agentforce 1 add-on. The same page says an admin turns the feature on in Setup by granting the Access Builder Central permission set to themselves and their team and enabling the Builder Central Beta feature. After that, users open it from the App Launcher.
Salesforce Ben's roundup of admin news from Dreamforce 2026 describes Builder Central as needing nothing beyond a permission set assignment and calls it free in every org. Salesforce's own page lists specific editions and Trailhead refers to beta terms, so the sources do not line up neatly, which is common for a beta. Try the activation in a sandbox first, write down what you did, and check the result against Salesforce Help for your release.
Check 3: Decide who gets the permission set
Salesforce says apps and agents built in Builder Central inherit the existing permissions and org configuration of the user. That makes the access of the person running a build part of the risk. A builder with broad access can reach more of your org than a builder with a narrow permission set.
Start with named admins. Record who holds the Access Builder Central permission set, and put a review date on the list so the access ends or is renewed on purpose. The post on least privilege for AI agents in Salesforce covers how to scope access for any tool that acts in your org.
Check 4: Fix the path from build to production
In the beta, Builder Central deploys to a sandbox with one click. Trailhead says that making the app available in production is a separate step outside Builder Central. That gap works in your favor, because your existing release route still decides what reaches production.
Write down which route that is. Change sets and Salesforce CLI are common routes, and DevOps Center works too. Name the person who validates the deployment and the person who approves it. The Salesforce change management checklist gives you a seven-stage routine that fits anything Builder Central produces, including a rollback plan and a change log.
The temporary preview org is useful for a first look at real behavior. Treat it as a preview and run your own testing in a sandbox that matches production.
Check 5: Review what it generates before anyone relies on it
Builder Central can generate objects, pages, flows and an agent from one description. Treat that output as a draft from a colleague whose work you have not reviewed before. Trailhead advises you to review the output before you deploy it, and it positions the metadata visualizations as the place to review. Changes happen in the Preview.
Open the data model, flow and permission set views and compare each against your standards. Four questions cover most of it:
- Do the object and field names follow your naming convention, and does every field have a description?
- Does each flow have a fault path, and does it avoid duplicating automation already on the same object?
- Does the permission set grant only what the app needs?
- Did the build create an object or field that your org already has under another name?
Keep a short review record for each build with the date, the reviewer and the changes you asked for. If a build fails review, change it in the Preview or ask the Build Agent for the fix, and review again.
Check 6: Test with real personas and check data exposure
Salesforce says Builder Central reads your org metadata and Data 360 context, enforces your existing field-level security and user permissions, and keeps your data inside your tenant. These are Salesforce's own statements, so verify them in your org.
Verification takes a few test users. Run the new app as someone whose permissions should hide a sensitive field and confirm the field stays hidden. Include a user who should be blocked from the new object entirely. If Builder Central builds an agent, ask it the questions it should decline and read the answers. Record the result for each persona.
Check 7: Name an owner for everything it builds
A generated app becomes ordinary metadata in your org the day it is deployed. Someone has to maintain the flows, keep the descriptions accurate and retire the pieces nobody uses. SF Ben's 2026 Salesforce Admin Survey found that 31% of respondents report high or very high technical debt, so an extra source of metadata deserves an owner from day one.
Give each generated component a description that says why it exists, add a row to your change log and name the person responsible. If you keep documentation in sync as you build, the use case page on Salesforce org documentation with AI shows how an AI client can read live metadata and write it up for you.
Where Cirra AI fits
Cirra AI is a hosted Salesforce Admin MCP Server. You authenticate a Salesforce org through OAuth, connect the AI client you already use, such as Claude, ChatGPT or Cursor, and describe the change you need. Cirra AI makes it as the connected user, within that user's permissions. The Salesforce Admin MCP Server product page lists the capabilities, and Cirra AI supports Salesforce Enterprise Edition and up.
The seven checks above apply to any tool that changes your org, and Cirra AI gives you settings that support them. Access is set per org across four data categories (Metadata, User Data, Personal Setup Data and Business Data), and each category can be None, Read Only or Read and Write. A sandbox connection can allow metadata changes while the production connection stays read-only for metadata. Actions are logged in an exportable audit trail, which gives your change log something to compare against.
The Free plan includes 100 credits, so you can try a sandbox connection before you decide anything. Ready to see it on a sandbox? Start Free Trial, or Learn More about the product.
Frequently asked questions
What is Salesforce Builder Central?
Salesforce Builder Central is a workspace where admins and builders describe an app or an agent in plain language and have it built, previewed and deployed. Salesforce announced it on September 14, 2026, and it is in beta.
Is Builder Central generally available?
No. Salesforce describes Builder Central as a beta, and Salesforce's announcement and product page give no general availability date. Salesforce says it plans to add build and deployment capabilities, including capabilities from Setup with Agentforce, as it approaches general availability.
Can Builder Central deploy to production?
In the beta, Builder Central deploys to a sandbox with one click. Trailhead says that making the app available in production is a separate step outside Builder Central, so your existing release route decides what reaches production.
Who should get access to Builder Central first?
Start with a few named admins, and record who holds the Access Builder Central permission set. Salesforce says apps and agents inherit the existing permissions of the user, so the access of the person running a build matters.
How is Builder Central different from Setup with Agentforce?
Trailhead describes Setup with Agentforce as the tool for configuring an org and troubleshooting setup issues, and Builder Central as the tool for building apps and agents through chat and visual editing. Salesforce says Builder Central will include capabilities from Setup with Agentforce as it approaches general availability.
Can an AI client make Salesforce changes while I evaluate Builder Central?
Yes. Cirra AI connects an AI client such as Claude, ChatGPT or Cursor to your Salesforce org through OAuth and makes changes as the connected user, within that user's permissions. Connect a sandbox first and review each planned change before it reaches production.
