Skip to main content

Changelog

All notable changes to the BC Dialing Application extension are documented in this file. For detailed change documents, see the linked files below. For the full performance investigation timeline (v2.0.0.12 through v2.3.0.0), see INVESTIGATION-Performance-Locking.md.

[2.4.0.0] - 2026-03-11​

Change Document: CHANGE-v2.4.0.0.md

Fixed​

  • Widened AssetType (Text[20] → Text[100]) on NextivaData, PhoneNumber (Text[20] → Text[50]) on CustomerPhoneLog, EmailAddress (Text[20] → Text[250]) on CustomerEmailLog, and error log fields on Nextiva Error Logs — string length constraint errors were blocking recording and transcript sync
  • Migrated UseReadySAS from deprecated Text to SecretText parameter type in CU-60003 and CU-60004 — eliminates AL0432 compiler warnings and prevents SAS token from appearing in runtime logs
  • Eliminated double Get() + Modify(true) on the success path — attempt increment folded into UpdateAllPhoneLogFlags and UpdateAllEmailLogFlags, saving 100 DB operations per 50-record batch

Added​

  • Configurable batch cap for Job Queue processing (Max Phone Logs Per Run, Max Email Logs Per Run on NextivaConfig, default 50) — prevents unbounded processing runs, token expiry mid-run, and cascading failures during backlog drain (ISSUE-15)
  • Immediate abandonment for permanent failures — "Customer Not found" errors set Attempts = 3 immediately instead of burning through 3 retries, freeing queue capacity for recoverable records
  • Batch cap fields exposed on NextivaConfigAPI page for monitoring visibility
  • New telemetry events: BCDIALER-1002 (batch cap reached), BCDIALER-5002 (permanent failure abandonment)
  • BCDIALER-1000 startup telemetry now includes batch cap configuration values

Changed​

  • Job Queue Settings group added to Nextiva Config Setup page (80007) with both batch cap fields

Migration Notes​

  • Upgrade codeunit (CU-60005) automatically sets batch cap defaults to 50 during upgrade
  • Adjust batch cap values via the Nextiva Config Setup page (80007) if needed — higher values drain backlogs faster but increase run duration and token expiry risk

[2.3.6.0] - 2026-03-09​

Change Document: CHANGE-v2.3.6.0.md

Added​

  • TryInsertCustomer [TryFunction] diagnostic wrapper around NewCust.Insert(true) on Pages 80000 (ReceivePhoneNumber) and 80003 (ReceiveEmail) — catches NavPermissionException before it unwinds the call stack, logs the exact failing object and permission type as BCDIALER-0021 to Application Insights, then re-raises to preserve HTTP 403 behavior for the Nextiva caller. Post-v2.3.5.0 telemetry shows live Nextiva calls still 403ing at 50–75% while integration tests succeed — the integration test authenticates as BestwayBCAPI (D365 Full Access), masking the Nextiva service account's actual permission context. BCDIALER-0021 will identify whether the remaining failure is a codeunit EXECUTE permission, a BC SaaS entitlement restriction, or an additional table not yet in the 34-table inline Permissions list. (ISSUE-12 diagnostic)

[2.3.5.0] - 2026-03-09​

Change Document: CHANGE-v2.3.5.0.md

Fixed​

  • Added Dimension table (BC table 348) to Pages 80000 (ReceivePhoneNumber), 80003 (ReceiveEmail), and CU-60000 (PhoneIntegration) inline Permissions — DefaultDimension.Insert(true) during CopyDefaultDimensionsFromTemplate (called inside ApplyCustomerTemplate) validates Dimension Code against the Dimension table via BC ORM TableRelation enforcement; this table access is invisible to static AL code analysis and was the final missing permission causing 100% HTTP 403 NavPermissionException on new customer creation after v2.3.4.0. Permission total is now 34. (CRITICAL — ISSUE-12 final fix)

[2.3.4.0] - 2026-03-09​

Change Document: CHANGE-v2.3.4.0.md

Fixed​

  • Added 13 remaining Customer Templ. field tables to Pages 80000 (ReceivePhoneNumber), 80003 (ReceiveEmail), and CU-60000 (PhoneIntegration) — covers every setup table accessed by Validate() triggers when ApplyCustomerTemplate runs for any standard BC Customer Template field (Customer Price Group, Tax Area, Payment Method, Shipment Method, Language, Finance Charge Terms, Territory, Customer Discount Group, Shipping Agent, Reminder Terms, Responsibility Center, Location, Post Code). v2.3.3.0 left these uncovered because the analysis traced the Nextiva API payload fields rather than the full template record; the BestwayUSA INVCSalesHandler.OnAfterInsertCustomer subscriber calls ApplyCustomerTemplate inside Insert(true), accessing all template fields, not just the ones the Nextiva system sends. Permissions total is now 33 — all standard Customer Templ. field table relations are covered. (CRITICAL — ISSUE-12 final fix)

[2.3.3.0] - 2026-03-09​

Change Document: CHANGE-v2.3.3.0.md

Fixed​

  • Added 5 missing table permissions to Pages 80000 (ReceivePhoneNumber), 80003 (ReceiveEmail), and CU-60000 (PhoneIntegration) — Salesperson/Purchaser, Payment Terms, Currency, Country/Region, and General Ledger Setup were accessed during new customer creation via ApplyCustomerTemplate field validation and BestwayUSA extension event subscribers but not declared in inline Permissions, causing HTTP 403 NavPermissionException on 65-74% of API calls (CRITICAL — ISSUE-12 root cause fix)
  • Standardized step 4 breadcrumb telemetry (BCDIALER-0020) to use Dictionary overload on Pages 80000 and 80003, matching all other breadcrumb steps

[2.3.2.0] - 2026-03-09​

Change Document: CHANGE-v2.3.2.0.md

Added​

  • Step-through breadcrumb telemetry (BCDIALER-0020) on Pages 80000 and 80003 — logs each stage of the OnInsertRecord trigger (config load, customer lookup, template get, InitCustomerNo, Insert, ApplyCustomerTemplate, Modify) with custom dimensions identifying the source page, step number, and contextual data (phone number, email, template name, customer number). When a 403 NavPermissionException aborts execution, the last breadcrumb logged pinpoints the exact operation that triggered the permission failure

[2.3.1.0] - 2026-03-09​

Change Document: CHANGE-v2.3.1.0.md

Added​

  • Screen pop URL telemetry (BCDIALER-0010) — logs the base URL template, customer number, and final generated URL on every inbound call and email screen pop across CU-60000, Page 80000, and Page 80003. Enables post-deployment diagnosis of screen pop failures without code changes or user interaction

[2.3.0.0] - 2026-03-06​

Change Document: CHANGE-v2.3.0.0.md

Fixed​

  • Restructured CU-60003 (Job Queue) to complete all HTTP I/O before any database writes — interleaved DB writes during Nextiva API calls and Azure Blob uploads held Customer table locks for 15-40 seconds per record, causing SQL lock timeouts (HTTP 409) and "information on the page is out of date" errors for CS agents (CRITICAL — Root Cause of Locking)
  • Eliminated 4 redundant Customer lookups per phone log record in CU-60003 — each of SaveSummary, SaveRecording, SaveTranscript, and AddCustomerBlobLink performed its own Customer FindFirst by phone number. Consolidated to a single lookup in TryProcessPhoneLog, with Customer "No." passed through the chain (HIGH)
  • Eliminated 4 redundant CustomerPhoneLog Modify calls per record in CU-60003 — UpdateNextiveEntryFlags was called 3 times (once per asset) plus UpdateAttempt, each performing a separate Get+Modify. Replaced with UpdateAllPhoneLogFlags (single Get+Modify for all three flags); UpdateAttempt remains a separate call. Total: 2 Get+Modify pairs instead of 4 (HIGH)
  • Page 80004 (EndMailCall) had empty OnInsertRecord trigger and commented-out SourceTableTemporary — incoming email end-of-call events created orphaned CustomerEmailLog records with blank Customer No. Added Customer email lookup matching EndCall (80001) pattern (MEDIUM)
  • CU-60000 (legacy PhoneIntegration) missing SetLoadFields on Customer lookup, missing Modify after ApplyCustomerTemplate (phone number lost after template application), missing inline Permissions for 13 standard BC tables (HIGH)
  • Manual Sync date-based path (Pag-80009) called CU-60003 legacy stubs that only uploaded blobs without writing Record Links or updating processing flags — records appeared unprocessed after manual sync (REGRESSION FIX)

Added​

  • Upgrade codeunit (CU-60005) auto-populates NextivaConfig table during deployment — eliminates manual pre-deployment configuration requirement
  • NextivaConfig API page (80010) for verifying config population via OData after deployment
  • Azure Blob SAS Token field on NextivaConfig table — SAS token now configurable instead of hardcoded in codeunits
  • Inline Permissions for CU-60000 covering all standard BC tables accessed by Customer creation flow

Changed​

  • All Nextiva API credentials (Login URL, AuthText) now read from NextivaConfig table instead of hardcoded values — CU-60003 reads in OnRun, CU-60004 reads via LoadConfig helper (CRITICAL — Security)
  • All hardcoded fallback branches now emit Session.LogMessage warnings (BCDIALER-0001 through BCDIALER-0003) to Application Insights when activated — fallback usage is immediately detectable in telemetry without breaking the integration
  • BC Base URL now read from NextivaConfig table with hardcoded fallback on Pages 80000, 80003, and CU-60000
  • Customer Template name now read from NextivaConfig table with 'ECOMMERCE' fallback on Pages 80000 and 80003
  • Azure Blob SAS token now read from NextivaConfig table with hardcoded fallback in CU-60003 and CU-60004
  • Manual Sync page (80009) date-based path now calls Phase 1 (FetchAndUpload*) + Phase 2 (WriteBlobLinks + UpdateFlags) directly instead of legacy stubs
  • Removed legacy Save* stubs from CU-60003 — dead code after Pag-80009 restructure
  • Updated BCDialerPermissions permission set with CU-60004, CU-60005, and Page 80010

Migration Notes​

  • Upgrade codeunit (CU-60005) automatically populates NextivaConfig during v2.3.0.0 deployment — no manual pre-deployment configuration needed
  • Existing manual NextivaConfig entries are preserved; upgrade only fills in empty fields
  • Verify config population post-deployment via OData: GET /api/CambaySolutions/PhoneIntegration/v1.0/nextivaConfigs
  • Hardcoded credential fallbacks remain in the code as a transitional safety net — see CHANGE-v2.3.0.0.md (Credential Migration) for the complete inventory. These fallbacks should be removed in v2.4.0.0 after confirming the config-driven approach works in production
  • A deployment verification script (tools/verify_deployment.py) is available to validate config population and external connectivity end-to-end

[2.2.1.0] - 2026-03-05​

Change Document: CHANGE-v2.2.1.0.md

Fixed​

  • Added inline permissions for 13 standard BC tables accessed by Insert(true) and ApplyCustomerTemplate on Pages 80000 and 80003 — missing permissions caused 65-77% of incoming API calls to fail with HTTP 403 NavPermissionException after v2.2.0.0 deployment (CRITICAL)
  • Set SourceTableTemporary = true on Page 80003 (ReceiveEmail) to match Page 80000 — inconsistency caused wider transaction scope on email page, contributing to SQL lock timeout errors (HTTP 409)

[2.2.0.0] - 2026-03-04​

Change Document: CHANGE-v2.2.0.0.md

Fixed​

  • Removed LockTable() on Customer table in Pages 80000 and 80003 — exclusive table lock from every incoming call caused "information on the page is out of date" errors for CS agents editing or creating customers (CRITICAL)
  • Changed Insert() to Insert(true) on new Customer records in Pages 80000 and 80003 — skipped OnInsert trigger bypassed standard BC customer setup (No. Series validation, default field population)
  • Added placeholder Name (New Customer) on API-created customers in Pages 80000 and 80003 — blank Name fields made new customers unidentifiable in lists and lookups
  • Separated read-only Customer lookup from Customer creation into distinct record variables in Pages 80000 and 80003 — SetLoadFields optimization was persisting into Insert/Modify operations, risking partial field loading during template application or trigger execution
  • Customer No. field not populated on phone/email log records when an existing customer is found — only set when a new customer was created (Pages 80000 and 80003)
  • Customer No. field not populated on EndCall log records (Page 80001) — FindFirst() return value was discarded, making every EndCall log record untraceable to a Customer without re-querying by phone number
  • Eliminated duplicate FindFirst() call in AddCustomerBlobLink (CU-60003 and CU-60004) — original code called FindFirst() twice, wasting a database round-trip
  • Added missing filter fields ("Phone No.", "E-Mail") to SetLoadFields calls in LogError procedures (CU-60003 and CU-60004) — filter fields should be included in the load list for clarity and correctness
  • Switched Job Queue queries in CU-60003 from SetCurrentKey("No.") to the new ProcessingStatus secondary keys — the original primary key override prevented the new indexes from being used, making them dead weight with write overhead but no read benefit

Added​

  • Secondary key ProcessingStatus on CustomerPhoneLog (Tab80000) for efficient filtering by sync status fields
  • Secondary key ProcessingStatus on CustomerEmailLog (Tab80002) for efficient filtering by sync status fields
  • Secondary index on Customer table Phone No. field for efficient phone number lookups across the extension (TabExt-60000)
  • Secondary index on Customer table E-Mail field for efficient email lookups across the extension (TabExt-60000)
  • SetLoadFields optimizations on Customer table lookups across Pages 80000, 80001, 80003 and Codeunits 60003, 60004 — reduces data transferred from database for read-only queries

Changed​

  • Phone number and email are now re-applied after ApplyCustomerTemplate as a defensive measure against future template changes overwriting the incoming contact info
  • Removed unused variable declarations and dead code across Pages 80000, 80001, 80003 and Codeunits 60003, 60004
  • Job Queue processing order in CU-60003 changed from newest-first (descending No.) to index-driven order (ProcessingStatus key) — processing order is not functionally significant for the sync batch

[2.1.0.0] - 2026-02-26​

Change Document: CHANGE-v2.1.0.0.md

Fixed​

  • Broke single long-running transaction in CU-60003 into per-record micro-transactions to eliminate Customer table lock contention during Job Queue processing (CRITICAL)
  • Added error isolation (TryFunction wrappers) so one failed record does not abort the entire sync batch
  • Fixed copy-paste bug in email log error logging that referenced phone log variables

Added​

  • Extension-level telemetry via Application Insights connection string in app.json
  • LockTable() concurrency guard on Pages 80000 and 80003 (subsequently removed in v2.2.0.0 — see above)

[2.0.0.12]​

Initial release by Cambay Solutions.