[Bug Fix] #304: [SOA] Re-resolve new sender to created contact after 'I have added the contact'

[ventselartur]

Bug Reference

Work item microsoft/BCAppsBugFix#304

Fixes microsoft/BCAppsBugFix#304

Fixes AB#615541

Summary

Sales Order Agent (SOA) failed to recover when an email arrived from a new/unrecognized sender: after the user created the contact from the agent chat and confirmed with the "I have added the contact" suggestion, the agent still reported that it could not find the customer. This fix strengthens the intervention instruction so the agent re-resolves the sender starting from the contact list after the contact is created, instead of remaining in the stale customer-list context.

Root Cause

The AL data resolution is already correct: AgentTaskMessage.From and the newly created contact's "E-Mail" both come from EmailInbox."Sender Address", so GetSecurityFiltersForContacts (codeunit 4305 "SOA Filters Impl.") finds the new contact on re-resolution, and a contact without a linked customer is already supported (SetFilterOnSalesHeader in codeunit 4306 falls back to the "Sell-to Contact No." filter; quote creation uses customer templates).

The defect was in the agent's continuation behavior, driven by the SOA-CONTACT-ADDED intervention instruction text (SOAContactInterventionSuggestionInstructionsLbl in SOASetup.Codeunit.al). It only said "Rerun the contact information check on the contact list page and proceed further" and did not explicitly command the agent to navigate back to the contact list and search again before concluding. When the assistance request had been raised from the Customer List page, the agent stayed in that stale context after the contact was created and re-reported "can't find the customer".

Changes Made

• src/Apps/W1/SalesOrderAgent/app/src/Setup/SOASetup.Codeunit.al: Reworded the SOAContactInterventionSuggestionInstructionsLbl label (Locked = true, MaxLength = 1024 unchanged) to explicitly instruct the agent to navigate to the contact list page, search for the contact again, proceed with the contact if found, and only fall back to the customer list if the contact is still not found. This is the only source change.

Implementation Process

• Fix iterations: Not applicable - tests not required
• Compilation: ✅ All projects compile successfully
• Publish: ✅ Modified app published successfully
• Validation: Tests not required by the approved plan

Validation Evidence

No-Test Validation Evidence

• Tests required by plan: No
• Rationale: The defect only manifests through the live SOA agent runtime (inbound email → agent task → LLM interpreting the intervention instruction text → multi-turn user intervention/Continue navigation). The changed artifact is a Locked label consumed as natural-language guidance for the LLM, not deterministic AL branch logic. The underlying AL data resolution and security-filter logic were verified correct, so there is no deterministic AL defect for a red-to-green automated test, and there is no SOA test project in the repository. Reproducing the symptom requires the external email system and the agent/LLM runtime, which the AL test environment cannot control.
• Compilation: ✅ All modified projects compiled successfully
• Publish: ✅ Modified app published successfully
• Manual/external validation approach: With SOA configured so input reviews are not required, send an email from a new sender, use the chat link to create the contact, select "I have added the contact", click Continue, and confirm the agent re-resolves to the newly created contact and proceeds (creates the sales quote/order) instead of reporting it cannot find the customer.

Validation Coverage

• Automated tests: Not applicable per approved Test Strategy
• Build and publish validation completed
• Manual/external validation: Run the 6-step repro from the issue with input reviews disabled and confirm the agent proceeds after the contact is created
• Regression testing: Confirm normal (recognized-sender) contact/customer resolution and security filtering are unaffected

Miapp Propagation

• Layers propagated to: None - the fix touched no propagated path
• Files changed by propagation: 0
• VerifyMiappSync: ✅ No files still need to be integrated

Review Notes

The change is limited to a single agent-instruction label string. Reviewers should focus on the wording of the new instruction to confirm it unambiguously directs the agent to re-resolve from the contact list first and only fall back to the customer list when the contact is still not found.

🤖 Generated by the bc-fix-bug skill

---

Promoted from microsoft/BCAppsBugFix#313: https://github.com/microsoft/BCAppsBugFix/pull/313

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept with Suggestions

What this PR does

This changes the SOA contact-added intervention instruction so the agent returns to the Contact List page, searches for the new contact, proceeds if found, and only then falls back to the Customer List page. That matches the failing flow: after a user creates a contact for a new email sender, the agent must re-resolve contact/customer state instead of staying in stale customer-list context.

The AL filtering code already finds contacts by sender email, and Sales Header filtering can use Sell-to Contact No. when no customer exists. This label change therefore targets the right control point, keeps the existing label limits, and does not alter runtime data filters.

Problem-solution fit

Fit: Strong

The bug says the failure happens after selecting the contact-added response and continuing. The diff directly changes that response's instruction and makes the contact-first re-resolution order explicit, so the solution fits the described failure without broadening behavior.

Suggestions

S1 (🟠 Moderate): Complete the live agent validation
This change depends on how the agent follows the new instruction. Run the full new-sender flow once before merging, and confirm it finds the created contact after Continue. A build cannot prove this behavior.

Risk assessment and necessity

Risk: This is a narrow change to one locked instruction label used by both Customer List and Contact List assistance. The main regression surface is the SOA intervention flow for new senders: unclear wording could still send the agent to the wrong page, but it does not change filters, posting, or customer/contact data.

Necessity: The change is necessary because first-time senders can otherwise stay blocked after the user creates the contact. The scope is right for the reported failure: it changes only the instruction that drives the continuation behavior.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=10772 round=1 by=alexei-dobriansky at=2026-08-28T12:17:02Z lastSha=26d149a89913ba9a2ddc7b447a2b6f67ac75804a reviewKey=6112b02d23a6e075f551a981d3a127c6bb575e23a97ca00a0f19786065a17126 suggestions=S1@cd3f5ee9

[github-actions]

⚠️ Stale Status Check Deleted

The Pull Request Build workflow run for this PR was older than 72 hours and has been deleted.

📋 Why was it deleted?

Status checks that are too old may no longer reflect the current state of the target branch. To ensure this PR is validated against the latest code and passes up-to-date checks, a fresh build is required.

---

🔄 How to trigger a new status check:

1. 📤 Push a new commit to the PR branch, or
2. 🔁 Close and reopen the PR

This will automatically trigger a new Pull Request Build workflow run.

[attilatoury]

Should we manually validate?

[github-actions]

⚠️ Stale Status Check Deleted

The Pull Request Build workflow run for this PR was older than 72 hours and has been deleted.

📋 Why was it deleted?

Status checks that are too old may no longer reflect the current state of the target branch. To ensure this PR is validated against the latest code and passes up-to-date checks, a fresh build is required.

---

🔄 How to trigger a new status check:

1. 📤 Push a new commit to the PR branch, or
2. 🔁 Close and reopen the PR

This will automatically trigger a new Pull Request Build workflow run.