Explanation:

Option C (Correct):

Salesforce supports Bring Your Own LLM (BYOLLM) in Einstein Studio. By registering the Amazon Bedrock model as a BYOLLM, the Specialist can explicitly bind the prompt template to that model. This ensures deterministic routing and compliance with the requirement to avoid default OpenAI models.

Option A:

Restricting metadata access via permission sets does not control runtime model routing. Even if the Agent User cannot read OpenAI metadata records, the system could still attempt to route prompts to the default model. This does not guarantee compliance.

Option B:

Configuring a Data 360 Private Connect endpoint reroutes traffic at a network level, but it applies globally, not at the prompt template level. The requirement is specific to one customer service prompt, so this approach is too broad and lacks precision.

Reference:

Salesforce documentation on BYOLLM in Einstein Studio explains how external models (like Amazon Bedrock) can be registered and explicitly selected for prompt templates, ensuring compliance and deterministic routing.

Explanation:

Agentforce Observability and session tracing parse complex, multi-turn AI logs from Data Cloud in real-time or near-real-time to map out the reasoning paths, executed actions, and classification details of human-to-agent conversations.

Why B is correct:

When an end-user session finishes or goes idle, its logs enter a telemetry queue. Before Data Cloud completely ingests, transforms, and runs analytics workflows on the interaction data, the session stays in an "unprocessed" state. If a specialist jumps into the troubleshooting panel right away and finds nothing under the Processed Sessions tab, the best next operational check is the Unprocessed Sessions tab to see if it is simply queued in the pipeline.

Why A is incorrect:

The absence of a single session does not mean the agent itself isn't registered with the Observability application. If the agent weren't registered, you wouldn't track any history at all, rather than missing just the most recent user interaction.

Why C is incorrect:

A 24-hour batch processing model would make active real-time troubleshooting and debugging impossible. Agentforce session logs do not rely on daily batch windows; they flow continuously through ingestion pipelines.

Reference

Salesforce Agentforce Management & Monitoring: Troubleshooting with Agentforce Observability. The Observability workspace splits session tracking data into processing states. Real-time traces first clear the ingestion and parsing pipeline (visible under Unprocessed/Pending states) before moving completely into the fully parsed Processed Sessions log dashboard.

Explanation:

When configuring an Omni-Channel Flow (often referred to as an Omni-Flow) to manage conversations, cases, or transfers between humans and agents, Salesforce uses a unified workflow core action.

Why B is correct:

Route Work is the official standard core action element in Omni-Channel flows used to direct incoming records (like a Messaging Session or Voice Call) to its final destination. Within the configuration settings of the Route Work action, you specify the routing target by setting the Route To parameter.

For human agents, you can set it to a specific Queue, Skills, or an individual Agent. For AI escalations, you select Agentforce Service Agent within this exact same action block.

Why A and C are incorrect:

Neither "Route Conversation" nor "Route to Agent" are valid structural element names inside the Salesforce Flow Builder palette. They are descriptive terms for what the routing engine accomplishes, but they do not exist as standalone components.

Reference
Salesforce Service Cloud & Agentforce Help: Route to an Agentforce Service Agent / Create an Omni-Channel Flow. To route interactions dynamically within an Omni-Channel flow, administrators must drag the Route Work action onto the Flow Builder canvas and set the input parameters to define the target destination.

Explanation:

A Flex Prompt Template is designed to be extensible. If a business later decides that the prompt should accept an additional input—such as a PDF document—you do not need to recreate the template or reindex it. Instead, you can update the existing template by adding another resource.

Why B is correct

Agentforce allows you to modify an existing Flex prompt template by:

• Opening the template.
• Navigating to the Resources section.
• Adding and configuring the new resource (in this case, a PDF input).
• Updating the prompt logic to reference the new resource as needed.

This preserves the existing template while extending it to support additional inputs.

Why the other options are incorrect

A. Reindex in order to add a new resource to an existing template

Reindexing is associated with refreshing indexed data for search or retrieval scenarios. It is not the mechanism for adding a new input resource to a Flex prompt template.

❌ Incorrect.

C. Discard the current Flex template and create a new one with a resource

Recreating the template is unnecessary. Flex prompt templates are intended to be editable and support adding resources over time.

❌ This adds unnecessary work and loses continuity with the existing template.

Key Exam Concept

Flex Prompt Templates are editable after creation. If requirements evolve, you can:

• Add new resources.
• Configure additional inputs.
• Update prompt instructions.

There is generally no need to rebuild the template simply because new inputs are required.

References
Relevant Salesforce resources include:
• Prompt Builder documentation on Flex Prompt Templates and Resources.
• Trailhead: Get Started with Prompt Builder – Managing prompt template resources and inputs.
• Salesforce Agentforce documentation covering prompt template configuration.

Explanation

The recommended tool is the Model Playground.

Why Model Playground?

• It allows you to test prompts, actions, and agent behavior against multiple simulated or real-world user utterances in a controlled environment.

• You can iterate quickly on how the reasoning engine (Atlas) selects and invokes custom Agent actions based on different phrasings, without fully activating or deploying the action to a live agent.

• This is ideal for validating action relevance, grounding, and selection logic before going live.

Why Not the Others?

A. Agentforce:
This refers to the overall platform or agents in production/runtime — not a dedicated testing tool for pre-activation utterance testing.

B. Agent Builder:
Used for building and configuring agents, topics, and actions (including Agent Script). It is not the primary tool for rapid, multi-utterance testing of action invocation.