Building and customizing solutions using Microsoft 365 Copilot APIs and tools
The confirmation must resume the existing TASK_STATE_INPUT_REQUIRED task using its original task ID and contextId; however, Microsoft’s public Work IQ documentation does not currently specify the JSON field placement or proprietary interaction-response schema needed to submit that MCP confirmation.
What is established
For your response, preserve all three levels of correlation:
- Task:
result.task.id— the original pending task, not a new task. - Conversation:
result.task.contextId. - Interaction: values emitted by the selected Adaptive Card action, especially
sourceRequestId,actionId, andconfirmationOption.
A2A continuation guidance requires continuing the original pending task rather than starting an unrelated action ^1^. Work IQ separately documents that subsequent messages carry the previous contextId and use the same A2A version and JSON-RPC binding ^2^.
The public Work IQ task-management documentation exposes GetTask, CancelTask, and SubscribeToTask, but does not document an interaction-response method or a request schema for application/vnd.ms-workiq.interaction+json ^3^.
Consequently, an exact, supported confirmation JSON cannot be derived from the published contract.
Why an ordinary follow-up fails
The documented generic multi-turn request looks like this:
{
"jsonrpc": "2.0",
"id": "<new-request-guid>",
"method": "SendMessage",
"params": {
"message": {
"role": "ROLE_USER",
"messageId": "<new-message-guid>",
"contextId": "<original-context-id>",
"parts": [
{ "text": "Yes, proceed." }
]
}
}
}
This is only the documented format for a conversational follow-up. It does not identify the pending task and is not a documented MCP confirmation response. Sending it can create another turn without satisfying the pending interaction, which is consistent with:
The interaction response is missing, invalid, or does not match the pending task.
Although the original task ID must participate in resumption, the Work IQ documentation does not establish whether it belongs in params.id, the message, metadata, an interaction part, or another extension field. Adding it to an invented location would therefore be speculative.
Information that can be safely extracted
For the Confirm action, retain the Action.Submit.data.message object exactly as received. In your example, the likely correlation candidates are:
-
sourceRequestId -
actionId -
confirmationOption: 1 -
isCancelOption: false -
messageType: "InvokeAction"
For cancellation, the card supplies confirmationOption: 3 and isCancelOption: true.
These fields are emitted by the service, but their presence in the card does not establish the required A2A request wrapper. Do not:
- send only
"Yes"as text; - create a new conversation without the original
contextId; - poll with
GetTaskexpecting that to submit approval; - copy or call
pauseResumeStoreRegiondirectly—it is not a documented public Work IQ endpoint; - assume the JSON-RPC
idis the task ID; it identifies the JSON-RPC request.
Recommended next action
Because several attempted JSON shapes already return -32602, capture and escalate the following through Microsoft support or the Work IQ documentation feedback channel:
- The complete redacted
TASK_STATE_INPUT_REQUIREDresponse. - The exact follow-up request body and headers.
- Original task ID and
contextId. - JSON-RPC request IDs for both turns.
- UTC timestamps and the complete error response.
- Confirmation that
A2A-Version: 1.0was used on both requests.
Ask specifically for the Work IQ A2A v1.0 interaction-response schema for application/vnd.ms-workiq.interaction+json and the documented field that binds the response to the pending task ID. Until that contract is published or supplied by Microsoft, no particular response wrapper can be presented as a supported working payload.
References