Fairhaven Veterinary Network's specialist deploys an updated agent from sandbox to production using a change set that includes the agent's topics, actions, and the Prompt Builder templates they call. After deployment, the agent works for most staff but a newly hired front-desk coordinator cannot invoke it at all. What did the change set most likely fail to carry over?
Select an answer to reveal the explanation.
Short Explanation
Metadata like topics, actions, and templates travels in the change set, but who gets access to use them is a permission-set assignment on a specific user record, and that has to be granted in the target org separately, it doesn't just ride along.
Full Explanation
Change sets move configuration metadata such as topics, actions, and Prompt Builder templates, but they do not automatically grant end users access to that metadata in the target org. Access to invoke an agent depends on the correct permission set being assigned to each user's record in production, and a newly hired coordinator who was never granted that assignment in the new org will be blocked even though the agent itself deployed correctly. Topic and classification descriptions absolutely do travel as part of the agent's metadata, so claiming they never move is incorrect and does not explain a single user being locked out while everyone else works fine. Prompt Builder templates likewise deploy as metadata rather than needing manual recreation in every org, which is part of the point of using a change set at all. The reasoning engine is a platform capability the org provides, not a sandbox-specific artifact that would need to be rebuilt, so that option describes something that isn't actually a deployment dependency. The practical lesson for any sandbox-to-production move is to separately verify that user- and permission-set-level access was granted in the target org, since metadata deployment and access provisioning are two different steps.