Daniel Göhler prisma informatik GmbH

It would be great if the "Run Once (foreground)" action for Job Queue Entries also displayed stack trace details when an error occurs. Currently, I need to run the same codeunit via a URL parameter to see the error stack. Showing the stack trace directly in the "Run Once (foreground)" output would simplify debugging and make error diagnostics more efficient.

Multilingual email templates for document distribution are frequently requested by customers, as multilingual support is standard in many areas of Business Central. Requirement: Enable configuration of email subject and body texts per document type and language, similar to the existing approach for reminders, so that the correct text is automatically selected based on the recipient’s language when sending documents.

Description / Problem Statement

Microsoft 365 Copilot has access to Microsoft 365 tenant data through the Semantic Index, but Dynamics 365 Business Central data is currently excluded.

Business Central contains highly valuable business data such as customers, vendors, items, sales documents, financial KPIs, and operational insights. The lack of native integration significantly limits the usefulness of Microsoft 365 Copilot for business users who rely on Business Central as their core ERP system.

Proposed Solution

If a native integration between Business Central and the Microsoft 365 Copilot Semantic Index is not feasible in the short term, Microsoft should provide a default, out‑of‑the‑box Microsoft Graph / Copilot connector for Business Central that:

• Can be enabled by administrators with minimal configuration
• Indexes relevant Business Central entities securely and permission‑aware
• Integrates directly into the Microsoft 365 Copilot Semantic Index
• Works with Microsoft 365 Copilot Chat at the same performance and intelligence level as other M365 data sources

Admin entry point example:

https://admin.cloud.microsoft/?#/copilot/connectors

Why Copilot Studio Is Not a Sufficient Alternative

While it is technically possible to access Business Central data using Copilot Studio, this approach has several major limitations:

• Query performance is significantly slower compared to the Semantic Index
• Responses are not as context‑aware, intelligent, or reliable
• Prompt execution is inconsistent and often does not follow instructions correctly
• The experience is clearly inferior to Microsoft 365 Copilot using the GPT‑5.2 model
• Higher implementation and maintenance effort for customers

As a result, Copilot Studio does not provide a comparable user experience to Microsoft 365 Copilot with native Semantic Index access.

Business Value

A native or default connector would enable scenarios such as:

• “What are our current open sales orders and risks?”
• “Summarize overdue customers and their outstanding amounts.”
• “Which items have low availability and high sales volume?”
• “Give me a financial overview for this month based on Business Central data.”

This would dramatically increase the value of both Business Central and Microsoft 365 Copilot for decision‑makers and operational users.

Summary

Business Central is a critical system of record and should be treated as a first‑class data source for Microsoft 365 Copilot.

A native integration or an official out‑of‑the‑box connector for the Semantic Index would unlock enormous productivity and insight potential for customers.

Today, we tested the Copilot Chat integration in Microsoft Dynamics 365 Business Central and compared it side by side with Microsoft 365 Copilot. The difference in quality and performance was like night and day.

The Copilot Chat in Business Central, especially when used for documentation-related questions, is extremely slow. The responses often do not match the question well, lack intelligence, or are not very helpful. In some cases, Copilot Chat either responds with “I don’t know” or returns an error.

In contrast, when we asked the same questions in Microsoft 365 Copilot, the responses were immediate, well-articulated, and consistently relevant. We explicitly included “Business Central” in the questions so Microsoft 365 Copilot clearly understood the context. The quality of the answers was significantly better and always aligned with the intent of the question.

Therefore, we strongly recommend improving the answer quality, intelligence, and response time of Copilot Chat in Business Central so that it matches the level of Microsoft 365 Copilot.

Alternatively, integrating Microsoft 365 Copilot directly into Business Central would be a highly effective solution.

Problem statement

In wholesale scenarios, the Item No. is often only an internal system identifier.

Customers, sales, and purchasing primarily work with:

• Manufacturer Code
• Manufacturer Item No.

In our solution, the Item table is extended with:

• Manufacturer Code
• Manufacturer Item No.

The Sales Line is also extended accordingly.

For our customers, the combination of Manufacturer Code + Manufacturer Item No. is the business‑relevant key, while the internal Item No. is irrelevant.

Current limitation

We attempted to surface this information in the “SOA Multi Items Availability” page.

However:

• The page is not extensible
• We therefore added it via customizations to the Sales Order Agent role center
• Despite this, the Sales Order Agent does not understand or use this information

Example user request the agent fails to handle correctly:

Hello, I require a quotation for a lamp with the manufacturer part number 2721 from manufacturer BOSCH.

The agent appears to rely strictly on Item No.‑based logic and ignores manufacturer‑based identification, even though this data is available in the system.

Assumed root cause

The Sales Order Agent likely operates with strict internal rules and a fixed prompt, defining:

• Which tables
• Which fields
• Which identifiers

are considered during interpretation and execution.

Since:

• The prompt is not visible
• The agent cannot be extended
• Prompt events are not exposed, even with Agent Playground enabled

there is currently no way to teach the agent that Manufacturer Code + Manufacturer Item No. is a valid and primary item identifier in wholesale scenarios.

Requested improvements / ideas

1. Extensibility of the Sales Order Agent

• Allow partners and ISVs to extend:
• Recognized identifiers
• Field mappings
• Item resolution logic

2. Prompt visibility or extension hooks

• Similar to Agent Playground, but for system agents
• At least allow registering:
• Additional semantic keys
• Alternate item lookup rules

3. Ability to clone the Sales Order Agent

• Copy the default agent
• Customize the prompt and behavior
• Keep access to:
• Mailboxes
• Sales documents
• Business Central context

4. Mailbox access for custom agents

• Currently, custom Agent Playground agents cannot access mailboxes
• This is a blocker if the default agent cannot be extended

Business value

Without this extensibility:

• Wholesale customers cannot use the Sales Order Agent effectively
• Real‑world item identification (manufacturer‑based) is ignored
• Partners are forced into fragile workarounds or cannot adopt the agent at all

Making the Sales Order Agent extensible would significantly increase its adoption, accuracy, and industry relevance, especially in wholesale and manufacturing scenarios.

Technical context & reasoning (additional, optional section)

This part is not part of the idea text, but helps explain why your assumption is very likely correct:

• The Sales Order Agent is almost certainly:
• Prompt‑driven
• Backed by fixed semantic mappings
• Restricted to a known schema (Item No., Variant, etc.)
• If Manufacturer Item No. is not part of:
• The retrieval schema, or
• The tool function definitions
• then the LLM literally cannot reason with it, even if it exists on pages.
• UI customizations alone don’t help, because:
• Agents operate on data contracts, not UI
• Non‑extensible pages = non‑extensible agent context

Your proposal is therefore architecturally sound and not a misunderstanding.

We are currently testing the Agent Playground, which is a great and promising tool for building agents that we can provide to our customers. However, there are two major limitations that are currently holding us back.

1. Agent performance and speed

The overall execution speed of Business Central Agents is very very slow. Compared to Microsoft 365 Copilot, ChatGPT, or agentic tools such as Claude Code, Codex, or even OpenClaw, Business Central Agents feel significantly slower taking minutes—even when executing a single tasks with no other tasks in the system.

We tested several scenarios to better understand the behavior, such as:

• Time registration
• Customer duplicate checks

In all cases, the response time was noticeably slower than expected, which negatively impacts usability and user confidence.

2. Missing interactive response capabilities

During our tests, we observed that the underlying LLM asks follow-up questions, but there is currently no interface that allows the user to respond to these questions.

At the moment:

• The agent cannot request a simple Yes/No confirmation.
• For more complex tasks (e.g., time registration), there is no way to enter additional required information interactively.
• The only possible interaction is to start a completely new task, which breaks the natural flow of the conversation.

It would be a major improvement if agents could:

• Ask questions and allow direct written responses
• Support simple confirmation dialogs (Yes/No)
• Request structured input for complex tasks

An even better experience would be native UI support for lookups. For example:

• During time registration, the agent could prompt for Job and Job Task
• The Job Task lookup should automatically be filtered based on the previously selected Job

This kind of guided, context-aware interaction would make Business Central Agents far more powerful, intuitive, and competitive with other modern agent platforms.

In wholesale scenarios, the Item No. is often only an internal system identifier.

Customers, sales, and purchasing primarily work with:

• Manufacturer Code
• Manufacturer Item No.

In our solution, the Item table is extended with:

• Manufacturer Code
• Manufacturer Item No.

The Sales Line is also extended accordingly.

For our customers, the combination of Manufacturer Code + Manufacturer Item No. is the business‑relevant key, while the internal Item No. is irrelevant.

The scenario would be to pass some manufacturer part numbers from a CSV order file (manufacturer part number; quantity) to the Copilot line suggestion for sales lines, so that they can then be transferred into a sales order or a quote.

However, this also does not work, because the relevant table SalesLineAISuggestions.Table.al in the SalesLinesSuggestions app is marked as Internal and is therefore not extensible.

In addition, there do not seem to be any events available to intervene in the search in Search.Codeunit.al—although I might be overlooking something.

It would be nice if it were extensible.