Adding action-groups to swagger schema #4021
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces a new operation‑level vendor extension for Swagger 2.0 connectors in the Power Platform schema: x-ms-action-groups. Its value is an array of group objects, each with a domain (e.g., email, file, event) and a scope (read | create | destructive). Actions may belong to multiple groups—e.g., Send email can be both email.create and email.destructive. The extension is defined in #/definitions/x-ms-action-group and exposed on each operation via operation.properties["x-ms-action-group"].
The goal is to enable a grouped “Add tool” experience in Copilot Studio without changing runtime semantics. Today, makers have to enable Outlook/SharePoint/Teams operations one‑by‑one; grouping lets the UX present curated sets (Mail → Read/Create/Destructive, Files → Read, etc.) and add many related actions in one step. This reduces setup time, minimizes omissions, and improves consistency across agents and environments—all while keeping individual actions visible in the tools list after they’re added.
This change is purely additive and non‑breaking. It does not modify execution, planning, or object models, and it has no effect on Power Apps or Power Automate—clients that don’t look for this extension will simply ignore it. Connectors that don’t annotate operations continue to work as they do today; the grouped UX will use the tags when present and fall back to search/individual add when absent. The schema also enforces a consistent mental model via a fixed scope enum and uniqueItems on the array to prevent duplicate tags.
In short, x-ms-action-group gives connector authors a lightweight, forward‑compatible way to describe addition‑time groupings of operations. It delivers immediate UX value (faster, safer tool enablement) with zero runtime risk, and it leaves room to evolve grouping semantics later if we decide to add shared inputs or policy binding in a future phase.