A Salesforce AI demo proves that a model can produce a useful answer. Production readiness proves something harder: the right person can use the workflow with the right context, the system can constrain what happens next, failures are visible, and the business knows who owns the result.
That distinction applies whether the interface is Agentforce, Claude, ChatGPT, a custom chatbot, or an application built with an API. The model is one layer. Salesforce identity, source data, deterministic business logic, approval, monitoring, and recovery still make the workflow safe enough to operate.
Do not ask whether the AI is ready for production. Ask whether the complete operating workflow is ready for a bad answer, a denied action, stale data, a changed permission, and a human who needs to recover it.
Seven gates between a pilot and production
| Gate | Production question | Evidence to retain |
|---|---|---|
| Outcome | Which measurable job improves, and what is explicitly out of scope? | Workflow contract, owner, baseline, success measure |
| Identity | Which Salesforce identity is used, and why can it access each object, field, and action? | Auth design, scopes, permission sets, access test |
| Context | Which records, metadata, documents, or retrieved passages can enter the model context? | Data map, filters, source labels, retention review |
| Action | Which decisions remain rules, which can use AI judgment, and which need approval? | Tool inventory, risk tier, approval matrix |
| Evaluation | Does the complete workflow behave acceptably across normal, ambiguous, denied, and hostile inputs? | Evaluation set, expected results, release threshold |
| Recovery | How is a bad write prevented, reversed, or escalated? | Preview path, rollback plan, runbook |
| Operation | Who reviews failures, access drift, model or tool changes, and adoption? | Dashboard, alert routes, review cadence, named owner |
1. Write the workflow contract before the prompt
A useful contract names the user, trigger, sources, permitted actions, output, review point, exception path, and business measure. “Summarize an account” is a feature description. “Prepare a cited renewal brief for the account owner using these approved Salesforce fields and support records, without changing the account” is an operable first version.
Keep the first release narrow enough to evaluate. One role, one job, one environment, a bounded data surface, and either no write action or one reversible write usually teaches more than a broad assistant with undefined authority. GAT maps these layers as part of a broader Salesforce + AI operating system, not as an isolated prompt exercise.
2. Treat identity as an architecture decision
“It uses Salesforce permissions” is incomplete. Document whether the connector authenticates each person, uses a shared integration identity, invokes Apex that can run in a different context, or reaches another system after Salesforce. Then test the effective behavior—not just the intended profile.
- Start with a sandbox and the smallest object, field, metadata, and action scope the job needs.
- Test positive and negative access with representative roles, including a user who must be denied.
- Separate read, draft, write, deploy, and administrative capabilities so one approval choice does not unlock all of them.
- Define token revocation, user offboarding, environment separation, and periodic permission review.
- Inspect every downstream system and service identity in a cross-platform workflow.
The deeper checklist is in our Salesforce MCP security guide. The principle is the same for a custom API or chatbot: follow the effective data and action path from the human identity to the final side effect.
3. Keep deterministic policy out of model judgment
Models are useful where language, incomplete evidence, or synthesis matters. They are a poor substitute for a stable rule the business can state and test. Territory boundaries, required consent, entitlement, duplicate prevention, SLA clocks, record validation, and approval thresholds generally belong in Salesforce, an orchestration layer, or another deterministic control.
A strong pattern is: rules collect and constrain context; AI interprets the bounded material; rules validate the proposed action; a human approves consequential risk. Salesforce's own context-engineering guidance similarly recommends structured actions for critical business logic rather than relying only on natural-language instructions.
4. Evaluate the workflow, not just the answer
An evaluation set should exercise retrieval, reasoning, tool choice, permission boundaries, side effects, and recovery. Build it from real workflow shapes, with sensitive values removed where needed, and run it again whenever the prompt, model, data mapping, tool definition, automation, or permission model changes.
Minimum test families
- Normal: common requests with complete, current data.
- Incomplete: missing fields, conflicting records, stale documents, or no eligible owner.
- Ambiguous: requests where the workflow should clarify rather than guess.
- Denied: data and actions the authenticated user cannot access.
- Adversarial: instructions embedded in retrieved content or user text that attempt to redirect the workflow.
- Tool failure: timeouts, limits, partial responses, validation errors, and downstream outages.
- Regression: previously accepted cases that must remain stable after a change.
Score what the business cares about: source correctness, required-field completeness, appropriate abstention, unauthorized-access prevention, valid tool arguments, correct approval behavior, and recoverability. A fluent answer is not a sufficient release criterion.
5. Design approval around risk, not around every click
Requiring approval for every harmless read makes the workflow unusable. Automatically approving every write makes it unsafe. Classify actions by reversibility, customer impact, financial or regulatory consequence, scope, and confidence in validation.
| Risk tier | Example | Typical control |
|---|---|---|
| Read | Retrieve permitted pipeline or case context | Source citation, access logging, bounded fields |
| Draft | Prepare a brief, reply, recommendation, or proposed record changes | Human review before external use or write |
| Reversible write | Create a task or update a low-risk field with history | Preview, validation, selective approval, audit trail |
| Consequential action | Change ownership, communicate externally, deploy metadata, or affect eligibility | Explicit approval, tighter roles, sandbox or check-only path, recovery plan |
OpenAI's current MCP guidance defaults toward approval and recommends restricting allowed tools and keeping sensitive actions behind an approval flow. The exact implementation differs by platform, but the architectural question is durable: who can authorize the side effect, with what evidence, and how is that decision recorded?
6. Make rollback and failure handling part of the happy path
Define what happens when the model chooses the wrong tool, Salesforce rejects a write, only part of a multi-system flow succeeds, a record changes between preview and execution, or the model cannot support its conclusion. Where possible, use idempotency, validation-only operations, record history, staged changes, transaction boundaries, and explicit reconciliation jobs.
The user needs a useful failure state: what did not happen, what remains safe, what can be retried, and who owns the exception. “Something went wrong” is not an operating control.
7. Assign ongoing ownership before launch
Production changes after go-live. Permission sets evolve. Salesforce fields and automations change. Retrieved knowledge ages. MCP tools gain capabilities. Model behavior and platform controls change. Adoption introduces requests the original pilot never considered.
Name the person or team accountable for access review, evaluation regressions, tool and prompt changes, incident response, user feedback, and outcome reporting. That owner may be internal, a Salesforce AI engineering team, or a managed partnership. It cannot be “the model.”
A practical release sequence
- Observe: map the existing human workflow and baseline its volume, delay, errors, and handoffs.
- Read: let a small role-based group retrieve and synthesize approved context without writes.
- Draft: generate proposed work while a person remains the executor.
- Approve: add a narrow, reversible action with visible inputs and explicit review.
- Automate selectively: remove approval only for well-evaluated, low-risk actions with reliable recovery.
- Expand: add roles, systems, and actions only after operational evidence supports them.
Official references
- OpenAI: MCP and connectors—approvals, allowed tools, and risk guidance
- OpenAI: enterprise app and connector control layers
- Salesforce Developers: context engineering and structured actions
- Salesforce: Agentforce security and shared responsibility
- NIST AI Risk Management Framework
If you have a candidate workflow, GAT can run the architecture and readiness review, implement the smallest safe path, and stay accountable after launch. Start with a consultation, or see how we implement Salesforce MCP workflows.