Phase 2 Scope vs. Identified Gaps -- Coverage Analysis
Analysis Date: March 26, 2026 Source Documents:
- Phase 2 SOW:
PHASE2-SCOPE-v6.md(Sataware, 03/26/2026) - Delivery Mapping:
SDD-DELIVERY-MAPPING.md(March 24, 2026) - Gap Analysis: memory
cms_faq_gap_analysis.md(March 19, 2026)
Summary
The Phase 2 SOW addresses the table extension and field gaps -- the most visible shortcoming from Phase 1. It does not address the majority of the SDD's undelivered commitments, including incremental sync, deactivation logic, validation enforcement, page extensions for the newly extended tables, or the structural and security issues found in the delivered code.
| Category | Total Gaps Identified | Addressed by Phase 2 | Still Missing |
|---|---|---|---|
| Table extensions (new) | 3 tables missing extensions | 3 (Symptom, Fault, Resolution) | 0 |
| Fields on extended tables | 19 fields missing | 19 fields covered | 0 |
| Incremental sync | Not delivered | Not addressed | 1 |
| Deactivation logic | Not delivered | Not addressed | 1 |
| Page extensions (UI filtering) | 3+ surfaces missing | Not addressed | 3+ |
| Validation (reject inactive) | Not delivered | Not addressed | 1 |
| Fault Area/Symptom Relationship | Table not synced | Not addressed | 1 |
| Delete-and-reinsert pattern | Violates SDD | Not addressed | 1 |
| Double execution bug | OnAfterInsert fires sync twice | Not addressed | 1 |
| Transaction safety | No rollback/partial update protection | Not addressed | 1 |
| Service Item Worksheet filter | Commented out | Not addressed | 1 |
| Documentation | Not delivered | Mentioned (Section 4 line item) | Partially |
| Security (hardcoded creds) | 2 issues | Not addressed | 2 |
| Telemetry | Missing from app.json | Not addressed | 1 |
Bottom line: Phase 2 closes the table extension gap (the "1 of 20 fields" / "1 of 4 table extensions" problem). Everything else from the SDD commitment scorecard remains open.
Detailed Line-by-Line Mapping
What Phase 2 DOES Cover
These items from the SDD delivery mapping will be addressed if Phase 2 is delivered as scoped:
| SDD Commitment # | Commitment | Current Status | Phase 2 Impact |
|---|---|---|---|
| 1 | Synchronize fault-related master data from FAQ API into BC | Partial (4 of 6 tables) | Improves -- fields added to all 4 master tables; sync logic updated to populate them. Still does not address Fault Area/Symptom Relationship (table 50113). |
| 2 | Ensure BC uses only valid and active codes for new transactions | Partial (2 of 6 tables have Status) | Improves -- Status and Active fields added to all 4 tables. But Phase 2 does not include page extensions to filter these tables in the UI, so the fields exist but may not be enforced. |
| 13 | Inactive records retained for historical reference | Partial (2 of 6) | Improves -- all 4 master tables will have Status/Active fields to support inactive marking. |
| 14 | Only active values available for new transactions | Partial (2 of 6) | Partially improves -- fields exist, but no page extensions are in scope to filter them. |
| 17 | All existing fault-related records will be marked Inactive (full rebuild) | Partial (2 of 6) | Improves -- rebuild can now mark records on all 4 tables. Depends on sync logic updates being implemented correctly. |
| 19 | FAQ API identifiers persisted as primary reference | No (API IDs used as BC Code) | Addresses -- FAQ ID field added as a separate column on all 4 tables. |
| 27 | Maintain sync state across executions | Partial (log only, no per-record state) | Improves -- Created in FAQ and Last Modified in FAQ fields enable per-record sync state. |
| 34 | Inactive handling ensures backward compatibility | Partial (2 of 6) | Improves -- all 4 tables gain inactive capability. |
What Phase 2 Does NOT Cover
These gaps from the SDD delivery mapping remain completely unaddressed:
| SDD # | Commitment | Gap | Why It Matters |
|---|---|---|---|
| 4 | Introduce inactive handling without deleting existing records | Delete-and-reinsert pattern (codeunit 65500, lines 209-212) still present | Deleting records changes SystemId, breaking external references. This is a data integrity violation that persists regardless of Phase 2. |
| 5 | Provide controlled sync mechanisms as defined in the SDD | Only full sync exists | The SDD defines three mechanisms (full rebuild, incremental, notifications). Incremental still missing. |
| 8 | Automated incremental synchronization capability | No incremental sync | Every execution fetches the complete dataset. No "last modified" parameter, no change detection, no differential processing. Phase 2 adds the Last Modified in FAQ field which enables incremental sync, but does not implement it. |
| 11 | Supporting technical documentation | Not delivered | Phase 2 includes a "Documentation Update" line item (2-3 hrs), but the acceptance criteria only require "source code committed to repository" -- no specific documentation deliverables are defined. |
| 12 | No deletion of records once used in posted transactions | Delete(true) on line 210 | The delete-and-reinsert pattern is not in Phase 2 scope. |
| 15 | Synchronization logic must be safe to re-run | Delete-reinsert + double execution | Neither issue is addressed. The OnAfterInsert trigger (TableExt 50001, line 14) that causes every scheduled sync to run twice is not in scope. |
| 23 | Detection of changes between API data and BC cache | No change detection | Phase 2 adds the timestamp fields that could support change detection, but the actual detection logic is not in scope. |
| 26 | Mark records Inactive when removed from the API | No deactivation logic | If a code exists in BC but is absent from the next API response, nothing happens. The code to compare API results against BC records and mark missing ones as Inactive does not exist and is not in Phase 2 scope. |
| 31 | Summary of records marked Inactive (in notification) | Deactivation logic prerequisite missing | Cannot summarize deactivations that don't happen. |
| 32 | Only Active values available for selection (UI enforcement) | No page extensions for Symptom Code, Fault Code, Resolution Code | Phase 2 adds the fields but does not include page extensions to filter lookups on these tables. Users will still see all records. |
| 35 | Partial updates are avoided | No transaction wrapping | The sync loop processes records sequentially with no rollback. A failure mid-sync leaves a partially updated dataset. |
| 36 | Repeat executions do not create duplicate or invalid data | Delete-reinsert changes SystemId | Still present. |
| 37 | Final source code delivery with supporting documentation | Documentation not delivered | Phase 2's documentation line item is vague and not in the acceptance criteria. |
Structural & Security Issues Not in Phase 2 Scope
These were identified in the gap analysis and code review but are not mentioned in the Phase 2 SOW:
| Issue | Severity | Status |
|---|---|---|
Hardcoded API credentials (username=BWUFAQ&password=BWUFAQ123 in codeunit) | Critical / Security | Not addressed |
Hardcoded admin password (admin / 12345 in AdminPermission page) | Critical / Security | Not addressed |
| Double sync execution (OnAfterInsert on Job Queue Log Entry fires sync twice) | High / Bug | Not addressed |
| Delete-and-reinsert pattern (breaks SystemId referential integrity) | High / Data Integrity | Not addressed |
| Service Item Worksheet filter commented out (PageExt 50005 line 44) | Medium / Functional | Not addressed |
| No page extensions for Symptom Code, Fault Code, Resolution Code lookups | Medium / Functional | Not addressed |
| No PSI page extensions for any fault-related lookups | Medium / Functional | Not addressed |
| No validation triggers (OnValidate to reject inactive codes) | Medium / Functional | Not addressed |
No telemetry (applicationInsightsConnectionString missing from app.json) | Medium / Operational | Not addressed |
| FAQ Management page mostly commented out (700+ lines dead code) | Low / Code Quality | Not addressed |
| Inconsistent Status casing ("true"/"false" vs "True"/"False" across objects) | Low / Code Quality | Not addressed |
| No error handling in ProcessStandardFormatResponse | Medium / Reliability | Not addressed |
| Fault Area/Symptom Relationship (table 50113) completely absent | Medium / Functional | Not addressed |
Assessment
Phase 2 is a necessary but narrow step. It closes the most quantifiable gap from Phase 1 -- the missing table extensions and fields -- and adds the infrastructure (FAQ ID, timestamps) that would make future features like incremental sync and change detection possible.
However, of the 37 SDD commitments scored in the delivery mapping:
| Verdict | Phase 1 | After Phase 2 (projected) |
|---|---|---|
| Yes -- fully delivered | 13 (35%) | 13 (35%) |
| Partial -- improved but not complete | 13 (35%) | 19 (51%) -- several "No" items move to "Partial" |
| No -- not delivered | 11 (30%) | 5 (14%) |
Phase 2 moves ~6 items from "No" or "Partial" toward "Partial" or closer to "Yes," but zero "No" items become "Yes" because the SOW only adds fields -- it does not implement the logic that uses them (incremental sync, deactivation, UI filtering, validation).
Items That Should Be in Phase 2 But Are Not
If the goal is to deliver a working extension that meets the SDD, these items should be discussed with Sataware as additions to Phase 2 or as a defined Phase 3:
-
Page extensions for the 3 newly extended tables -- without these, adding Status/Active fields has no user-facing effect. Users still see all records. Estimated effort: 3-4 hrs per table (9-12 hrs total).
-
Deactivation logic -- the ability to mark records Inactive when they're absent from the API response. This is the core value proposition of the sync. Without it, the Status field is only ever set to Active. Estimated effort: 4-8 hrs.
-
Fix the delete-and-reinsert pattern -- replace
Delete(true)+Insert(true)withModify(true)on Fault/Resol. Relationship records. This is a data integrity fix, not a feature. Estimated effort: 1-2 hrs. -
Fix the double execution bug -- remove or guard the
OnAfterInsertsubscriber on Job Queue Log Entry that causes every scheduled sync to run twice. Estimated effort: 1 hr. -
Remove hardcoded credentials -- move API credentials and admin password to BC's Isolated Storage or the API Setup table. Estimated effort: 2-3 hrs.
-
Uncomment the Service Item Worksheet filter (PageExt 50005 line 44) -- or implement it correctly. Estimated effort: < 1 hr.
Total additional effort for items 1-6: ~17-26 hrs at $28/hr = $476-$728.
Recommendation
Phase 2 as scoped is worth approximately $700-$924 for table extension work that is straightforward and well-defined. The acceptance criteria are clear and verifiable. Approve the scope as-is, but before confirming:
-
Clarify "Integration & sync logic updates" (6-8 hrs) -- the SOW says this covers "support new fields across all tables." Does this include populating the new fields (FAQ ID, Created in FAQ, Last Modified in FAQ) from the API response during sync? If not, the fields will exist but be permanently empty. Get written confirmation of what "support" means.
-
Flag the items above as Phase 3 -- send Ashok a list of the remaining gaps and ask for a Phase 3 estimate that covers deactivation logic, page extensions, and bug fixes. This keeps Phase 2 on track while ensuring the remaining work is scoped and estimated before the next invoice.
-
Do not accept Phase 2 as closing the SDD -- the SDD commitment scorecard should be updated after Phase 2 delivery, but it will still show material gaps. Phase 2 is remediation of Phase 1 shortfalls, not new work.