Before you start
Enable Digital workers for an eligible organization, create a shared channel for the support workflow, and assign a responsible owner and responders. Decide which customer or internal environment the agent may act on. Connect the ticketing and operational systems through supported cloud tools. Provision credentials specifically for the agent, choose its models and budgets, and define what requires an escalation. Org Brain has its own owner activation and consent; it is useful grounding when enabled, rather than a substitute for the ticket or live system.Follow one support case
1
Receive and understand the request
A help-desk event starts a worker through a configured webhook. Configure the trigger mapping to supply the ticket identifier and trusted customer/account mapping when the run is created. The agent uses the configured account to fetch the ticket and read its history and affected service.Treat ticket text as context, not permission to select another customer account. If the trusted mapping, target, or requested outcome is missing or ambiguous, ask a human or prepare a clarification through the ticket system before taking action.
2
Investigate with knowledge and live evidence
The agent checks service status and relevant diagnostics through its permitted tools. It searches organization-visible Org Brain evidence for approved operating knowledge when available, then verifies the relevant details against the live system.For a stopped service, this might mean checking the current health, recent change history, dependencies, and the approved recovery method. Separate observed facts from the agent’s hypothesis.
3
Bring in the right people
If a detail is missing, the agent creates a human question. If a system-changing request is needed, it presents the exact proposed connector request for approval. Your team responds in Work → My approvals, the desktop inbox, or a configured Slack route.The run keeps its state while it waits. Connector-write approval requires an independent authorized manager; the person who started the run cannot approve that write. After all open human tasks resolve, Studio queues the run to continue.
4
Carry out the approved work
The worker executes the approved connector request with its own configured credential against the intended customer or internal service. Capture the service’s response before deciding what to do next.Define the action narrowly: for example, restart one named service through its management API. An agent does not gain an operator’s SSH session, local network route, or remote desktop simply by belonging to the same channel. If the required action is outside its tools, hand the case to an operator with the evidence collected so far.
5
Verify recovery
Read the service state again and perform the workflow’s success check. A successful API response is evidence that a request was accepted, not proof that the customer’s problem is resolved.Use a durable wait for a later check when recovery takes time. Bound retries and further actions. If the check fails, preserve the evidence and escalate instead of closing the ticket as resolved.
6
Respond and close the loop
Prepare an accurate customer update: what was found, what changed, what was verified, and any remaining action. Send the approved reply through the ticketing connector or a configured mail-service endpoint. Keep internal notes distinct from the public customer reply.Closing or changing the ticket is another external write and follows the connector’s approval path. If the case needs further work, record the findings and next owner in the support system. A worker run marked Completed does not itself close an external ticket.
7
Learn from the outcome
Review the result, human decisions, time, and cost in Outcomes. Save durable lessons with the intended audience and inspect proposed workflow improvements before applying them.Worker reports remain channel-scoped evidence for authorized people. They do not automatically become organization-wide knowledge available to worker search. Publish only the facts that should be shared more broadly.
Decide whether the case is ready to close
Use the observed result to choose the next step. A successful action, a sent reply, and a closed ticket are separate outcomes; the workflow needs evidence for each. Bound any retry path you add. Missing approval or a failed customer update must not become an unsupported claim that the case is resolved.Connect the systems that complete the loop
Use Connectors and MCP to define the external operations. Confirm that each operation is supported by the cloud worker runtime; availability in desktop Copilot alone is insufficient.
Example: connect the customer response to the ticket
The HubSpot preset includes ticket and conversation reads, a customer-visible thread reply, an internal note, and a ticket update. Configure the agent to read the conversation and recipient, send an approved reply, and select the correct closed pipeline stage after verification. Discover the pipeline stage from the connected account rather than inventing an identifier. Zendesk similarly provides ticket reads and updates with comment and status fields. Keep a public customer reply distinct from an internal note. With either system, the preset supplies API definitions; you still configure the worker’s connection, endpoint grants, approval steps, and workflow, then test the complete case in your environment.Turn the loop into an agent workflow
In Administration → Channels, open your channel and create an agent. A useful starting description is:Handle stopped-service support requests for the configured customer environment. Read the ticket and live service state, gather evidence, ask for missing information, request approval for the exact recovery action, verify service health, and prepare an accurate customer update. Close only after the success criteria pass; otherwise escalate with evidence and the next required decision.Review the generated workflow before activation. Make the expected input, permitted tools, completion evidence, and failure path clear at every stage. A default support template can help with triage and drafting; it does not come with authority or integrations to send replies and change infrastructure. Separate stages for investigation, approved action, verification, and response make mistakes easier to detect. Use Verify, then advance where a stage needs acceptance criteria. Place a configured human review before the next stage’s consequential work; connector writes retain their exact-request approval requirement. See AI support agents for the UI steps, connections, triggers, budgets, and run controls.
Keep customer boundaries explicit
The ticket’s customer name is context, not authorization. Scope the credential, tenant, tool, target, and channel deliberately. Use separate organizations when customers need an organization-level trust boundary. Workers search organization-visible Org Brain evidence only. A channel does not turn organization-wide knowledge into a private customer partition. Keep restricted customer details in the appropriately scoped support or operational system instead of publishing them organization-wide to make them searchable. When handing work to another agent or person, include the authorized target, observed evidence, action already taken, and remaining decision. Transfer only the information needed for that work.Test the whole case before scaling
Use a controlled ticket and environment. Activate the saved agent for manual testing before enabling unattended triggers, then exercise these outcomes:
Review your help desk and target-system records alongside the run’s timeline and artifacts. Expand to another support category only when the existing loop has clear ownership, reliable evidence, and acceptable outcomes.