ADR-0041 — In-App Feedback & ADO Work Item Integration

Status: Accepted
Date: 2026-06-24
AB#: 4424, 4425

---

Context

Members, ministers, and admins have no direct path to report bugs or request features inside the app. All feedback currently goes through informal channels (text, email) with no traceability. We need a structured, in-app mechanism that routes submissions into ADO for proper triage and visibility.

Decision

Add a smart feedback form to the About page. The form collects:

1. Submission type — Bug Report, Feature Request, General Feedback, Praise
2. Feature area — dropdown matching the app's actual product areas (see taxonomy below)
3. Type-specific fields — each type shows the right fields with inline guidance

On submit, the API calls ADO REST (az boards work-item create equivalent via ADO REST API) and creates a work item under the Community Feedback & Bug Reporting epic (AB#4424). The client receives the ADO work item ID as confirmation.

Feature area taxonomy

Dropdown value	Tag on ADO item
Sign In / Account	feedback:auth
My Profile	feedback:profile
Members	feedback:members
Family	feedback:family
Admin Portal	feedback:admin
Minister Portal	feedback:minister
Watch & Listen	feedback:media
Calendar / Events	feedback:calendar
Groups	feedback:groups
Messages / Announcements	feedback:messages
Marketplace	feedback:marketplace
Homeschool	feedback:homeschool
Other	feedback:other

Type-specific fields

Bug Report:

• Title (required)
• What happened (required)
• Steps to reproduce (required)
• Expected behavior (optional)
• Device / browser (optional, pre-filled from UA)

Feature Request:

• Title (required)
• What problem does this solve? (required)
• How would you like it to work? (optional)
• How often would you use this? (optional — Low/Sometimes/Often/Daily)

General Feedback / Praise:

• Title (required)
• Your feedback (required)

ADO work item mapping

Form field	ADO field
type=bug	Work item type: Bug
type=feature	Work item type: User Story
type=feedback/praise	Work item type: User Story
title	System.Title
submitter email (from auth)	Description footer
area tag	Tags
priority (low/medium/high from type)	Microsoft.VSTS.Common.Priority
parent	AB#4424

Security

• Endpoint requires authentication (requireAuth). Unauthenticated users cannot submit.
• Rate-limited: 5 submissions per user per hour (existing rate-limit middleware).
• Submission body is validated with Zod before any ADO call is made.
• The ADO PAT used is the existing AZURE_DEVOPS_EXT_PAT scoped to work item write only.
• User email is appended to the description (never stored separately).

Alternatives considered

1. GitHub Issues — rejected: GitHub Issues are public intake only; ADO is the source of truth.
2. Email form — rejected: no traceability, no ADO visibility.
3. Separate feedback service — rejected: ADO REST API is already authenticated and available.

Consequences

• ADO work item volume will increase as members submit feedback.
• The Platform team must monitor AB#4424 regularly and triage child items.
• The About page gains a substantive feature that encourages member engagement.