BC Development — Status Update
Period: March 5 – 19, 2026 Prepared for: Jennifer Dwiggins, Rob Chowdhury Meeting: CSM3 Brainstorming — March 20, 2026, 11:00 AM MST
Executive Summary
Over the past two weeks, we shipped 8 releases across 4 extensions, resolved a critical production issue (ISSUE-12), and built an automated test infrastructure covering 125+ test cases across 4,600+ lines of test code. We published formal contribution guidelines that establish acceptance criteria for all vendor deliveries — a direct response to the CMS FAQ Management delivery gaps. The CMS FAQ gap analysis objectively documents that Sataware delivered 5% of the required field coverage, with hardcoded credentials and commented-out core functionality.
An automated pipeline resolved 22 of 27 missing QR tickets today — reducing the stuck submissions backlog by 96% since late February (126 → 5 genuinely unresolvable). PO Email v1.2.0.0 is deployed to Production with post-deployment action items pending (permission set assignment for 12 users). Service Order Lockout v1.1.1.0 is undergoing automated UAT ahead of Production deployment. BC Dialing v2.4.0.0 is deploying to Production.
1. Test Automation Infrastructure
This is the biggest capability gain of the period. We now have a shared Python test library (tools/bc_test_helpers/) with 8 reusable modules that any BC extension can use for automated testing:
| Module | Purpose |
|---|---|
bc_api_client.py | Generic OData API client with MSAL OAuth2 |
bc_playwright_helpers.py | Browser automation for BC web client |
bc_user_manager.py | Automated test user lifecycle (BC) |
entra_user_manager.py | Entra ID user CRUD via Graph API |
auth_manager.py | Playwright SSO login and auth state caching |
test_data_manager.py | Test record isolation (claim/release pattern) |
report_adapter.py | Maps pytest results to TC-X.Y test case IDs |
conftest_base.py | Shared pytest fixtures for all extensions |
Coverage by Extension
| Extension | Modules | Test Functions | Lines of Code | Type |
|---|---|---|---|---|
| Service Order Lockout | 12 | 40 | 2,094 | API + Playwright |
| CMS FAQ Management | 10 | 60 | 1,429 | API (GAP-annotated) |
| PO Email Notification | 2 | 25 | 1,077 | API + Playwright |
| CSM API Toolkit | 1 | 6 | — | AL (BC Test Tool) |
| Totals | 25 | 131 | 4,600+ | — |
Additionally, 14 UAT test plan Word documents have been generated via automated Python tooling, and test results are output as timestamped Word docs for audit trails.
Why this matters: Before this period, we had 0 automated tests outside of the CSM API's 6 AL tests. We now have 131 automated test functions that can validate extension behavior on every deployment. This eliminates the "it worked when I tested it manually" gap and gives us objective, repeatable verification.
2. BC Dialing Application (Nextiva Integration)
Current Production: v2.3.6.0 Ready for Production: v2.4.0.0
ISSUE-12 — RESOLVED (March 10)
This was the critical issue blocking customer record creation via the Nextiva integration. After 5 code releases investigating the root cause, we identified that the Versapay Payments extension's OnInsert subscriber on the Customer table was reading Table 37028480 (Versapay ARC Setup) — a table outside our extension's dependency chain.
Root cause fix: Added CL GENERAL -CL-, EFT GENERAL -CL-, EFT SETUP -CL- permission sets to the Entra application on BC page 9861. This was an admin-side fix — the AL compiler cannot reference tables outside an extension's declared dependencies, so a code fix was not possible.
Key learning: The S2S user_Id in Application Insights is the Azure AD object ID, not the BC userSecurityId. Entra applications are managed on page 9861, not the Users page 9800.
Other Issues
| Issue | Severity | Status | Resolution |
|---|---|---|---|
| ISSUE-12 | CRITICAL | RESOLVED | Versapay permission sets added to Entra app |
| ISSUE-13 | MEDIUM | MONITORING | "Page not up to date" on CE-0250097 — no reports since March 11 |
| ISSUE-14 | HIGH | SELF-RESOLVING | Orphaned phone logs from pre-ISSUE-12 era — clearing naturally |
| ISSUE-15 | MEDIUM | FIXED in v2.4.0.0 | Batch caps (default 50), immediate abandonment for permanent failures |
v2.4.0.0 Improvements
- String width fixes: AssetType, PhoneNumber, EmailAddress fields
- SecretText migration for credential handling
- 100 fewer database operations per batch cycle
- Batch processing caps to prevent runaway jobs
Active Thread: Phone Number Format
Rob, Jen, Ashok, and James Bird (Nextiva) are engaged on the "Urgent: Update Phone Number Format" email thread. Sataware deployed an Azure Function fix to the sandbox on March 19. Rob offered Azure Portal access. James is engaged on timeline. Jen asked: "Please advise how quickly testing can be completed."
Decision needed: v2.4.0.0 Production deployment timing.
3. Failed CSM Submissions Resolver Pipeline
An automated pipeline that resolves stuck CSM1 submissions by fuzzy-matching BC fault codes against the FAQ API and submitting directly to CSM1 — zero CS agent involvement.
How It Works
The resolver reads failed QR submissions from BC, identifies why they failed (typically a fault code or resolution code that doesn't have a direct match in CSM1's FAQ system), performs fuzzy matching against the FAQ API to find the closest valid mapping, and re-submits to CSM1 with the corrected codes.
Results
| Date | Action | Outcome |
|---|---|---|
| March 5 | Initial pipeline run | 187 records sent successfully |
| March 20 | ECOM location code bug found and fixed | Location codes starting with "ECOM" were being excluded — these account for ~20% of CSM1 tickets |
| March 20 | Re-run after fix | 22 of Peilin's 27 missing tickets resolved and submitted (all HTTP 200) |
Remaining Unresolvable Records (5)
Five tickets from Peilin's March 17 report cannot be resolved because no valid FAQ mappings exist for their resolution codes:
- PCSI137012
- PCSI140589
- PCSI140989
- PCSI146525
- PCSI156319
These require either new FAQ API mappings to be created or manual resolution by CS.
Why this matters: This pipeline eliminates an entire category of manual work. Before this, every failed QR submission required a CS agent to manually look up fault codes, find the correct mapping, and re-submit through CSM1. The pipeline does it automatically and at scale — 209 records resolved across two runs with no human intervention.
4. CMS FAQ Management (Sataware)
This workstream is a vendor accountability story. The gap analysis objectively documents what was delivered versus what was specified.
Gap Analysis Summary (March 19)
| Area | Expected | Delivered | Coverage |
|---|---|---|---|
| Required fields (5 fields × 4 tables) | 20 | 1 (Status on Fault Area) | 5% |
| Table extensions (4 master tables) | 4 | 1 (Fault Area only) | 25% |
| Sync modes (full + incremental) | 2 | 1 (full only) | 50% |
| Active filtering (SO, SIW, PSI) | 3 surfaces | 1 partial | ~15% |
| Validation (reject inactive codes) | Required | Not implemented | 0% |
| Email notifications | Required | Entirely commented out | 0% |
| Sync state / audit trail | Required | Table exists but unused | ~10% |
Security Issues Found in Delivered Code
- Hardcoded API credentials in
FAQAPIIntegration.Codeunit.al:24—username=BWUFAQ&password=BWUFAQ123 - Hardcoded admin password in
AdminPermission.Page.al:35-36—admin/12345
Structural Issues
- FAQ Management page (65504) is entirely commented out — 700+ lines of dead code covering the dashboard, email, scheduling, and reporting
- No
applicationInsightsConnectionStringin app.json (no telemetry) - No error handling or transaction management in sync processing
- Multiple objects crammed into single files
Version Gap
Source code delivered is v1.0.0.57. The compiled .app binary is v1.0.0.73. That is 16 revisions of source code we do not have. Source has been requested 6 times since February 26:
- Feb 26 — initial request
- Mar 3 — follow-up
- Mar 7 — follow-up
- Mar 12 — follow-up
- Mar 18 — Rob asked Ashok: "Have you sent the code to Phil?"
- Mar 19 — Phil to Ashok: 6th request. Ashok uploaded a zip. Phil identified version discrepancy in the response.
Automated Test Suite
60 test functions built specifically to objectively prove the gap analysis. Tests are annotated with GAP markers — when a test fails, the failure maps directly to a documented delivery gap. This removes ambiguity from the vendor conversation: the tests either pass or they don't.
5. Contribution Guidelines
Published docs/CONTRIBUTING.md — formal acceptance criteria for all vendor deliveries. This is a direct response to the CMS FAQ experience and establishes the bar going forward.
Key sections: app.json requirements, folder structure, naming conventions, code quality standards (including AL anti-patterns), performance requirements, documentation standards, test plan expectations.
Key line: "Work that does not meet these standards will be returned for remediation before UAT can proceed."
v1.0 underwent adversarial review with 16 findings identified and applied. Committed March 9 (dc252cf). Available as both markdown and formatted Word document.
6. PO Email Notification
Production version: v1.2.0.0 (deployed March 20)
v1.1.0.0 — Security Overhaul
- Hardcoded Azure AD credentials replaced with Isolated Storage setup page
Email.Sendreplaced withEmail.Enqueue(non-blocking — emails no longer block the PO workflow)- TempEmailResults record handling fixed
- 28 telemetry events added for full observability
v1.1.1.0 — Performance
- Redundant database query eliminated in the email preparation path
- Missing
SetLoadFieldsadded for Customer lookups
v1.2.0.0 — ID Migration + Bug Fixes (8 items)
- Field ID 50119 → 80100 on 3 table extensions — eliminates collision with BestwayUSA's reserved range
- Enum value 50149 → 80100 — same collision risk resolved
- OnLookup concatenation bug fixed (CRITICAL) — search text was being embedded in the recipient list instead of appending to the existing field value
- Guarded Get() calls — prevents runtime errors that would block warehouse receipt creation
- SetLoadFields completions — 4 missing filter fields + PurchHeader.Get() in subscriber loop (200+ fields → 4)
- Permission set UX — added Caption and Assignable = true
- Dead code removed — PO Email Dispatcher codeunit (80102) deleted, zero callers
Production Deployment (March 20)
Deployed v1.2.0.0 to Production. This closes Jen's March 6 and March 13 asks.
- Sandbox: 23/23 automated tests passing (21 API + 2 Playwright browser)
- Deployment blocker: Orphaned "Temp Email Results" table from v1.0.88.5 contained cached data — BC refused to drop it with "Add" schema sync. Resolved by unpublishing both old copies and re-uploading with "Force" schema sync mode.
- Post-deployment config completed: PO Email Setup configured with Graph API credentials, email scenario covered by default BW Do Not Reply account
- Action item for meeting: POEMAILPERMISSIONSET assignment to BW-SUPPLYCHAIN-MGR users (12 users) — the S2S automation app lacks permission to assign permission sets, so this requires either manual assignment via the BC web client or an Entra security group mapping. Need to determine who handles this and the timeline, as users without the permission set will not have access to the email lookup or setup pages
7. Service Order Lockout
Current version: v1.1.1.0 (March 20)
v1.1.0.0 (February 27) — Defect Fixes
14 defects fixed, including 2 CRITICAL:
- Inverted permission check that blocked all CS users with BW-CS-SERVICE role
- BW-CS-SERVICE permission set referenced but never defined
Additional: stale lock auto-release (configurable timeout, default 4 hours), SUPER user lock release action, setup page.
v1.1.0.1 (March 19) — API and Test Automation
- API pages 52403/52404 for external integration
- Playwright test suite: 12 test areas, 40 test functions
- Security hardening
v1.1.1.0 (March 20) — Permission Model Overhaul
Investigated all 200 enabled users in BC sandbox to map the existing CS permission structure. Found that BW-ASSIGNSVCORD (33 users) and BW-CS-MANAGERS (21 users) already map to the exact roles needed.
- Page gate now checks
BW-ASSIGNSVCORDinstead ofBW-CS-SERVICE— no manual permission assignment needed at deployment - Release Lock now permits
BW-CS-MANAGERSorSUPER— CS supervisors (Allyson, Javier, Diana, etc.) can release stuck locks without escalating to IT - Upgrade codeunit auto-assigns
BW-CS-SERVICEto allBW-ASSIGNSVCORDusers for table-level permissions - Three-tier access model: CS Temps (open/lock), CS Managers (open/lock/release), SUPER (bypass all)
Deployment status: Automated UAT is in progress against the sandbox. No deployment blockers identified. Ready for Production pending UAT completion.
8. CSM API Toolkit
v1.2.0.0 (March 5)
- Posted Service Invoice Header API page (56123)
- Combined database lookups from 2 queries to 1 per row
- 6 new test functions in test codeunit 56115
v1.5.0.0 (March 6)
- Status field added to Fault Area API — required for CMS FAQ Management dependency
9. Innovia Source Code Sync
- Phil requested DevOps access for Innovia (March 11)
- Rob granted access same day
- Mark Newman committed BestwayUSA, BW_DataAPIReport, and eShop Modifications source (March 12-13)
- PR reviewed and merged March 16
- Sami Jenedi had initial access issues — resolved
This gives us the current source for the BestwayUSA extension (published in Production as v27.0.0.0 by Innovia). We can now review changes, run diffs, and maintain continuity if Innovia's engagement changes.
10. Infrastructure and Housekeeping
- Azure Telemetry: Urgent email to Rob on March 11 regarding data retention configuration
- BC Platform: Sandboxes updated to v27.2 (March 13-14). BC v27.5 available — updates scheduled May-July 2026
- Repository: Telemetry connection strings added to extensions missing them, ID range corrections,
.env.exampleand.gitignorestandardization - Versapay Job Error: Jen flagged March 12, resolved March 13
11. QR Weekly Report — Missing Ticket Resolution
Peilin's March 17 weekly QR report flagged 27 missing ticket IDs (period: March 9–15). The CSM Submissions Resolver pipeline was run on March 20 to address them.
Results
| Category | Count | Detail |
|---|---|---|
| Resolved and submitted | 22 | All returned HTTP 200 from CSM1 |
| Unresolvable | 5 | No valid FAQ mappings exist for their resolution codes |
Unresolvable Tickets
| Ticket ID | Reason |
|---|---|
| PCSI137012 | No valid FAQ mapping for resolution code |
| PCSI140589 | No valid FAQ mapping for resolution code |
| PCSI140989 | No valid FAQ mapping for resolution code |
| PCSI146525 | No valid FAQ mapping for resolution code |
| PCSI156319 | No valid FAQ mapping for resolution code |
Root Cause
The resolver pipeline was excluding records with ECOM location codes. ECOM locations account for approximately 20% of CSM1 tickets, so their exclusion was a significant gap. The bug was identified and fixed on March 20 before the re-run.
Trend
| Report Period | Missing/Error Tickets | Action Taken |
|---|---|---|
| Feb 9–22 | 126 | Identified CSM Quality Sent flag bug |
| Feb 23–Mar 1 | Same issues persisting | Root cause analysis |
| Mar 2–8 | 14 (down from 126) | Duplicate fix deployed Mar 6, backfill of 855 records |
| Mar 9–15 | 27 | ECOM bug fixed, 22 resolved via pipeline Mar 20 |
Net: From 126 stuck tickets in late February to 5 genuinely unresolvable records. The pipeline and bug fixes have cleared 96% of the backlog.
12. Open Items
| # | Item | Owner | Status | Priority |
|---|---|---|---|---|
| 1 | ISSUE-13 "Page not up to date" on Customer | Phil | Monitoring — no user reports since March 11 (9 days). Record version conflict, not lock timeout. Likely reduced by ISSUE-12 fix. If recurrence, investigate BC Dialing Job Queue writes to Customer records. | LOW |
| 2 | CMS FAQ v1.0.0.73 source from Sataware | Ashok | Version gap identified, follow-up sent | HIGH |
| 3 | Phone number format fix (Azure Function) | Sataware | Deployed to sandbox, testing needed | HIGH |
| 4 | PO Email permission set assignment | Phil/Rob | v1.2.0.0 DEPLOYED to Production. Setup configured. Meeting discussion: assign POEMAILPERMISSIONSET to 12 BW-SUPPLYCHAIN-MGR users — S2S app lacks permission to assign. Needs manual assignment via BC web client or Entra security group. Users without it cannot access email lookup or setup pages. | MEDIUM |
| 5 | SOL v1.1.1.0 Production deployment | Phil | AUTOMATED UAT IN PROGRESS — running against sandbox. v1.1.1.0 eliminates manual permission assignment. Upgrade codeunit auto-assigns BW-CS-SERVICE. Gate uses existing BW-ASSIGNSVCORD role. CS Managers can now release locks. Deploy to Production pending UAT completion. | MEDIUM |
| 6 | BC Dialing v2.4.0.0 Production deployment | Phil | DEPLOYING — proceeding ASAP, independent of phone format fix (Azure Function, separate deployment) | HIGH |
| 7 | QR missing ticket IDs (27) | Phil | IN PROGRESS — pipeline re-run March 20 to address 27 missing tickets from Peilin's March 17 report. Pending confirmation of results. | LOW |
| 8 | Versapay ARC lock timeouts | Rob/Innovia | NEW — 4 lock timeouts on Versapay ARC Log table March 19, WebClient sessions contending with Versapay Job Queue. Not caused by our extensions. | MEDIUM |
Decisions Needed
- BC Dialing v2.4.0.0 — Deploying to Production ASAP. Phone format fix is an Azure Function (separate deployment path).
- PO Email v1.2.0.0 — DEPLOYED to Production March 20. Closes Jen's March 6 and March 13 asks. Post-deployment config complete. Action needed: POEMAILPERMISSIONSET must be assigned to 12 BW-SUPPLYCHAIN-MGR users — who handles this and when? S2S app cannot assign; requires manual BC web client assignment or Entra security group.
- Service Order Lockout v1.1.1.0 — Automated UAT in progress against sandbox. No manual permission assignment needed at deployment. Deploy to Production once UAT completes.
- CMS FAQ Management — How do we want to handle the 5% delivery with Sataware? Return for remediation per Contribution Guidelines, or negotiate a timeline?
Upcoming Initiatives
1. Extension Documentation Coverage
Five of our extensions have complete documentation (README, CHANGELOG, CHANGE docs, UAT test plans). The remaining extensions — including BestwayUSA (our largest at 190+ objects), BW_DataAPIReport, and the Quarterly Commissions Report — have no README or change documentation. The goal is to bring every extension up to the standard defined in the Contribution Guidelines: a README that describes purpose, setup, configuration, and usage; a two-tier changelog; and a UAT test plan.
This is foundational work. Without it, any developer picking up one of these extensions — whether internal or a new vendor — starts from zero context. The documentation for the extensions we've already touched (BC Dialing, CSM API, Service Order Lockout, PO Email, CMS FAQ) has already proven its value in reducing back-and-forth and shortening onboarding time.
2. Stakeholder Documentation Portal
Today, all extension documentation lives in the git repo as markdown files. This means anyone who needs to reference a README, a change document, a test plan, or the contribution guidelines must either have repo access or receive a copy via email. That's a barrier for non-technical stakeholders (Jen, CS managers, vendor project managers) and creates stale copies floating around in inboxes.
The plan is to build a documentation site — similar to what Mintlify, GitBook, or Docusaurus provide — that publishes the repo's documentation to a clean, searchable web interface. Key requirements:
- Auto-publish from the repo — documentation updates on merge, no manual deployment
- Organized by extension — each extension's docs grouped together (README, changelogs, test plans)
- Searchable — find any procedure, test case, or deployment note across all extensions
- No repo access required — accessible to anyone with a Bestway account
- Version history — see what changed and when, without needing git
This gives Jen visibility into what's been delivered, gives vendors a single reference for contribution standards, and gives CS managers access to test plans and release notes without going through IT.
3. Automated Test Coverage Expansion
We built the test infrastructure (125+ tests, shared library) around four extensions this period. The next step is extending that coverage to the remaining extensions — starting with BestwayUSA (190+ objects, zero automated tests) and BW_DataAPIReport. The bc_test_helpers library was designed for reuse: any extension can spin up API-level and Playwright browser tests using the same patterns. The goal is that no extension goes to Production without automated test validation.
4. Development Pipeline and Vendor Accountability
Currently, code gets to Production through manual review and manual deployment. There is no enforced gate between "vendor says it's done" and "extension is published to Production." The plan:
- Pull request enforcement — all changes go through PRs on Azure DevOps, no direct pushes to main
- Automated shipment readiness checks — PRs are blocked unless they pass the Shipment Readiness Checklist (documentation exists, tests pass, telemetry configured, version bumped, ID ranges respected)
- Vendor payment tied to pipeline success — vendor deliveries are not accepted (and invoices are not approved) until the code passes the automated validation pipeline and deploys successfully to the sandbox. This closes the loop on the CMS FAQ situation where we received a 5% delivery with hardcoded credentials and no way to objectively reject it before it consumed review cycles
This changes the vendor conversation from "we reviewed your code and found problems" to "the pipeline rejected your submission — here's the report." It removes subjectivity and puts the burden of proof on the vendor.
5. Proactive Telemetry Monitoring and Alerting
All extensions now emit telemetry to Azure Application Insights, but monitoring is reactive — we find problems when users report them or when we happen to query the logs. The plan is to build proactive monitoring:
- Errors and exceptions — automated alerts when extension error rates exceed baseline thresholds, with severity classification and affected user counts
- Performance degradation — alerts on long-running operations, elevated SQL lock timeout rates (like the Versapay issue we surfaced today — 18 lock timeouts on March 19 that nobody noticed until we queried for it), and slow API response times
- Resource contention — monitoring for storage growth, Job Queue backlogs, and processing bottlenecks that indicate capacity issues before they become outages
The Versapay lock timeout finding from this session is a perfect example: 4 lock timeouts per day on the Versapay ARC Log table from WebClient sessions contending with the Versapay Job Queue. Nobody knew about it until we went looking. Proactive alerts would have surfaced this the day it started.
6. BC Platform Upgrade Readiness
BC v27.2 is deployed to our sandboxes. BC v27.5 is available, with updates scheduled May–July 2026. Microsoft publishes a rolling upgrade calendar with forced upgrade windows — if we don't upgrade proactively, Microsoft upgrades us on their schedule.
We need:
- Upgrade calendar tracking — know the exact dates for planned and forced upgrades, mapped against our deployment schedule
- Compatibility assessment — for each upgrade, identify breaking changes, deprecated features, and runtime version bumps that affect our 8+ extensions and their dependencies (especially BW_DataAPIReport with its 20+ dependencies)
- Mitigation plan — sandbox testing window before each Production upgrade, with automated test suites validating all extensions against the new platform version. This is where the test coverage expansion (initiative #3) pays off: if every extension has automated tests, we can run them against a sandbox on the new BC version and know within minutes if anything breaks
7. BC Data Archiving and Storage Management
BC environments accumulate data over time — ledger entries, posted documents, change logs, telemetry records — and Microsoft charges for storage overages above the included capacity per environment. Without a proactive archiving strategy, storage costs grow silently until they show up on the invoice.
This initiative covers:
- Storage audit — inventory current database size by table, identify the largest consumers (posted ledger entries, change log, job queue log, telemetry), and map growth rates to project when overages will hit
- Archiving options — evaluate BC's built-in data archiving (available in BC 23+), third-party archiving extensions, and manual approaches (export to Azure Blob Storage or Data Lake). Each has tradeoffs around accessibility, compliance, and cost
- Retention policies — define how long different record types need to be retained in the live database vs. archived storage, aligned with Bestway's compliance and operational requirements
- Storage overage monitoring — proactive alerting when environment storage approaches the included threshold, so we can archive before Microsoft applies overage charges
Appendix A: BC Dialing Application — Issue Tracker
All issues tracked against the BC Dialing Application (Nextiva Integration). Issues are referenced throughout this report by ID.
Summary
| ID | Title | Severity | Status | Version Fixed |
|---|---|---|---|---|
| ISSUE-1 | DB writes interleaved with HTTP I/O (root cause of locking) | CRITICAL | FIXED | v2.3.0.0 |
| ISSUE-2 | 4 redundant Customer lookups per phone log record | HIGH | FIXED | v2.3.0.0 |
| ISSUE-3 | 4 redundant Modifies on CustomerPhoneLog per record | HIGH | FIXED | v2.3.0.0 |
| ISSUE-4 | Page 80004 EndMailCall — empty trigger | MEDIUM | FIXED | v2.3.0.0 |
| ISSUE-5 | CU-60000 legacy PhoneIntegration bugs | HIGH | FIXED | v2.3.0.0 |
| ISSUE-6 | Hardcoded Nextiva credentials | CRITICAL | FIXED | v2.3.0.0 |
| ISSUE-7 | Hardcoded Production URL | MEDIUM | FIXED | v2.3.0.0 |
| ISSUE-8 | Hardcoded Customer Template | MEDIUM | FIXED | v2.3.0.0 |
| ISSUE-9 | Hardcoded Azure Blob SAS Token | MEDIUM | FIXED | v2.3.0.0 |
| ISSUE-10 | Manual Sync date-based path regression | MEDIUM | FIXED | v2.3.0.0 |
| ISSUE-11 | Permission set incomplete | LOW | FIXED | v2.3.0.0 |
| ISSUE-12 | HTTP 403 on new Customer creation | CRITICAL | RESOLVED | Admin fix (2026-03-10) |
| ISSUE-13 | "Page is not up-to-date" error on Customer record | MEDIUM | MONITORING | — |
| ISSUE-14 | Job Queue 91% phone log error rate | HIGH | SELF-RESOLVING | — |
| ISSUE-15 | Pending email log backlog not clearing | MEDIUM | FIXED | v2.4.0.0 |
ISSUE-1: DB Writes Interleaved with HTTP I/O (CRITICAL — FIXED)
The original architecture in CU-60003 mixed database writes with HTTP calls to Nextiva APIs and Azure Blob Storage uploads within the same transaction. This held exclusive locks on Customer and PhoneLog tables for 15–40 seconds per record while waiting on external I/O — causing lock timeouts (RT0012/RT0013) that blocked CS agents from opening Customer cards.
Fix (v2.3.0.0): Complete rewrite of the processing flow into Phase 1 (HTTP + blob operations, no DB writes) and Phase 2 (DB writes only). Lock duration reduced from 15–40s to <1s per record. Confirmed in Production: zero lock timeouts in 7+ days post-deployment.
ISSUE-2: 4 Redundant Customer Lookups Per Phone Log (HIGH — FIXED)
Each phone log record triggered 4 separate Customer.Get() calls — one for each artifact type (summary, recording, transcript, call data). All 4 looked up the same customer.
Fix (v2.3.0.0): Single Customer lookup in TryProcessPhoneLog, Customer "No." passed to downstream procedures. 4 lookups → 1.
ISSUE-3: 4 Redundant Modifies on CustomerPhoneLog (HIGH — FIXED)
Each artifact save individually Modified the phone log record to update its processed flag. Four separate Modify() calls per record.
Fix (v2.3.0.0): Single Get+Modify via UpdateAllPhoneLogFlags. 4 modifies → 1.
ISSUE-4: Page 80004 EndMailCall — Empty Trigger (MEDIUM — FIXED)
The EndMailCall API page (80004) had an empty OnInsertRecord trigger — it accepted inbound email events but performed no Customer lookup, leaving the email log orphaned.
Fix (v2.3.0.0): Added Customer email lookup in OnInsertRecord matching the EndCall pattern on Page 80001.
ISSUE-5: CU-60000 Legacy PhoneIntegration Bugs (HIGH — FIXED)
The legacy PhoneIntegration codeunit (CU-60000) had multiple issues: missing SetLoadFields on Customer lookups, Modify() without trigger (skipping OnModify subscribers), hardcoded URLs, and missing permission declarations.
Fix (v2.3.0.0): SetLoadFields added, Modify(true) after template application, inline Permissions declared, config-driven URL.
ISSUE-6: Hardcoded Nextiva Credentials (CRITICAL — FIXED)
Nextiva API credentials (login URL, auth token) were hardcoded directly in CU-60003 and CU-60004 source code.
Fix (v2.3.0.0): Credentials read from NextivaConfig table (80003) with configuration page. Hardcoded fallbacks retained temporarily with telemetry warnings (BCDIALER-0001 through BCDIALER-0003) — scheduled for removal in v2.4.0.0.
ISSUE-7: Hardcoded Production URL (MEDIUM — FIXED)
The BC Base URL for screen pop was hardcoded in API pages and CU-60000, preventing sandbox testing and making URL changes require a code deployment.
Fix (v2.3.0.0): URL read from NextivaConfig with fallback. Confirmed correct via BCDIALER-0010 telemetry in v2.3.1.0.
ISSUE-8: Hardcoded Customer Template (MEDIUM — FIXED)
Customer template name ("ECOMMERCE") was hardcoded in API pages 80000 and 80003.
Fix (v2.3.0.0): Template read from NextivaConfig."Customer Template" with 'ECOMMERCE' fallback.
ISSUE-9: Hardcoded Azure Blob SAS Token (MEDIUM — FIXED)
Azure Blob Storage SAS token was hardcoded in CU-60003 and CU-60004 source code.
Fix (v2.3.0.0): "Azure Blob SAS Token" field added to NextivaConfig table. TryInitializeAuth reads from config with hardcoded fallback (same transitional pattern as ISSUE-6).
ISSUE-10: Manual Sync Date-Based Path Regression (MEDIUM — FIXED)
The Manual Sync page (Pag-80009) date-based path was still calling legacy Save* procedures that interleaved DB writes with HTTP calls (the same pattern fixed in ISSUE-1 for the Job Queue path).
Fix (v2.3.0.0): Date-based path now calls FetchAndUpload* + WriteBlobLinks + UpdateFlags directly. Legacy Save* stubs removed from CU-60003.
ISSUE-11: Permission Set Incomplete (LOW — FIXED)
BCDialerPermissions permission set was missing entries for CU-60004, CU-60005, and Page 80010.
Fix (v2.3.0.0): All three added to the permission set.
ISSUE-12: HTTP 403 on New Customer Creation (CRITICAL — RESOLVED)
New customer creation via Nextiva inbound calls/emails returned HTTP 403 (NavPermissionException). This was the highest-impact issue of the period — it meant every new caller or emailer could not have a customer record created automatically, falling back to manual CS agent entry.
Root cause: The Versapay Payments extension has an OnInsert event subscriber on the Customer table that reads Table 37028480 (Versapay ARC Setup). When Customer.Insert(true) fires, BC executes OnInsert subscribers from ALL installed extensions — not just the calling extension's dependencies. The Nextiva service account (Entra application) lacked the Versapay permission sets needed to satisfy this cross-extension read.
Why a code fix was impossible: The AL compiler requires all table references in the Permissions property to be resolvable via the dependency chain. Table 37028480 belongs to the Versapay Cloud Platform Setup extension, which is not in BC Dialing's app.json dependencies. Adding tabledata 37028480 = R produces compiler error AL0185.
Fix (2026-03-10): Admin-side — added CL GENERAL -CL-, EFT GENERAL -CL-, and EFT SETUP -CL- permission sets to the Nextiva Entra application on BC page 9861. BCDIALER-0021 errors dropped to zero within minutes.
Investigation path: 5 code releases (v2.3.1.0 through v2.3.6.0) progressively added permission tables and diagnostic telemetry. The [TryFunction] wrapper added in v2.3.6.0 captured the exact error text naming the Versapay table, extension, and permission set — which led directly to the admin fix.
ISSUE-13: "Page is not up-to-date" Error on Customer Record (MEDIUM — MONITORING)
CS agents occasionally receive "The changes to the Customer record cannot be saved because some information on the page is not up-to-date" when editing customer records. First reported March 9 by Allyson Sinquah on Customer CE-0250097 (Rich Aitken). Nathan Froncek confirmed the same error on the same customer.
Telemetry: No RT0012/RT0013 (lock timeouts) in 7+ days — the locking fix from ISSUE-1 is holding. This is a standard BC record version conflict: another process modifies the Customer record between the time the page loads and the time the user saves.
Hypothesis: CU-60003 Job Queue writes Record Links to Customer records during artifact processing. If a CS agent has the same customer card open, BC detects the version mismatch on save. The ISSUE-12 fix (more successful customer creations) may have increased the frequency of concurrent writes.
Current status: No user reports since March 11 (9 days). Monitoring. If recurrence, next step is correlating Job Queue activity timestamps with the error events on specific customer records.
ISSUE-14: Job Queue 91% Phone Log Error Rate (HIGH — SELF-RESOLVING)
Job Queue runs showed 84/92 phone logs erroring with "Customer not found for phone log" (BCDIALER-5000). 11 distinct phone numbers failing, all exhausting the 3-attempt retry limit and being abandoned (BCDIALER-5001).
Root cause: These phone logs reference calls that arrived while ISSUE-12 was active. The API pages returned 403 instead of creating a Customer record, but the phone log was still written. The Job Queue then cannot find a Customer to attach artifacts (recordings, transcripts) to.
Resolution: Self-resolves now that ISSUE-12 is fixed. New inbound calls create customers successfully. Orphaned phone logs from the ISSUE-12 era will remain errored unless manually reprocessed. BCDIALER-5000/5001 event rates are declining as new traffic replaces the orphaned backlog.
ISSUE-15: Pending Email Log Backlog Not Clearing (MEDIUM — FIXED)
Pending email log count was steady at ~630 across multiple Job Queue runs. Processing 8–16 records per run with 0 errors, but the backlog was not shrinking — new records arriving faster than processing.
Root cause: No batch size cap in the email processing loop, but throughput was limited by the sequential HTTP calls per record (Nextiva API auth + artifact fetch + Azure Blob upload).
Fix (v2.4.0.0): Batch processing caps (default 50 records per run) with immediate abandonment for permanent failures. This prevents runaway processing time while ensuring the backlog drains steadily.