CMS FAQ Management Extension — Delivery Review
Extension: FAQ Management (Epic 193) Version Under Review: v1.0.0.73 Vendor: Sataware Technologies LLC Solution Design Date: December 16, 2025 Review Date: March 6, 2026 Prepared by: Phil McCaffrey, ERP Specialist Organization: Bestway (USA) Inc.
Executive Summary
Sataware Technologies LLC was engaged to build a Business Central extension that synchronizes fault-related master data from the FAQ API into BC (Epic 193). The approved Solution Design (dated 12/16/25) defines six tables in scope, five required fields per fault master table (20 total across four tables), three synchronization modes, and six deliverables — including final source code delivery. The estimated effort was ~134 hours at $28/hr.
The delivered extension (v1.0.0.73) implements 1 of 20 required fields. Three of four fault master tables have zero table extensions. Source code has not been delivered despite five requests over eight days. The vendor has stated that source code is contingent on invoice payment; the Solution Design lists it as a standard deliverable.
This document recommends that UAT not proceed until: (1) source code is delivered and committed to the repository, (2) table extensions exist on all four fault master tables with all five required fields, and (3) the one-time migration is re-evaluated against the complete schema. These items should be discussed and resolved on the March 9 review call with Sataware.
1. Background
The CMS 1.0 Fault Detail Sync initiative (Epic 193) was established to synchronize fault-related master data from the external FAQ API into Microsoft Dynamics 365 Business Central. The goal is to ensure BC uses only valid, active fault codes for new transactions while preserving historical Service Orders and posted data.
Sataware Technologies LLC was engaged to design and implement the extension. The Solution Design document (dated 12/16/25) was authored by Sataware, reviewed by Bestway, and explicitly approved by Phil McCaffrey on December 16:
"This updated Solution Design appears to address and satisfy all of the acceptance criteria laid out. We are good to move forward from our side."
The Solution Design is the authoritative reference for evaluating what was delivered.
1.1. Project Timeline
| Date | Event |
|---|---|
| Dec 2, 2025 | Initial effort estimate shared by Sataware (~84 hours at $28/hr) |
| Dec 5, 2025 | Bestway approves first 5 hours for Requirement Review and Solution Design |
| Dec 9, 2025 | First draft of Solution Design delivered by Sataware |
| Dec 10, 2025 | Bestway requests changes: automated sync, full rebuild approach, email notifications |
| Dec 12, 2025 | Bestway confirms automated sync was always in scope; Rob Chowdhury (Director of IT) approves additional hours |
| Dec 16, 2025 | Updated Solution Design delivered and approved (~134 hours total) |
| Dec 23, 2025 | Sataware reports build errors (missing IWX/Innovia dependencies) |
| Feb 9, 2026 | Sataware says corrections complete; demo call scheduled |
| Feb 12, 2026 | Sataware submits Invoice #466051 |
| Feb 26, 2026 | Rob Chowdhury: testing not done; waiting for source code in repo |
| Feb 28, 2026 | v1.0.0.58 installs successfully in sandbox |
| Mar 1–3, 2026 | Versions 59–61 fail to install (BestwayUSA dependency mismatch) |
| Mar 5, 2026 | v1.0.0.73 uploaded; source code withheld pending invoice payment |
| Mar 5, 2026 | Bestway validates .app via symbol extraction; significant gaps identified |
| Mar 6, 2026 | Review call scheduled for March 9 |
2. Solution Design Requirements
The following requirements are drawn directly from the approved Solution Design document (dated December 16, 2025). Section numbers reference that document.
2.1. Scope (Section 3)
Six BC tables are explicitly in scope:
- 2.1.1. Fault Area (Table 5915)
- 2.1.2. Symptom Code (Table 5916)
- 2.1.3. Fault Code (Table 5918)
- 2.1.4. Resolution Code (Table 5919)
- 2.1.5. Fault/Resolution Relationship (Table 5920)
- 2.1.6. Fault Area/Symptom Relationship
2.2. Deliverables (Section 4)
- 2.2.1. Updated BC extension logic to support FAQ API synchronization
- 2.2.2. One-time full rebuild synchronization capability
- 2.2.3. Automated incremental synchronization capability
- 2.2.4. Stakeholder notification summary for detected changes
- 2.2.5. Final source code delivery
- 2.2.6. Supporting technical documentation
2.3. Required Fields (Derived from Sections 7.1, 7.2, 8)
The synchronization behaviors described in the Solution Design require specific fields on each fault master table. These fields are the necessary implementation of the behaviors the document specifies.
| Required Field | Derived From | Purpose |
|---|---|---|
| Status (Active/Inactive) | Sec 7.1: "All existing records will be marked Inactive" | Controls code availability |
| FAQ ID | Sec 7.1: "FAQ API identifiers will be persisted as primary reference" | Links BC records to FAQ API |
| Active (Boolean) | Sec 8: "Only Active values available for selection" | UI filtering for validation |
| Created in FAQ | Sec 7.2: "Maintain sync state across executions" | Tracks first sync timestamp |
| Last Modified in FAQ | Sec 7.2: "Detection of changes between API data and BC cache" | Change detection |
20 required field implementations (5 fields × 4 fault master tables).
Note: The five required fields apply to the four fault master tables (Fault Area, Symptom Code, Fault Code, Resolution Code). The two relationship tables (Fault/Resolution Relationship and Fault Area/Symptom Relationship) serve as cross-reference mappings and are evaluated separately in the delivery analysis (Section 3.1).
2.4. Synchronization Approaches (Section 7)
2.4.1. One-Time Full Rebuild Sync
- All existing fault-related records will be marked Inactive
- A complete import will be performed from the FAQ API
- FAQ API identifiers will be persisted as the primary reference
- Historical and posted data will remain unchanged
2.4.2. Automated Incremental Sync
- Periodic unattended execution
- Detection of changes between API data and BC cache
- Insert new records; update modified records
- Mark records Inactive when removed from the API
- Maintain sync state across executions
2.4.3. Stakeholder Notification
- Configurable recipient list
- Summary of newly added, updated, and inactivated records
2.5. Estimated Effort (Section 10)
- ~134 hours (approximate) at $28/hr
- Covers core sync, one-time rebuild, automated incremental sync, and stakeholder notification
3. Delivery Analysis — What v1.0.0.73 Contains
The compiled .app package for v1.0.0.73 was validated via symbol extraction on March 5, 2026. Source code was not available for review.
3.1. Table Extensions Delivered
| BC Table | Table ID | Extension? | Fields Added |
|---|---|---|---|
| Fault Area | 5915 | Yes | Status (Option: true/false) — Field ID 50000 |
| Symptom Code | 5916 | NONE | — |
| Fault Code | 5918 | NONE | — |
| Resolution Code | 5919 | NONE | — |
| Fault/Resol. Relationship | 5920 | Yes | Status (Option) — Field 65500; Source (Text) — Field 65501 |
| Fault Area/Symptom Rel. | — | NONE | — |
Note: The Fault Area Status field was delivered as an Option type with true/false values (Field ID 50000). The Solution Design specifies an Active/Inactive status semantic. The delivered field type does not align with the specified behavior. The Fault Area/Symptom Relationship table, listed in scope (Section 3 of the Solution Design), has no table extension and no corresponding table ID was identified in the delivery.
3.2. Required Fields vs. Delivered
| Required Field | Fault Area | Symptom Code | Fault Code | Resolution Code |
|---|---|---|---|---|
| Status | Present | Missing | Missing | Missing |
| FAQ ID | Missing | Missing | Missing | Missing |
| Active | Missing | Missing | Missing | Missing |
| Created in FAQ | Missing | Missing | Missing | Missing |
| Last Modified in FAQ | Missing | Missing | Missing | Missing |
Result: 1 of 20 required field implementations delivered (Status on Fault Area only).
4. Gap Analysis
4.1. Missing Table Extensions (CRITICAL)
Symptom Code (5916), Fault Code (5918), and Resolution Code (5919) have no table extensions. Zero fields were added to these three tables.
Without Status, FAQ ID, or sync audit fields on these tables, the extension cannot:
- 4.1.1. Mark symptom codes, fault codes, or resolution codes as Inactive (Section 7.1)
- 4.1.2. Persist FAQ API identifiers on these tables (Section 7.1)
- 4.1.3. Detect changes for incremental sync on these tables (Section 7.2)
- 4.1.4. Filter inactive codes from UI selection on these tables (Section 8)
4.2. Missing Fields on Fault Area (HIGH)
Fault Area has a Status field but is missing FAQ ID, Active, Created in FAQ, and Last Modified in FAQ. Without FAQ ID, the rebuild sync cannot use the FAQ API identifier as the primary reference (Section 7.1). Without audit fields, incremental sync cannot detect changes on this table (Section 7.2).
4.3. Premature Migration Execution (HIGH)
The one-time full rebuild migration (Section 7.1) was executed against the sandbox before Bestway had an opportunity to capture a pre-migration baseline snapshot. This is a destructive, one-time operation.
Without a pre-migration baseline:
- 4.3.1. We cannot independently verify whether historical data was preserved
- 4.3.2. We cannot verify whether records were correctly marked Inactive
- 4.3.3. We cannot compare the before-state to the after-state
- 4.3.4. If the rebuild was incomplete or incorrect, there is no reference to restore from
4.4. Source Code Not Delivered (HIGH)
Source code has not been committed to the repository despite five requests over eight days (Feb 26, Feb 27, Mar 2, Mar 4, Mar 5).
Vendor position: "We normally provide the full AL source as part of the final delivery once the invoice for the completed development work has been settled."
Sections 4 and 11 of the Solution Design list source code delivery as a deliverable, not a post-payment conditional.
4.5. Deliverable Status Summary
| Deliverable | Status |
|---|---|
| BC extension logic for FAQ sync | Partially delivered — only 2 of 6 tables have extensions |
| One-time full rebuild sync | Executed but unverifiable — no baseline, no source code |
| Automated incremental sync | Unknown — cannot verify without source code |
| Stakeholder notification | Unknown — cannot verify without source code |
| Final source code delivery | NOT DELIVERED |
| Supporting technical documentation | NOT DELIVERED |
5. Vendor Response and Assessment
On March 5, 2026, Ashok Marimuthu (CEO, Sataware Technologies LLC) responded to the gap analysis:
"Based on our earlier discussions and the demos conducted during development, the implementation focused on adding the Status field to the Fault/Resolution table to support the inactive handling behavior required for synchronization. During those discussions, the approach was to manage the active/inactive validation through the Fault Resolution codes, since that table is the one referenced for UI validation in the service order workflow."
"From a design perspective, adding the same set of additional columns across all tables would introduce additional complexity and potential issues within the existing extension structure."
5.1. Assessment
-
5.1.1. The Solution Design is the agreed specification. It was authored by Sataware, reviewed by Bestway, and approved by both parties. It does not limit the scope to the Fault/Resolution table. Section 3 explicitly lists all six tables. Sections 7.1, 7.2, and 8 describe behaviors that apply to all fault-related data entities.
-
5.1.2. The "complexity" argument is not supported by the Solution Design. The vendor estimated ~134 hours of effort for the full scope. If the scope was always limited to two tables, the effort estimate does not reflect that limitation.
-
5.1.3. Verbal discussions do not override a written, approved Solution Design. The document's stated purpose is to "clearly define the approved scope, execution behavior, and boundaries for implementation" (Section 1). If the scope was narrowed during development, the Solution Design should have been updated and re-approved.
6. Additional Context
6.1. Invoice and Payment
Sataware submitted Invoice #466051 on February 12, 2026 for the full development effort. Source code delivery and further support are stated as contingent on invoice payment.
Bestway position (Rob Chowdhury, Feb 26): "Our team hasn't tested the task yet. Phil mentioned that he's waiting for you to push the code to the repository. Once everything is confirmed and moved to production, we'll inform our AP to proceed."
6.2. Source Code Request Timeline
| Date | Channel | Response |
|---|---|---|
| Feb 26, 2026 | Teams chat | Acknowledged |
| Feb 27, 2026 | Teams chat | Acknowledged |
| Mar 2, 2026 | No response | |
| Mar 4, 2026 | Email (detailed request) | Acknowledged |
| Mar 5, 2026 | Email (5th request) | Withheld until invoice paid |
6.3. Effort Estimate History
| Date | Estimate | Scope |
|---|---|---|
| Dec 2, 2025 | ~84 hours | Core sync functionality (manual trigger) |
| Dec 12, 2025 | +40–50 hours | Automated sync + email notifications |
| Dec 16, 2025 | ~134 hours | Full scope per approved Solution Design |
7. Open Questions for March 9 Review Call
The following items should be addressed on the call with Sataware:
-
7.1. Scope alignment: Does Sataware agree that the Solution Design (dated 12/16/25) is the specification for the delivered extension? If the scope was narrowed during development, why was the Solution Design not updated?
-
7.2. Missing table extensions: What is the plan to deliver table extensions for Symptom Code (5916), Fault Code (5918), and Resolution Code (5919)?
-
7.3. Missing fields: What is the plan to deliver FAQ ID, Active, Created in FAQ, and Last Modified in FAQ fields on all four fault master tables?
-
7.4. Migration verification: Can Sataware provide logs or evidence of what the rebuild migration did? What records were marked Inactive? What was imported?
-
7.5. Automated incremental sync: Has this been implemented? If so, how does it function without sync audit fields on the majority of the fault tables?
-
7.6. Stakeholder notification: Has this been implemented?
-
7.7. Source code: When will source code be committed to the repository? The Solution Design lists this as a deliverable, not a post-payment conditional.
-
7.8. Invoice reconciliation: The delivered extension does not implement the scope defined in the Solution Design. How should the invoice be reconciled against the actual delivery?
8. Next Steps
8.1. Before UAT Can Proceed
-
8.1.1. Source code must be delivered and committed to the repository. Without source code, Bestway cannot verify the implementation, troubleshoot issues, or maintain the extension.
-
8.1.2. Table extensions must exist on all four fault master tables. Symptom Code, Fault Code, and Resolution Code need table extensions with the fields required by the Solution Design.
-
8.1.3. All five required fields must be present on all four tables. Status, FAQ ID, Active, Created in FAQ, and Last Modified in FAQ.
-
8.1.4. Migration must be re-evaluated. If the rebuild ran against incomplete table extensions, the results may be incomplete or incorrect. A re-run may be required once the full schema is in place.
8.2. On the Call
- 8.2.1. Walk through this document section by section
- 8.2.2. Get explicit agreement on whether the Solution Design is the specification
- 8.2.3. Get a concrete remediation plan with dates for delivering the missing scope
- 8.2.4. Discuss invoice reconciliation in the context of the delivery gaps
Appendix A: Reference Documents
| Document | Date | Location |
|---|---|---|
| The following documents are maintained in Bestway's internal repository and are available upon request. |
| Solution Design | Dec 16, 2025 | V1_CSM_1_0_Fault_Detail_Sync_Solution_Design.pdf | | FAQ API to BC Mapping | Dec 2025 | FAQ API to BC Mapping.png | | Epic 193 Requirements | Nov 2025 | Epic - Sync Business Central with FAQ API.docx | | This Delivery Review | Mar 6, 2026 | CMS FAQ Management - Delivery Review v1.1.docx |