elastic / elastic/connectors

[Outlook] Manual E2E parity validation (M365 tenant)

Open
#4,359 0 comments 0 reactions 0 assignees View on GitHub
effort:medium outlook team:extract-and-transform
Dominant language
Python
Stars
133
Forks
205
Avg merge
16h 3m
Merged PRs (30d)
102

Description

## Parent

Part of #4264
Blocked by: `outlook_cloud` feature-complete

## Summary

Manual E2E parity validation on a real M365 tenant: side-by-side legacy `outlook` (cloud) vs `outlook_cloud`.

## Scope

- Requires M365 test tenant + Entra app with Graph app permissions (+ optional Application Access Policy for 2–5 mailboxes)
- Checklist: all document types (mail×4, calendar, contacts, DLs, tasks, attachments×3), DLS, incremental run
- Record gaps; block GA on critical parity failures

## Acceptance criteria

- [ ] Side-by-side run completed and results posted on this issue
- [ ] Critical gaps filed or fixed before release QA
- [ ] Non-critical gaps documented with follow-ups

## Out of scope

- Automated live CI against M365 (nice-to-have later)

Contributor guide

Open the contributing guide

Research direction

Start with parent issue #4264 and confirm that the outlook_cloud feature is feature-complete before arranging access to the M365 test tenant and Entra app. Run the side-by-side legacy outlook and outlook_cloud checklist across mail, calendar, contacts, distribution lists, tasks, attachments, and incremental runs. Done means results are posted here, critical gaps are filed or fixed before release QA, and non-critical gaps have documented follow-ups.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, python
Domain
backend, cloud, testing
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.