Tematy od Firm 2026

An AI tool that ingests an original document and its translated version, automatically evaluates translation quality, and returns an overall rating plus targeted feedback. The solution will combine Natural Language Processing, LLM-based evaluation, and practical software engineering into a usable “translation QA” pipeline.

Main features:
1. Document ingestion & alignment (source vs. translation)
• Support common formats (e.g., TXT/DOCX/PDF) and extract text reliably (handle headings, lists, tables).
o Segment text into units (sentences/paragraphs) and align source-to-target segments even when lengths differ.
o Produce an “alignment view” so reviewers can trace every score back to specific parts of the documents.
2. Quality scoring with AI + transparent criteria
• Generate a multi-dimensional score, for example: Accuracy/Faithfulness, Fluency/Grammar, Terminology consistency, Style/Tone, and Formatting preservation.
o Use an LLM (with specified metrics) to compute per-segment scores and an aggregated document score.
o Require the evaluator to output short evidence-based notes (e.g., “meaning changed”, “missing sentence”, “wrong number/date”), not just a number.
3. Error detection, reporting, and improvement hints
• Detect common issues: omissions/additions, mistranslations, named entities and numbers inconsistencies, glossary violations, and untranslated fragments.
o Provide a structured report: overall grade, per-section breakdown, and a ranked list of highest-impact problems.
o Optional: allow “re-evaluate after fix” or propose corrected translations for flagged segments (clearly separated from the evaluation).

Support offered by company:

• Consultations by an employee of the company.
• Supervision over the project by an employee of the company.
• Participation of a company employee in project meetings.

Accepted group size: 3 people, 4 people

Acceptable project language: English, Polish

Available groups: 1/1

Additional remarks:
(none)

Problem statement
A chatbot connected to Confluence (thousands of pages) and other sources (Stack overflow) produces low-quality, “nonsense” answers.
Confluence content is largely untagged, inconsistent, and contains duplicates/outdated pages.
Chatbot does not detect profiles and does not adjust the level of complexity of the answers to the profile (data engineers, business users, architects)

Objectives
Propose an end-to-end architecture for a knowledge chatbot that is grounded in sources and avoids hallucinations. Technology that works the best with non cloud Confluence and thousands of articles.
Define a practical content preparation strategy that works - include main recommendation and minimal actions that could improve the quality of provided answers
Deliver actionable recommendations: “what to fix first” and expected impact.
Provide an evaluation framework and test plan that can be executed on synthetic/redacted data.

Assumptions and constraints
No access to production Confluence pages for students.
Available technologies are related to the Open AI and Copilot

Support offered by company:

• Consultations by an employee of the company.
• Supervision over the project by an employee of the company.
• Participation of a company employee in project meetings.

Accepted group size: 3 people, 4 people

Acceptable project language: English, Polish

Available groups: 1/1

Additional remarks:
(none)

Problem to solve:
When we organize an event for all students from Wroclaw (different universities) – we don’t have a dedicated website/application for that. We would like to have one place where we can add all the information.

Main information:
- Overview of the event: purpose, description, mission
- Agenda
- Venue – information about location (main event) and watch parties
- Q&A about the event

Speakers:
- Speakers profiles – with photos, short description
- Possibility to contact a Speaker (e.g., e-mail, link to LinkedIn profile)

Materials (treasures for people who downloaded the app):
- Materials from previous events
- Job offers from Volvo Group (from tech)

Contact with speakers and attendees:
- Feedback after the session (simple without many questions) with a question on what they would like to hear about in the next event
- Information about mentorship opportunities

Sign-up possibility:
- Students can sign up for the event on this website – a short form with basic required information (name, surname, email address).
- There should also be an admin panel to check how many people are signed up and who exactly.
- Possibility to send an email/notification to all registered people.

Technology stack:
- Backend: C#, .NET, Azure
- Frontend: Typescript, React

Planowane formy współpracy:

• Konsultacje merytoryczne ze strony pracownika firmy.
• Nadzór merytoryczny pracownika firmy nad całością lub fragmentami projektu.
• Udział pracownika firmy w spotkaniach projektowych.

Akceptowana wielkość grupy: 3 osoby, 4 osoby

Dopuszczalny język projektu: angielski, polski

Dostępna liczba grup: 1/1

Dodatkowe uwagi:
(brak)

Project goal:
- Build and pilot an application (online or offline) that automatically classifies documents/data into: Open, Internal, Confidential, Strictly Confidential
- Additionally, the application must flag whether the document/data contains personal information by setting: “contains personal information”

Functional scope (MVP):
- Automatic sensitivity classification based on document/data content
- Personal Information detection and flagging
- Supported input formats (to be confirmed; minimum proposal):
- Office documents: DOCX, PPTX, XLSX, PDF, TXT
- Data: JSON
- Operating modes:
- Online (service/assistant) or offline (local tool)
- Delivered either as an Office plugin or a dedicated Assistant (final choice to be confirmed during Discovery).
- Expected Output:
- Classification level + Personal Information flag
- Explainability (e.g., which rules/sections contributed to the decision)

Proposed Tasks:
1. Exploration of the solution design and possible technologies
- Decide on classification approach:
- Rule-based (keyword dictionaries/regex + Personal Information detectors)
- ML/LLM (contextual classification)
- Hybrid (deterministic Personal Information flagging and hybrid sensitivity scoring)
- Defining architecture, security, audit/logging, integration points.
2. MVP implementation
- Pipeline design and implementation (proposal: text extraction -> Personal Information detection -> sensitivity classification -> result + metadata)
- Basic UI/UX
3. Testing and calibration
- Prepare reference set of sanitized documents and data to measure quality.
- Personal Information detection
- Classification vs expected labels
4. Possible applications
- Office Plugin
- Online Application
- Offline Application

Deliverables:
- Requirements clarification document (scope, assumptions, constraints)
- Architecture/design document (including data flow)
- MVP tool (with the agreed input formats and output)
- Documentation (user guide + operational notes if online)
- Pilot report (quality metrics, findings, recommendations)

Support offered by company:

• Consultations by an employee of the company.
• Supervision over the project by an employee of the company.
• Participation of a company employee in project meetings.

Accepted group size: 3 people, 4 people

Acceptable project language: English, Polish

Available groups: 1/1

Additional remarks:
(none)

The system automatically monitors all Microsoft 365 Message Center announcements that relate to the Power Platform and its components (Power Apps, Power Automate, Dataverse, Copilot for Power Platform, etc.).
Whenever a new applicable announcement appears, it goes through an automated analysis process. The results of this analysis are stored in an internal “repository” (e.g., database, SharePoint list, or similar tracking system).
Goal:
The goal of this initiative is to ensure proactive, consistent, and efficient handling of all Microsoft Message Center (MC) announcements related to the Power Platform. By automating the analysis and classification of these announcements, the organization can reduce manual workload, detect impactful changes earlier, ensure timely communication, and maintain an up-to-date knowledge repository. This contributes to improved platform stability, compliance, and operational readiness.
Scope of work:
Included in Scope:
- Automatic retrieval of all MC announcements related to Power Platform and its components.
- Automated classification based on category, priority, and impact.
- Automated workflows for planned maintenance, routine updates, and unclear messages.
- Creation and maintenance of a structured repository.
- Automated stakeholder communication when needed.
- Monitoring services such as Power Apps, Power Automate, Microsoft Copilot (Power Platform), Microsoft Dataverse, and overall, Power Platform.
- Use of Power Platform and AI/GenAI capabilities to automate classification and summarization.
Out of Scope:
- Manual investigation of complex or ambiguous MC messages (triggered, not executed automatically).
- Handling announcements unrelated to Power Platform.
- Full lifecycle management of business-critical changes.
- Automatic remediation of issues caused by updates.
- Monitoring of non-Microsoft services.

Detailed Process Description:
1. Automated Collection & Pre-Processing:
- Retrieval of all relevant MC announcements and extraction of metadata.

2. Automated Classification:
- Category: maintenance, new feature, breaking change, etc.
- Priority: urgency and impact-based.
- Impact level across solutions and environments.

3. Automated Actions:
A. Planned Maintenance:
- Automatic notifications to solution owners and Tenant Admins.
- Repository entry updated and closed.

B. Regular Service Updates:
- Automatic closure with analysis saved.

C. Unclear or High-Impact Announcements:
- Automated GenAI summary created.
- Administrators alerted for review.
- Item remains open until resolved.

4. Repository Storage:
- All items stored with full history, analysis, actions taken, and status.
Technology and tools to be utilized:
The technology stack involves Power Platform components, including AI and generative AI capabilities:
• Power Automate (Or Agent flows)
• AI Builder
• MS Copilot Studio (Optional)
If needed, the process can integrate signals from other Microsoft services.

Support offered by company:

• Consultations by an employee of the company.
• Supervision over the project by an employee of the company.
• Participation of a company employee in project meetings.

Accepted group size: 3 people, 4 people

Acceptable project language: English, Polish

Available groups: 1/1

Additional remarks:
(none)

Initiative Definition & Evaluation Application (IDEA)

1. Project Overview
The Initiative Definition & Evaluation Application (IDEA) application is one of the first pillars of the Leads Process structure. It is a centralized intake and qualification solution designed to standardize how requests ("leads") are submitted, verified, and tracked. IDEA introduces a single, structured request form that captures all essential information required to open and assess a project, reducing ambiguity, manual follow-ups, and unnecessary meetings.
The application acts as a front gate to the initiative lifecycle, ensuring that only well-defined, compliant, and value-driven initiatives enter discovery and subsequent delivery phases.

2. Problem Statement & Background
Currently, requests are often initiated through various channels (e-mails, meetings, chats, etc.), leading to:
* Incomplete or inconsistent requirements,
* Repeated clarification meetings,
* Delays in discovery and implementation phases,
* Limited transparency of needs and workload,
* Difficulty measuring lead flow and performance.
IDEA addresses these challenges by enforcing structured data collection, early verification, and real-time visibility into the leads pipeline.

3. Project Objectives
Primary Objectives
* Create a single-entry point for all lead requests,
* Ensure complete and high-quality requirements at submission period,
* Enable early verification (e.g. DPO verification or governance checks),
* Provide end-to-end visibility of incoming leads.
Secondary Objectives
* Reduce time-to-discovery,
* Minimize coordination and meetings,
* Enable data-driven prioritization and planning,
* Support cost-efficient resource utilization.

4. Scope
In Scope
* Design and implementation of application IDEA,
* Definition of mandatory and optional input fields,
* Submission workflow and routing to responsible verifiers,
* Lead status tracking,
* Data model for reporting,
* PowerBI Leads Dashboard for KPIs and insights.

5. Structure & Required Fields
The IDEA application is designed to capture all minimum information required to initiate an initiative.
Core Identification
* Initiative title
* Organization
Business Context
* Initiative background
* Business challenge
Scope & Requirements
* High-level scope
* Basic requirements (functional / non-functional)
* Assumptions, constraints, risks
Planning Inputs
* High-level time-plan / target dates
* Active WBS for Discovery Phase
Governance & Contacts
* SPOC
* Business Owner
* Involved Stakeholders / Key Users / SMEs

6. Process Flow Draft
Step 1  -Open IDEA
Requestor accesses the application.
Step 2 - Complete Request
Requestor fills in all required fields. Smart validation ensures completeness and clarity before submission.
Step 3 - Submit Request
Upon clicking Send , the lead is registered in the system/list.
Step 4 -Verification
The request is automatically routed to the responsible verifier for:
* Validation of compliance with applicable regulations,
* Assignment of the responsible DPO or dedicated team,
* Assessment of data protection relevance and impact,
* Formal decision: approval or rejection of the request.
* Additional space for more clarification needed, etc.
Step 5 - Lead Status Assignment
Post-verification, the lead receives a status such as (to be verified):
* Submitted
* Under Review
* Assigned
* Approved - Discovery Phase
* Ongoing - Implementation Phase
* Rejected / Needs Clarification
Step 6 - Visibility & Reporting
All leads are stored in a structured dataset feeding the Lead Dashboard.

7. Lead Dashboard
A dedicated Lead Dashboard provides transparency and insights. Could be provided in PowerBI solution or anything similar. It is a transparent view of the IDEA as a base.
KPIs
* Total number of submitted leads
* Lead throughput (e.g. quarterly)
* Average lead time (e.g. Submission --> Approval --> Discovery)
* Average time to request completeness
* Leads by Organization
* Leads by responsible DPO / team
* Any other: to be verified
Value of the Dashboard
* Supports prioritization decisions
* Identifies bottlenecks
* Enables capacity planning
* Provides management-level visibility

8. Expected Outcomes
* Standardized, high-quality initiatives requests repo,
* Reduced lead intake cycle-time,
* More effective clarification and requirements gathering sessions,
* Improved transparency of the needs,
* Data-driven decision-making.

9. Given Values
For Business
* Less meetings = more clarity,
* Faster initiation of valuable initiatives,
* Predictable and transparent request handling,
* Better prioritization and cost awareness.
For Team
* Clearer requirements backlog,
* Reduced re-work and interruptions,
* Improved planning accuracy,
* Ability to focus effort where it matters most.

Support offered by company:

• Consultations by an employee of the company.
• Supervision over the project by an employee of the company.
• Participation of a company employee in project meetings.

Accepted group size: 3 people, 4 people

Acceptable project language: English, Polish

Available groups: 1/1

Additional remarks:
(none)

Spec-driven development (SDD), czyli rozwój oprogramowania sterowany specyfikacją, to nowoczesna metodologia pracy, która zyskała na znaczeniu w 2025 roku wraz z popularyzacją agentów AI (takich jak GitHub Copilot).

W tym podejściu to specyfikacja, a nie kod, staje się głównym artefaktem i „źródłem prawdy” projektu. Zamiast pisać kod ręcznie lub prosić AI o generowanie fragmentów na podstawie luźnych instrukcji (tzw. vibe coding), programista tworzy szczegółową, ustrukturyzowaną dokumentację, którą agenci AI przekształcają w działające oprogramowanie.

Jako student posiadający darmowy dostęp do GitHub Copilot w 2026 roku, możesz korzystać z frameworka Tessl, aby tworzyć aplikacje w oparciu o specyfikacje.

Oto jak te technologie współpracują ze sobą w praktyce:

1. Claude Sonnet 4.5 w GitHub Copilot

W 2026 roku studenci otrzymują darmowy plan Copilot Pro, który obejmuje dostęp do zaawansowanych modeli innych firm, w tym Claude Sonnet 4.5.

Możesz wybrać ten model w oknie czatu (model picker) w swoim edytorze kodu (np. VS Code).

Sonnet 4.5 jest uznawany za jeden z najlepszych modeli do zadań agentowych i programowania opartego na logice.

2. Wykorzystanie frameworka Tessl

Tessl to platforma do tworzenia oprogramowania typu „AI-native”, która promuje podejście Spec-Driven Development (SDD).

Tworzenie przez specyfikację: Zamiast pisać kod linijka po linijce, tworzysz pliki specyfikacji (specs) w języku naturalnym lub ustrukturyzowanym formacie.

Rola Claude Sonnet 4.5: Framework Tessl wykorzystuje „agenty” do interpretacji tych specyfikacji. Model Sonnet 4.5 (dostępny przez Copilota) dobrze radzi sobie z tym zadaniem, zamieniając Twoje wymagania na gotowy, przetestowany kod.

Zadanie polega na :

- skonfigurowaniu środowiska opartego o wyżej wymienione technologie

- przygotowaniu specyfikacji i wygenerowaniu prostej aplikacji typu workflow bazującej na aktualnej wersji Angular w oparciu o dostarczone wymagania.

Planowane formy współpracy:

• Konsultacje merytoryczne ze strony pracownika firmy.
• Nadzór merytoryczny pracownika firmy nad całością lub fragmentami projektu.
• Udział pracownika firmy w spotkaniach projektowych.

Akceptowana wielkość grupy: 3 osoby, 4 osoby

Dopuszczalny język projektu: angielski, polski

Dostępna liczba grup: 1/1

Dodatkowe uwagi:
(brak)

1. Opis ogólny
Meeting Action Orchestrator to aplikacja osadzona w ekosystemie Microsoft 365, której celem jest automatyzacja follow upów po spotkaniach, ale w sposób deterministyczny — bez użycia jakichkolwiek modeli AI lub funkcji generatywnych.
System ma pobierać szczegóły wybranego spotkania z kalendarza, umożliwić użytkownikowi wygodne stworzenie notatek (Minutes) według struktury:
• Decisions (podjęte decyzje)
• Actions / Tasks (zadania)
• Risks / Issues (ryzyka/problemy)
…a następnie utworzyć konkretne zadania w Plannerze lub To Do, zapisać Minutes w SharePoint oraz (opcjonalnie) przesłać podsumowanie na wskazany kanał Teams.
To jest projekt czysto inżynierski: integracje, formularze, przepływy, reguły, architektura, uprawnienia, API, brak czarnej skrzynki.

2. Cele projektu
Cele techniczne
• Poznanie Microsoft Graph API (głównie: Events, Users, Planner, ToDo, SharePoint, Teams).
• Zbudowanie aplikacji M365 z pełną ścieżką: Auth → API → logika → zapis → powiadomienia.
• Praktyka w projektowaniu integracji i obsługi uprawnień OAuth 2.0 / Microsoft Entra ID.
• Praktyka w tworzeniu przewidywalnych automatyzacji (bez AI).
Cele biznesowe
• Zmniejszenie czasochłonności follow upów po spotkaniach.
• Ustandaryzowanie notatek i zadań projektowych.
• Poprawa komunikacji między członkami zespołu.

3. Funkcjonalności

3.1 Core (obowiązkowe)
1. Wybór spotkania z kalendarza
• Użytkownik loguje się (OAuth + Graph delegated permissions).
• System pobiera listę spotkań przyszłych i minionych (np. z 7 dni).
• Użytkownik wybiera jedno spotkanie.
• Pobierani są:
o uczestnicy,
o organizator,
o data/czas,
o agenda (jeśli istnieje),
o link do spotkania,
o lokalizacja / online.
2. Formularz „Minutes”
Formularz zawiera 3 sekcje:
• Decisions – lista stringów.
• Actions – każde zadanie zawiera:
o opis,
o osoba przypisana (z listy uczestników),
o termin realizacji,
o priorytet (Low/Normal/High).
• Risks – tekst + opcjonalnie właściciel ryzyka.
Formularz może być:
• panel webowy (React/Angular/Vue),
• lub panel w Teams (tab app).
3. Zapis Minutes do SharePoint
System zapisuje Minutes jako:
• JSON w bibliotece „Meeting Minutes”,
•
o generuje PDF/HTML (opcjonalnie)
•
o nadaje nazwę:
Minutes_<yyyy-MM-dd>_<MeetingSubject>.json/pdf.
4. Automatyczne tworzenie zadań
Jedno kliknięcie:
„Create tasks in Planner/To Do”.
System tworzy zadania na podstawie sekcji Actions:
• opis = opis akcji,
• przypisana osoba = wyciągnięta z uczestników,
• dueDate = z formularza,
• ewentualnie bucket = „Meeting Actions”.
System zwraca linki do zadań.

3.2 Advanced (opcjonalne)
1. Szablony notatek
• Student może dodać listę predefiniowanych układów Minutes, np.:
o Scrum Retro,
o Risk Review,
o Arch Meeting,
o Steering Committee Notes.
• Szablony są przechowywane w SharePoint (lista „Minutes Templates”).
2. Podsumowanie w Teams
Po zapisaniu Minutes:
• wysyłana jest Adaptive Card na wybrany kanał Teams,
• karta zawiera:
o nazwę spotkania,
o organizatora,
o decyzje,
o liczbę zadań,
o przyciski:
 „Open Minutes”
 „Open Planner Tasks”
Dodatkowo można wrzucić załącznik (PDF).

3.3 Ultra (opcjonalne dla chętnych)
1. Reguły priorytetów
Prosty engine if/else, np.:
• jeśli akcja zawiera tag [RFC] → due date = +3 dni,
• jeśli zawiera [BLOCKER] → priorytet = High,
• jeśli zawiera [RISK] → przenieś do sekcji Risk.
2. Słowniki / tagi (Term Store)
Student dodaje:
• własne taxonomie,
• np. ProjectType, MeetingType, DecisionType.
W Minutes można wymusić, aby decyzja miała przynajmniej 1 tag.
3. „Nudge” przed kolejnym spotkaniem
System wykrywa, że:
• istnieją otwarte zadania z poprzedniego spotkania,
• oraz zbliża się następne spotkanie z identycznym tytułem lub cykliczne.
Wysyła wtedy przypomnienie:
• Adaptive Card w Teams,
• lub e-mail z listą niedokończonych zadań.

4. Architektura systemu
4.1 Komponenty
• Frontend (SPA lub Teams Tab App)
UI dla wyboru spotkań, wypełniania Minutes i uruchamiania tasków.
• Backend API
obsługuje:
o OAuth,
o Połączenia z Graph,
o Tworzenie plików,
o Tworzenie Planner tasks,
o Logikę reguł,
o Zapis do SharePoint.
• SharePoint
o Biblioteka Meeting Minutes (PDF/JSON),
o Lista Minutes Templates (opcjonalnie),
o Term Store (opcjonalnie).
• Planner / To Do
Zapisy zadań.
• Teams (opcjonalnie)
Adaptive Cards dla powiadomień.

4.2 Diagram logiczny (opis tekstowy)
1. Użytkownik loguje się → API pobiera token.
2. Front pobiera listę spotkań → GET /me/events.
3. Użytkownik wybiera spotkanie → API pobiera szczegóły.
4. Wypełnia Minutes → Front wysyła JSON do backendu.
5. Backend:
o zapisuje Minutes → SharePoint,
o generuje zadania → Planner/ToDo,
o generuje podsumowanie → Teams (opcjonalnie),
o zwraca linki i status.

5. Wykorzystane API Graph
Kalendarz
• GET /me/events
• GET /me/events/{id}
Planner
• POST /planner/tasks
• POST /planner/plans/{id}/tasks
To Do
• POST /me/todo/lists/{id}/tasks
SharePoint
• POST /sites/{id}/drive/items/root:/Minutes/...:/content
• GET /sites/{id}/lists/{id} (szablony)
Teams
• POST /teams/{id}/channels/{id}/messages
• adaptacyjne karty: @microsoft/teamsfx, adaptivecards.io

6. Wymagania niefunkcjonalne
• Autoryzacja: OAuth 2.0 + PKCE, delegated permissions.
• Przechowywanie sekretów: Key Vault lub plik user secret (dev).
• Obsługa błędów: retry, timeouts, logowanie.
• Telemetria: App Insights (darmowy tier ok).
• Dostępność: min. przeglądarka + Teams.
• Testy:
o jednostkowe (logika Minutes, reguły),
o integracyjne (Graph mock lub integration tokens).

7. Kryteria ukończenia
Minimalne (Core)
• można wybrać spotkanie,
• można utworzyć Minutes,
• Minutes zapisuje się na SharePoint,
• tworzone są zadania w Planner/ToDo,
• aplikacja działa z autentycznym tokenem użytkownika.
Dobry projekt (Core + Advanced)
• istnieją szablony Minutes,
• jest podsumowanie wysyłane na Teams,
• UI jest przyjazne i logiczne.
Świetny projekt (Core + Advanced + Ultra)
• działają reguły priorytetów,
• istnieją tagi i walidacje,
• działa system Nudge przed kolejnym spotkaniem,
• projekt jest solidnie przetestowany i udokumentowany.

8. Backlog przykładowy (do wrzucenia jako GitHub Issues)
Sprint 1
• Rejestracja aplikacji w Entra ID
• Implementacja OAuth + pobranie access_token
• Wylistowanie spotkań użytkownika
Sprint 2
• Pobieranie szczegółów spotkania
• UI do edycji Minutes (Decisions/Actions/Risks)
• Zapis Minutes do SharePoint
Sprint 3
• Tworzenie zadań Planner/ToDo
• Pokazywanie linków w UI
Sprint 4 (opcjonalnie)
• Szablony Minutes
• Adaptive Card Summary
Sprint 5 (ultra)
• Reguły priorytetów
• Nudge dla zadań
• Taxonomie/Term Store

9. Co student musi oddać
• Repo z kodem
• README (uruchomienie, konfiguracja, scopes)
• Diagram architektury
• Zrzuty ekranu lub film (5 min)
• Plik security.md (scopes, przepływy danych)
• Przykładowe Minutes + wygenerowane zadania

10. Podsumowanie
Ten projekt łączy:
✔ praktyczne użycie Graph,
✔ czyste automatyzacje M365,
✔ architekturę i struktury danych,
✔ UI + integracje + logikę biznesową,
❌ zero AI, zero kosztów.

Support offered by company:

• Consultations by an employee of the company.
• Supervision over the project by an employee of the company.
• Participation of a company employee in project meetings.

Accepted group size: 3 people, 4 people

Acceptable project language: English, Polish

Available groups: 1/1

Additional remarks:
(none)

Goal:
Deliver a reliable, automated capability that continuously monitors Microsoft Power Platform Release Plans, classifies every update by impact and priority, and triggers the right operational actions, so that tenant admins and product owners can respond faster, reduce risk, and capture opportunities from new/changed features.

Key outcomes
• Early visibility of material changes (e.g., AI features, breaking changes, deprecations) with targeted notifications to the Power Platform Tenant Administrator and relevant stakeholders.
• Single source of truth (“repository”) capturing each plan item, version diffs, impact/priority scores, and audit trail.
• Actionable workflows to update items, summarize changes, and (optionally) create tasks for review or mitigation.

Scope of the work:

Included in the scope:
• Coverage of Power Platform sections in Microsoft Release Plans: Power Apps, Power Pages, Power Automate, Microsoft Copilot Studio, AI Builder, Microsoft Dataverse, Governance & Administration, and Pro Development.
• Automated ingestion of plan items and updates, including change detection (content edits, status changes, date shifts).
• Automated analysis & classification (category, change type, impact, priority, AI relevance, “breaking change” flag).
• Repository persistence of the analyzed results, including version history and change logs.
• Automated actions, such as:
o Update repository items with a summary of changes whenever Microsoft edits a plan item.
o Notify the Power Platform Tenant Administrator on major/specific changes (AI features, significant product functionality updates).
• Dashboards & reports (trend of changes per product area, lead time to review, open actions by priority).
• Optional: task creation in Azure DevOps/Planner and Teams adaptive card notifications.

Out of scope:
• Automated remediation in production environments.
• Non-Power Platform product families beyond what you listed.
• Licensing automation or budget approval workflows.
• Parsing of non public or paywalled sources.

Detailed Process Description:
1. Ingestion & Change Detection
o Scheduled retrieval of Release Plan content (Power Platform sections).
o Diff engine to detect additions/edits/status changes.
2. Analysis & Classification
o Natural language summarization and classification (e.g., New/GA/Preview/Deprecation/Security/Breaking).
o Impact & priority scoring; AI feature tagging; risk flags.
3. Repository (Dataverse recommended)
o Tables for Feature Items, Change Logs, Classifications, Notifications, Subscriptions.
4. Action Orchestration (Power Automate)
o Update repository items + generate change summaries.
o Notify Tenant Admin and subscribed owners for Major/Special updates.
o Optional: Create review tasks in ADO/Planner; send Teams Adaptive Cards.
5. Experience Layer
o Power Apps admin console for search/review/override.
o Power BI dashboards for trend & SLA tracking.
o Copilot Studio assistant to “ask” about upcoming changes.
6. Governance & Security
o Role based access to tables and flows, audit history, and data retention.

Technology and tools to be utilized:
The technology stack involves Power Platform components, including AI and generative AI capabilities:
• Power Automate
• Dataverse
• AI Builder
• Power Apps
• Power BI
• MS Copilot Studio
If needed, the process can integrate signals from other Microsoft services (e.g., SharePoint, Azure DevOps or Teams).

Support offered by company:

• Consultations by an employee of the company.
• Supervision over the project by an employee of the company.
• Participation of a company employee in project meetings.

Accepted group size: 3 people, 4 people

Acceptable project language: English, Polish

Available groups: 1/1

Additional remarks:
(none)