State Updates

Show the eligible active New resources from the selected type and scope before asking which to postpone/dismiss. Exclude confirmed-deleted rows and any row with canPostponeDismiss=false. Ask for exact selected rows or all eligible shown rows when selection is unresolved; never choose the whole list implicitly. Reuse an explicit selection already given by the user, including an unambiguous prevalidation bucket. Reuse returned stable recommendation IDs; do not ask the user to type IDs or repeat the list just to select them. No cross-type update-all. Use the proposal/result layout. Keep full affected-resource IDs and stable recommendation IDs separately labeled in the expandable exact-target table before confirmation; reuse an unchanged identifier table already shown instead of repeating it. Never confuse the two identifiers.

• Postpone: after resource selection, ask which future return date to use unless the user already supplied one. Offer One week (7 calendar days), One month (one calendar month), Choose a date and time, and Cancel. Show each preset’s concrete return date/time and timezone, preserving local clock time; clamp an invalid month-end day to the month’s last day. Do not select a preset implicitly. For the custom choice, ask for the date/time and any missing timezone. This is date selection, not approval to update. Resolve the exact future ISO 8601 date/time and timezone before displaying the final batch proposal.
• Dismiss: reuse a supplied shared reason, otherwise ask once. Supported reasons: ExcessiveCostInvestmentRequired, ImplementationStepsAreUnclear, IncompatibleWithTheCurrentConfiguration, RiskIsAcceptable, TooComplexOrImpracticalToImplement, AnAlternativeSolutionIsAlreadyInPlace, Other.

Visibly show the entire selected batch, total count, exact scope/resources, intended status, chosen date/reason, Yearly potential savings and accumulated Cost as separate columns. For truncated lists disclose that the chosen target set contains only shown rows, including collapsed rows, never all matching resources.

Use one existing advisor_recommendation_update call with recommendation-ids containing all and only the selected stable record names. The MCP server’s destructive-operation Approve/Reject request is the batch confirmation. Do not add a separate Confirm these changes question or a per-record confirmation. A date answer, resource selection, or bare “continue” does not bypass that server approval. If the user asked only to prepare/preview, show the proposal and stop without calling update. Cancel/rejection means no updates and no retries.

All batch IDs must share one subscription or scalar Service Group, tenant, status and date/reason. Never silently split one approved batch into per-record calls or cross-scope batches. For a multi-subscription list without a common selected Service Group, resolve one eligible batch scope with the user before the date question. The existing scalar recommendation-id remains valid for a single record; never supply both ID options. Inspect the connected tool contract for batch support. If unavailable, report the limitation; do not substitute a shell loop, per-record calls or disable consent.

Use stable name as the update ID, never the affected-resource ARM ID/type GUID. Preserve the chosen scope/tenant/action/date/reason in the single call. Server approval is specific to that invocation, not reusable for another call after interruption or for later reactivation. Do not repeat successful updates or automatically retry failed, unverified or unattempted items; report outcomes first and obtain a new explicit request for further work. Postpone uses recommendation-status=Postponed, future ISO 8601 postponed-until-date-time with timezone; dismiss uses Dismissed and recommendation-dismiss-reason. Completion/reactivation use Completed/New only when requested. List status is source state, not the update’s recommendation-status. Use the result table once the batch finishes. Map each returned item by recommendationId to its selected resource; distinguish Succeeded, Failed, Unverified and NotAttempted. Preserve partial successes and do not claim the batch was atomic or a canceled write definitely failed. Use the existing update response’s outcome and returned status/date/reason; do not reclassify a successful update from a subsequent stale or empty list. Do not issue another confirmation to report results or silently retry a failed subset. State updates do not delete resources; an absent row proves neither deletion nor completion. State timestamps come from Advisor, not provisional local times.