Connected actions let an agent work with information and operations outside its knowledge base. They are useful when a support request depends on a live record or requires a change in another system. Before configuring an action, describe the customer outcome and identify the system responsible for it. An agent cannot safely complete a business operation merely because a tool or integration name is visible in the interface.

​
Separate answers, lookups, and updates

A policy answer explains approved information. A lookup reads a live record. An update changes that record. These are different responsibilities and should be configured and tested separately. For example, “Can delivery instructions be changed?” may be answered from policy. “Has my order shipped?” needs a lookup. “Change my delivery instruction” needs an authorized update with eligibility checks.

​
Define what the tool is allowed to do

Identify the API or service, the operation, and the minimum data required. Give the relevant specialist access only to the tools it needs. Procedures should explain when an operation is appropriate and what should happen if it cannot be completed. MCP is one way to expose tools. Other connections may use configured APIs or data connectors. Your technical owner should confirm authentication, customer identity, permissions, and provider requirements for the chosen approach.

​
Build the action around the business rule

Consider a fictional customer asking to change a delivery instruction. A safe configured workflow would establish identity, retrieve the order, check whether edits are permitted, collect the new instruction, obtain any required confirmation, and then invoke the update. The response should reflect the system’s result. If the update fails, the agent should not claim success. If the order is no longer eligible, it should explain the permitted next step or involve a person.

​
Test more than the successful request

Test an unauthorized customer, a missing record, an ineligible request, an unavailable service, and a response that lacks expected information. Confirm both the system behavior and the message the customer receives. Start with read-only access when it is enough to prove the workflow. Enable operations that change records only after the technical and policy owners have reviewed the complete flow.

​
Plan for ongoing ownership

Business APIs, credentials, and policies change. Assign an owner to maintain the connection and revisit its tests. Keep secrets out of knowledge articles, demo requests, and customer messages. Use the integration planning guide to decide what is ready to connect and where you will need engineering support.