9.6 Agentforce Risk, Troubleshooting, and Governance

Risks admins must recognize

Agentforce risk is not limited to dramatic AI failures. Most admin risks are ordinary platform risks expressed through a conversational interface. The agent might retrieve the wrong record, summarize stale data, reveal a hidden field, run an action with unexpected side effects, cite an outdated article, fail to transfer a customer, or make a confident statement when the source is weak. Good governance keeps these risks visible and manageable.

The first risk category is data exposure. If grounding includes internal files, old drafts, private notes, or records with weak sharing, the agent can produce answers that users should not receive. The second category is inaccurate output. A fluent answer can still be wrong if the source is stale, incomplete, or ambiguous. The third category is action risk. Creating, updating, routing, or escalating records can trigger validation rules, flows, approvals, assignment rules, notifications, and integrations.

Troubleshooting should be layered. Start with availability: is the feature enabled, is the edition or add-on present, and does the user have the required permission set? Next check navigation: is Agentforce Studio visible in the App Launcher, is the app assigned, and are tabs visible? Then check the agent configuration: is the right agent active, is the channel connected, are subagents or topics enabled, and are instructions saved? Finally check data, actions, and runtime context.

When an answer is wrong, do not edit instructions blindly. First identify whether the answer came from an approved source, generic reasoning, a stale article, missing record data, or a misunderstood request. If the source is wrong, fix the source. If the source is missing, add approved grounding. If the request is unsupported, improve refusal or escalation behavior. If the prompt is ambiguous, add examples or narrower instructions. Retest the exact transcript and related edge cases.

Governance model checklist:

• Use-case owner approves what the agent may and may not do.
• Content owner approves knowledge, documents, and data libraries used for grounding.
• Security owner approves permissions, sharing, channel exposure, and retention.
• Admin owner manages configuration, activation, access assignments, and monitoring.
• Developer owner supports Apex, external actions, integrations, and complex flow errors.
• Support owner triages user issues, feedback, and incident reports.
• Change owner controls versioning, release notes, rollback, and deactivation.

Prompt injection and instruction conflicts deserve attention. Users may ask the agent to ignore instructions, reveal internal rules, provide restricted data, or perform unsupported actions. An admin cannot solve this only with a longer instruction paragraph. The agent should have clear refusal behavior, restricted grounding, limited actions, and security tests that include adversarial prompts. Sensitive operations should still require permission checks and approvals outside the conversation.

Audit and retention are part of governance. Conversation logs, feedback, generated outputs, and action records can contain sensitive data. The admin should know who can view monitoring data, whether it is stored in Data Cloud or another supported location, how long it is retained, and how it is used for improvement. Monitoring access should be limited to people who need it for support, compliance, or product ownership.

Study trap: do not troubleshoot Agentforce as one black box. Break the problem into feature enablement, app access, user permission, data source, grounding, action, automation, sharing, channel, and monitoring layers. This approach leads to better answers in scenarios and better support in a real org.