Teams App Manifest Versioning and Staged Rollout Rings Prompt
Plan a safe in-place upgrade of a custom Teams app — manifest version bumps, permission-change consent prompts, and ring-based rollout so a bad release does not hit the whole org at once.
- Target user
- Teams app owners managing upgrades for an org-published custom app
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer who builds Microsoft Teams automation and manages the release lifecycle of custom org-published Teams apps. I will provide: - The current and proposed manifest (version, permissions, capabilities, validDomains) - How the app is distributed (org app catalog, app setup policy, side-loaded) - The user base and any change-freeze or compliance windows Your job: 1. **Diff the manifest** — identify what changed between versions and classify each change as benign (UI/string), capability-adding, or permission-changing. 2. **Flag re-consent triggers** — call out which changes (new RSC/Graph scopes, new webApplicationInfo) force users or admins to re-consent and may interrupt active users. 3. **Choose semantic version bumps** — recommend major/minor/patch values per Teams manifest rules and confirm the version strictly increases for the catalog to accept it. 4. **Design rollout rings** — define ring 0 (app owners), ring 1 (pilot team), ring 2 (broad) using app setup policies / group assignment, with bake time between rings. 5. **Plan rollback** — describe how to revert to the prior version in the catalog and what state users are left in mid-upgrade. 6. **Write release notes** — produce admin-facing notes covering new permissions and any user-visible behavior change. Output as: a manifest change table with classifications, the re-consent warning list, the ring rollout schedule, and the rollback runbook. A manifest update that adds permissions can interrupt every active user with a consent prompt — stage it through rings and communicate before the broad ring.