Add DTS dashboard links to Dynamic Workflow chat cards

[TsuyoshiUshio]

Please provide us with the following information:

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [x] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

1. Configure Dynamic Workflows with the Durable Task Scheduler backend.
2. Open an agent's built-in debug chat UI.
3. Ask the agent to start a workflow.
4. Observe that the workflow card shows the runtime status, progress, and a truncated instance ID, but provides no link to inspect that orchestration in the DTS dashboard.

Any log messages given by the failure

N/A. This is a usability enhancement, not a runtime failure.

Expected/desired behavior

When a Dynamic Workflow uses DTS, its workflow card in the built-in chat UI should provide an Open in DTS link. Prefer a direct orchestration-instance link if DTS exposes a documented stable deep-link contract. Otherwise, open the relevant task-hub dashboard and make the full instance ID easy to copy/search.

No link should be shown for the Azure Storage backend unless a separately supported dashboard target exists.

OS and Version?

All supported platforms. The motivating local scenario was Windows with the DTS Docker emulator and Azure Functions Core Tools v4.

Versions

Current main plus the per-agent Dynamic Workflows implementation in PR #151.

Mention any other details that might be useful

Current UI

The workflow card already retains the full workflow_id while rendering a truncated ID, progress, terminal state, and completion notification. This gives the UI everything needed to associate a link with the correct orchestration. A screenshot from the motivating discussion shows a completed workflow card between the initial assistant response and the final result summary; the missing affordance is a link from that card to DTS.

What can be derived from existing configuration

A generic WORKFLOW_DASHBOARD_URL_TEMPLATE should not normally be necessary:

• host.json identifies DTS through extensions.durableTask.storageProvider.type: azureManaged.
• storageProvider.connectionStringName identifies the app setting containing the DTS connection string.
• The connection string supplies the scheduler Endpoint.
• extensions.durableTask.hubName, after app-setting expansion, supplies the task hub name.
• For Azure DTS, the documented dashboard URL is:
  https://dashboard.durabletask.io/?endpoint=<SCHEDULER_ENDPOINT>&taskhub=<TASK_HUB_NAME>
• For the standard local emulator, the scheduler endpoint is normally port 8080 and the dashboard is normally http://localhost:8082.

Proposed behavior

1. Resolve dashboard metadata server-side; never expose the DTS connection string or authentication components to the browser.
2. For Azure DTS, derive the dashboard URL from the scheduler endpoint and resolved task hub name.
3. For the standard emulator mapping, derive the dashboard at port 8082.
4. Support an optional DTS_DASHBOARD_ENDPOINT override only for emulator/custom-network cases where the dashboard host port cannot be inferred from the scheduler endpoint. For example, the repository verifier maps container ports 8080 and 8082 independently to random host ports, so the gRPC connection string cannot reveal the mapped dashboard port.
5. Return only a validated safe dashboard URL/metadata to the Chat UI.
6. Render the workflow ID as a link or add an Open in DTS action on each workflow card. Use noopener noreferrer and open in a new tab.
7. Preserve the current UI unchanged when DTS is not configured or the URL cannot be derived safely.

Open design question

Microsoft documents the task-hub dashboard base URL and the dashboard's shareable-link feature, but we should confirm whether an orchestration-instance-specific route is a supported stable contract. If it is not, the first implementation should link to the task-hub dashboard and provide/copy the full workflow instance ID rather than depending on an undocumented route.

Authentication and security

• Azure dashboard access requires the user's Azure identity to have the Durable Task Data Contributor role.
• The application must not send connection strings, managed identity details, credentials, or arbitrary unvalidated URLs to the browser.
• Restrict derived/override URLs to http/https; consider allowing plain HTTP only for loopback emulator endpoints.

Acceptance criteria to discuss

• Azure DTS workflow cards show a task-hub dashboard link derived from existing configuration.
• Standard emulator workflow cards show the local dashboard link.
• Custom emulator port mappings work through a minimal optional override.
• Azure Storage workflow cards do not incorrectly show DTS links.
• No connection string or credential material reaches Chat UI responses or HTML.
• Tests cover Azure, standard emulator, custom-port override, malformed settings, and non-DTS fallback.

References:

• https://learn.microsoft.com/azure/durable-task/scheduler/durable-task-scheduler-dashboard
• PR feat: add multi-owner Dynamic Workflow ownership and isolation #151

---

Thanks! We'll be in touch soon.