# Governed Agentforce From Sandbox to Production for a Consumer Products Brand

> A consumer products brand wanted AI working inside its existing Salesforce org, on its own records, without opening a security gap. We configured and tested Agentforce and its AI actions in a sandbox, fixed what testing found, designed the permissions, and took it into production in a controlled rollout.

- Source: https://synconai.com/case-studies/consumer-products-agentforce-to-production
- Publisher: SynconAI (https://synconai.com)
- Type: Case study
- Evidence: Delivered client engagement. The client is anonymised; the industry, products and outcomes are theirs.
- Organisation: An Australian consumer products and retail brand with an established Salesforce org, introducing AI into its day-to-day business processes
- Industry: Consumer Goods & Retail
- Products: Agentforce, Einstein, Salesforce Platform, Permission Sets
- Service: Salesforce Agentforce Consulting (https://synconai.com/salesforce-agentforce-consulting)
- Reading time: 6 minutes

## In short

We took Agentforce from sandbox to production for an Australian consumer products brand. We configured the agent and its AI actions on the brand’s own Salesforce records, tested it against real scenarios and fixed what testing found, designed the permissions so the agent could do only what its job required, then set it up in production in a controlled rollout.

## Key points

- Start with the job, not the model. An agent with a defined task on defined records is testable; an agent asked to help with everything is not.
- Build and break it in a sandbox. Every defect found in testing is one a customer or a colleague never sees.
- Treat the agent as a user. It needs permissions designed on least privilege, the same as any person with access to business records.
- Plan the production step as its own piece of work. Setting up and verifying the configuration in production is where many AI pilots stall.

## Sandbox to production for an AI agent

The work starts by choosing the business processes the agent should support and the records it is allowed to read and change. Agentforce is configured in a sandbox with its topics, instructions and AI actions, grounded in the brand’s own Salesforce data. Testing runs real scenarios against the agent and surfaces defects, which are fixed in the sandbox. Permissions are designed so the agent and its users can do exactly what the process needs and nothing more. The configuration is then set up in production, checked again, and handed over with the brand’s team in control.

### 1. Scope

- Business processes
- Records in scope
- Success criteria

The agent does a defined job on defined data.

### 2. Configure

- Agentforce agent
- Topics and instructions
- AI actions
- Grounding

Built in a sandbox, never first in production.

### 3. Test and fix

- Scenario tests
- Defect fixes
- Retest

Testing is where an agent earns trust.

### 4. Secure

- Permission sets
- Agent user access
- Data visibility

Least privilege for people and for the agent.

### 5. Go live

- Production setup
- Verification
- Handover

A controlled rollout with the team in charge.

## The starting position

The brand sells consumer products and already ran its business on Salesforce. Its team saw the same opportunity many companies see in AI: a large amount of routine work on business records that a capable assistant could take on, freeing people for the work that needs judgment.

The team was equally clear about the risk. An AI that can read and change business records is a new kind of user, and a careless setup can expose data, make changes nobody approved or produce output nobody trusts. The brand did not want a demonstration that impressed in a meeting and then sat unused. It wanted governed AI: working in its existing org, on its own records, tested properly and introduced into production in a way the team could control.

That framed the engagement. The goal was not the most ambitious agent possible. It was a dependable first agent, delivered to production, with a process the brand could repeat for the next one.

## What we built

### 01 Agentforce configured for defined business processes

We configured Agentforce around specific business processes the brand chose, with topics and instructions that keep the agent focused on its job. A narrow, well-described job is what makes an agent testable, and testability is what makes it trustworthy.

### 02 AI actions on business records

The agent works through Salesforce AI actions that act on the brand's business records and support the related automated processes, including generating documents from record data. Because the actions run inside the platform, they respect the same data model and the same rules as everything else in the org.

### 03 Testing and sandbox fixes

All configuration was built and tested in a sandbox first. Testing ran the agent through realistic scenarios, and the defects it surfaced were fixed and retested before anything moved forward. This is the stage that turns a promising prototype into something a team will rely on.

### 04 Security and permission design

We treated the agent as a user with its own access needs. Permission sets were designed so the agent and the people working with it have exactly the access the processes require. Technical configuration choices were reviewed with security in mind, so introducing AI did not widen access to data that should stay restricted.

### 05 Production setup and handover

Production setup and configuration were planned as their own piece of work. The configuration was established in production, verified, and handed over, with delivery confirmed at the end of the engagement.

## How a governed first agent comes together

Most AI projects that fail do so in one of two ways. Some never leave the sandbox, because the step from an impressive test to a production system nobody has planned for turns out to be harder than the build. Others reach production too quickly and lose the trust of the people meant to use them after a few visible mistakes.

The sequence in this engagement was designed to avoid both. Scoping fixed the job and the data first, so there was a clear definition of success to test against. Configuration happened in a sandbox, where mistakes are cheap. Testing was treated as the main event, with fixes and retests until the agent behaved consistently. Permission design ran alongside, so security was part of the build and not a review bolted on at the end. Production setup came last and was planned in its own right, with verification after the move.

The result is more than one agent. The brand now has a working pattern for introducing AI: define the job, build in a sandbox, test until it is reliable, secure it on least privilege, and move it to production deliberately. The next agent can follow the same path faster, because the hardest decisions about data and access have already been made once.

## Why consumer brands should start this way

Consumer brands run on many small, repeated tasks across orders, products, customers and documents. That makes them a natural fit for AI assistance, and it also makes the risks concrete. A wrong change to a customer record or a document generated with the wrong figures is visible to customers quickly.

Starting with one governed agent in the existing org keeps those risks small while the team learns. It also keeps the AI close to the data it depends on. An agent working inside Salesforce reads the same records, follows the same rules and leaves the same audit trail as the rest of the business, which is far easier to govern than an outside tool with a copy of the data.

## The questions we answer before configuring an agent

Every Agentforce engagement we run starts with the same short list of questions. They are simple to ask and surprisingly hard to answer, and the answers decide whether the agent will be useful.

**What exactly is the job?** A sentence that describes the task, the person it helps and the moment it happens. If the job cannot be described in a sentence, it is too broad for a first agent.

**Which records does it need, and which must it never touch?** The answer becomes the permission design. Writing it down early stops scope from creeping into data the agent has no business reading.

**What does a good result look like?** Concrete examples of correct output become the test scenarios. Without them, testing turns into opinion.

**What happens when the agent is unsure or wrong?** A clear fallback, usually handing back to a person, is part of the design and not an afterthought.

**Who owns it after go-live?** An agent is a living part of the org. Someone on the business side needs to own its instructions and review its behavior as the business changes.

For this brand, working through those questions shaped the topics and instructions, the AI actions, the permission sets and the test plan. It is also why the production step went smoothly: by the time the configuration moved, the team already knew what the agent was for, what it could see and how to tell whether it was working.

## How we delivered it, end to end

**Scope the job and the data.** The processes in scope and the records the agent may use were agreed first.

**Build in a sandbox.** Agent, topics, instructions and AI actions were configured and tested away from production.

**Test, fix and retest.** Defects found in testing were resolved in the sandbox before any move.

**Design permissions alongside the build.** Access for the agent and its users was designed on least privilege throughout.

**Set up production deliberately.** The production configuration was planned, carried out and verified as its own step, then handed over.

## The decisions that mattered

**One dependable agent first.** A focused first release built confidence and a repeatable method.

**The agent as a user.** Designing the agent's permissions like a person's kept AI from becoming a back door to restricted data.

**Production as a planned step.** Treating go-live as its own piece of work is what got the agent out of the sandbox.

## What changed

| Area | Before | After |
| --- | --- | --- |
| AI in the org | Interest, but no governed approach | Agentforce live in the existing org |
| Routine work on records | Done manually | Supported by AI actions on business records |
| Quality | Untested ideas | Scenario-tested agent with defects fixed in sandbox |
| Security | Open question | Permission sets designed on least privilege |
| Path to production | Unclear | Planned production setup, verified and handed over |
| Next agents | Starting from scratch | A repeatable pattern to follow |

## What we would tell a brand starting this

Pick one job that matters and that you can describe precisely. Build the agent for that job in a sandbox, test it until it behaves the same way every time, give it only the access it needs, and plan the move to production as carefully as the build. A small agent that works in production does more for a business than a large one that never leaves the sandbox.

## Questions

### Did the brand need new data or a new org for Agentforce?

No. The agent works in the brand’s existing Salesforce org, on the records it already keeps. That was a requirement from the start: the value of Agentforce here is that it acts on the business’s own data inside the platform the team already uses.

### How were security and permissions handled?

The agent’s access was designed as carefully as a person’s. Permission sets give the agent and its users the access the process needs and no more, and the records the agent can read and change were agreed during scoping and checked during testing.

### How long does a first Agentforce deployment like this take?

It depends on how well defined the first use case is and how clean the underlying records are. A focused first agent on one process, with permissions designed and testing done properly, is a realistic first release. Broader agents should follow once the first one has earned trust.

---

SynconAI. https://synconai.com/case-studies/consumer-products-agentforce-to-production