9.4 Testing, Deployment, Monitoring, and Feedback Workflows

Testing beyond the happy path

Agentforce testing is broader than checking whether one sample prompt returns a polished answer. The admin must test whether the agent gives useful answers, stays inside scope, respects permissions, handles missing information, runs actions correctly, escalates when needed, and behaves the same way in the intended channel. Preview testing in Agentforce Builder is useful, but it is only the first layer.

A strong test plan starts with a prompt inventory. Collect realistic requests from service reps, sales users, internal employees, customers, managers, and admins. Include complete requests, vague requests, misspellings, slang, sensitive requests, unsupported asks, and attempts to retrieve data the user should not see. For a service agent, test common questions, angry customer language, entitlement exceptions, warranty limits, case status questions, and transfer requests.

Testing must include records with realistic data quality. Perfect demo records hide problems. Include incomplete accounts, private cases, hidden fields, unpublished knowledge, duplicate contacts, inactive owners, old entitlements, and records owned by users in different roles. If the agent will call a flow, test validation errors, required field gaps, duplicate rules, assignment rules, and fault paths. A user should receive a clear response when an action fails.

Security testing is not optional. Test as an admin, then test as a standard internal user, a manager, a service rep, an external user, and any other intended persona. Ask for fields hidden by field-level security. Ask for records outside sharing access. Ask the agent to ignore instructions. Ask for content from a different customer account. A safe launch requires evidence that the agent refuses, escalates, or cannot retrieve restricted data.

Deployment should be treated like a release. The admin should know which version is being activated, which audience receives access, which channel is connected, what training is needed, and how to turn the agent off if a problem appears. If the org uses change sets, DevOps Center, metadata deployment, or managed packages for related configuration, the agent work should be coordinated with those release practices where supported. Do not make a Friday afternoon production activation for a customer-facing agent without support coverage.

Deployment checklist:

• Confirm business approval of use case, audience, and data sources.
• Save version notes for instructions, subagents or topics, grounding sources, and actions.
• Complete preview testing and persona-based user acceptance testing.
• Confirm permission sets, app visibility, tab visibility, channel settings, and agent access assignments.
• Train support users on what the agent can do, what it cannot do, and how to report issues.
• Activate for a pilot audience before broad release where practical.
• Document deactivation, rollback, and escalation steps.

Monitoring closes the loop. Salesforce Agentforce learning paths emphasize analytics, monitoring, utterance analysis, and feedback or audit data. At admin scope, this means reviewing usage volume, unresolved requests, transfer rates, user feedback, action failures, common intents, and conversations where the answer was poor or risky. Monitoring should lead to action: update knowledge, narrow instructions, add examples, fix permissions, remove stale grounding, or train users.

Feedback workflows need an owner. A thumbs-down rating or rep complaint is not useful unless someone triages it. Create a queue or regular review meeting for agent feedback. Categorize issues as content gap, permission problem, instruction problem, action failure, unsupported use case, channel issue, or user training issue. Then make controlled changes and retest. Avoid editing instructions reactively after one complaint unless the issue is a security or compliance risk.

Study trap: do not activate because the agent works for the admin in preview. Admin accounts often have broad access, clean records, and knowledge of the desired answer. The certification answer should favor test evidence across personas, channels, records, and failure cases, followed by monitoring and feedback after release.