UAT Test Plan — BC Dialing Application

Field	Value
Version	1.0
Date	March 4, 2026
Project	Bestway BC Development
Environment	Business Central Sandbox

warning

This test plan covers the v2.2.0.0 release of the BC Dialing Application. Testing requires access to the Nextiva sandbox environment and the Azure Function that forwards call/email events to the BC API endpoints. Coordinate with the infrastructure team to confirm the Azure Function is pointed at the BC sandbox before beginning tests. The ECOMMERCE customer template must exist in the sandbox.

Overview

This test plan validates the BC Dialing Application extension for Microsoft Dynamics 365 Business Central. The extension integrates Nextiva phone and email events with BC Customer records. When an incoming call or email arrives, the extension looks up the Customer by phone number or email address. If no match is found, it creates a new Customer from the ECOMMERCE template and returns a URL to the Customer Card. A background Job Queue entry asynchronously syncs call summaries, recordings, and transcripts from the Nextiva Analytics API to Azure Blob Storage, linking each artifact to the Customer record.\n\nThis plan covers the v2.2.0.0 changes: removal of LockTable(), Insert(true) for proper customer setup, placeholder name on new customers, Customer No. population for existing customers, SetLoadFields separation, and Job Queue query optimization.

Extension Object Summary

Object	ID	Extends	Purpose
API Page	80000	CustomerPhoneLog	Receives incoming phone call events. Looks up or creates Customer by Phone No.
API Page	80001	CustomerPhoneLog	Receives call-end events with Nextiva session ID for async processing.
API Page	80003	CustomerEmailLog	Receives incoming email events. Looks up or creates Customer by E-Mail.
Codeunit	60003	N/A	Job Queue processor — syncs summaries, recordings, transcripts, and emails from Nextiva to Azure Blob Storage.
Table Extension	60000	Customer	Secondary indexes on Phone No. and E-Mail for efficient lookups.

Prerequisites

• The BC Dialing Application extension v2.2.0.0 is published to the sandbox environment.
• The ECOMMERCE customer template exists in the sandbox with a valid No. Series.
• The Azure Function forwarding Nextiva events is configured to point at the sandbox BC instance.
• A test phone number and test email address are available that do NOT match any existing Customer records (for new-customer tests).
• A test phone number and test email address are available that DO match existing Customer records (for existing-customer tests).
• The Nextiva sandbox environment is accessible and can generate test call/email events.
• A Job Queue entry for CU-60003 is configured in the sandbox (can be run manually for testing).
• The tester has access to the Customer Card, Customer Phone Log Viewer (Page 80005), Customer Email Log Viewer (Page 80006), and Nextiva Error Logs (Page 80008).

Test Area 1: Incoming Phone Call — New Customer

Requirement: When an incoming call arrives for an unknown phone number, the extension creates a new Customer from the ECOMMERCE template and returns the Customer Card URL.

Verify that the API page correctly creates a new Customer with the expected defaults and returns the correct URL and Customer No.

TC-1.1: New Customer Created from Phone Call

Step	Action	Expected Result
1	Trigger an incoming call event from the test phone number that does not match any existing Customer.	The API call returns successfully (HTTP 201).
2	Inspect the API response body.	The response includes a customerurl field containing a URL to the Customer Card and a customernum field containing the new Customer No.
3	Open the Customer Card using the returned URL.	The Customer Card opens. The Customer has Name = 'New Customer' and Phone No. matching the test phone number.

TC-1.2: ECOMMERCE Template Defaults Applied

Step	Action	Expected Result
1	On the Customer Card from TC-1.1, inspect the posting group fields (Gen. Bus. Posting Group, Customer Posting Group, etc.).	All posting group fields match the defaults defined in the ECOMMERCE customer template.
2	Inspect the Payment Terms Code and other template-driven fields.	All template-driven fields are populated with the ECOMMERCE template defaults.
3	Confirm the Phone No. field.	Phone No. matches the incoming call's phone number — it was not overwritten by the template.

TC-1.3: Phone Log Record Created

Step	Action	Expected Result
1	Open the Customer Phone Log Viewer (Page 80005).	The phone log list is visible.
2	Locate the log record for the test phone number.	A record exists with the correct Phone Number and Customer No. matching the newly created Customer.

Test Area 2: Incoming Phone Call — Existing Customer

Requirement: When an incoming call arrives for a phone number that matches an existing Customer, the extension returns the URL without creating a new Customer.

Verify that the API page finds the existing Customer and populates the Customer No. on the log record.

TC-2.1: Existing Customer Found by Phone Number

Step	Action	Expected Result
1	Trigger an incoming call event from the test phone number that matches an existing Customer.	The API call returns successfully (HTTP 201).
2	Inspect the API response body.	The customerurl field contains a URL pointing to the existing Customer Card. The customernum field contains the existing Customer's No.
3	Verify no new Customer was created.	The Customer count has not increased. No new 'New Customer' record exists.

TC-2.2: Customer No. Populated on Phone Log Record

Step	Action	Expected Result
1	Open the Customer Phone Log Viewer (Page 80005).	The phone log list is visible.
2	Locate the log record created by the call in TC-2.1.	The record's Customer No. field contains the existing Customer's No. — it is not blank.

Test Area 3: Incoming Email — New Customer

Requirement: When an incoming email arrives for an unknown email address, the extension creates a new Customer from the ECOMMERCE template.

Verify the email API page follows the same customer creation logic as the phone page.

TC-3.1: New Customer Created from Email

Step	Action	Expected Result
1	Trigger an incoming email event from a test email address that does not match any existing Customer.	The API call returns successfully (HTTP 201).
2	Inspect the API response body.	The response includes customerurl and customernum fields.
3	Open the Customer Card using the returned URL.	The Customer has Name = 'New Customer' and E-Mail matching the test email address. ECOMMERCE template defaults are applied.

TC-3.2: Email Log Record Created with Customer No.

Step	Action	Expected Result
1	Open the Customer Email Log Viewer (Page 80006).	The email log list is visible.
2	Locate the log record for the test email.	A record exists with the correct Email Address and Customer No. matching the newly created Customer.

Test Area 4: Incoming Email — Existing Customer

Requirement: When an incoming email arrives for an email address that matches an existing Customer, the extension returns the URL without creating a new Customer.

Verify that existing customer lookup and Customer No. population work for email.

TC-4.1: Existing Customer Found by Email

Step	Action	Expected Result
1	Trigger an incoming email event from a test email address that matches an existing Customer.	The API call returns successfully (HTTP 201).
2	Inspect the API response body.	The customerurl points to the existing Customer Card. The customernum contains the existing Customer's No.
3	Open the Customer Email Log Viewer. Locate the record.	The record's Customer No. field contains the existing Customer's No.

Test Area 5: Concurrent Access — No Lock Contention

Requirement: Incoming calls and emails must not block CS agents from editing or creating Customer records.

Verify that the removal of LockTable() allows concurrent Customer operations without errors.

note

These tests require two simultaneous sessions: one triggering API calls and one manually editing Customer records. Coordinate timing so that the Customer Card edit is in progress while the API call is being processed.

TC-5.1: Edit Customer Card During Incoming Call

Step	Action	Expected Result
1	Open a Customer Card in session A and begin editing a field (e.g., Name or Address).	The Customer Card is open and editable.
2	While session A has the Customer Card open, trigger an incoming call event in session B.	The API call completes successfully. No error is returned.
3	Return to session A and save the Customer Card.	The save completes without error. No 'information on this page is out of date' message appears.

TC-5.2: Create New Customer During Incoming Call

Step	Action	Expected Result
1	Begin creating a new Customer manually in session A (open a new Customer Card).	A new Customer Card is open for input.
2	While session A is filling in the new Customer, trigger an incoming call event in session B.	The API call completes successfully.
3	Complete and save the manually-created Customer in session A.	The insert completes without lock conflict or error.

Test Area 6: Job Queue Processing

Requirement: The Job Queue processor (CU-60003) asynchronously syncs call summaries, recordings, and transcripts from the Nextiva API to Azure Blob Storage.

Verify that pending phone and email log records are processed correctly by the Job Queue.

TC-6.1: Pending Phone Log Records Processed

Step	Action	Expected Result
1	Trigger one or more incoming calls that create phone log records with Nextiva session IDs.	Phone log records exist with SummaryUpdated = false, TranscriptUpdated = false, RecordingUpdated = false.
2	Run the Job Queue entry for CU-60003 (or wait for the next scheduled cycle).	The Job Queue completes without error.
3	Open the Customer Phone Log Viewer (Page 80005) and inspect the processed records.	SummaryUpdated, TranscriptUpdated, and RecordingUpdated are all set to true. The Attempts field has been incremented.
4	Open the matched Customer Card and inspect the Record Links.	Record Links exist for the summary, recording, and transcript — each pointing to an Azure Blob Storage URL.

TC-6.2: Pending Email Log Records Processed

Step	Action	Expected Result
1	Trigger one or more incoming emails that create email log records with Nextiva session IDs.	Email log records exist with InboundEmailUpdated = false and OutboundEmailUpdated = false.
2	Run the Job Queue entry for CU-60003.	The Job Queue completes without error.
3	Open the Customer Email Log Viewer (Page 80006) and inspect the processed records.	InboundEmailUpdated and OutboundEmailUpdated are set to true. The Attempts field has been incremented.

TC-6.3: Records with 3+ Attempts Are Skipped

Step	Action	Expected Result
1	Identify or create a phone log record with Attempts >= 3 and at least one sync flag still false.	The record exists with Attempts >= 3.
2	Run the Job Queue entry for CU-60003.	The Job Queue completes.
3	Inspect the record after processing.	The record was NOT processed — its sync flags and Attempts counter are unchanged from step 1.

TC-6.4: Attempt Counter Incremented on Each Cycle

Step	Action	Expected Result
1	Note the current Attempts value on a pending phone log record (should be 0 or 1).	The starting Attempts value is documented.
2	Run the Job Queue entry for CU-60003.	The Job Queue completes.
3	Inspect the Attempts field.	Attempts has been incremented by 1 from the starting value.

Test Area 7: Customer Template Application

Requirement: New customers created by the API pages must have the ECOMMERCE template defaults applied and retain the incoming phone number or email address.

Verify that the customer creation flow correctly applies the template without overwriting the contact information.

TC-7.1: ECOMMERCE Template Defaults Present on New Customer

Step	Action	Expected Result
1	Trigger an incoming call for a new phone number.	A new Customer is created.
2	Open the new Customer Card and inspect the Gen. Bus. Posting Group field.	The value matches the ECOMMERCE template's Gen. Bus. Posting Group setting.
3	Inspect the Customer Posting Group field.	The value matches the ECOMMERCE template's Customer Posting Group setting.
4	Inspect the Payment Terms Code field.	The value matches the ECOMMERCE template's Payment Terms Code setting.

TC-7.2: Phone Number Preserved After Template Application

Step	Action	Expected Result
1	Using the Customer created in TC-7.1, inspect the Phone No. field.	Phone No. matches the incoming call's phone number — it was NOT overwritten by the template application step.

TC-7.3: Email Preserved After Template Application

Step	Action	Expected Result
1	Trigger an incoming email for a new email address.	A new Customer is created.
2	Open the new Customer Card and inspect the E-Mail field.	E-Mail matches the incoming email address — it was NOT overwritten by the template application step.

Test Area 8: Error Handling

note

This test requires temporarily renaming or deleting the ECOMMERCE customer template. Restore it immediately after the test.

TC-8.1: Missing ECOMMERCE Template

Step	Action	Expected Result
1	Temporarily remove the ECOMMERCE customer template from the sandbox.	The template is not findable by the Get() call.
2	Trigger an incoming call for a new phone number.	The API call returns an error (the specific error depends on BC's Get() failure behavior).
3	Restore the ECOMMERCE template.	The template is back in place.
4	Trigger another incoming call for the same phone number.	The API call succeeds — a new Customer is created normally.

TC-8.2: Job Queue Error Logging

Step	Action	Expected Result
1	Create a phone log record with an invalid or expired Nextiva session ID.	The record exists and is pending processing.
2	Run the Job Queue entry for CU-60003.	The Job Queue completes (the error is caught by the TryFunction wrapper).
3	Open the Nextiva Error Logs (Page 80008).	An error log entry exists for the failed record, showing the source No., session ID, and error message.
4	Verify the phone log record's Attempts counter was incremented.	Attempts increased by 1 despite the failure — the record will be retried up to the 3-attempt limit.