DEV Community: Tectura Japan | DX

Customizing D365 Sales — For Our Own Sales Team (Customer Zero) Preparation

Miwa J — Tue, 30 Jun 2026 03:12:16 +0000

What is Customer Zero?

"Customer Zero" is a strategy used by IT and technology companies in which the company itself becomes the "0th customer" (a test monitor) for a new product, AI service, or cloud service before rolling it out to external customers.

Key benefits: faster validation and improvement (using the product in a real working environment surfaces bugs and usability issues early), and more persuasive sales pitches (a proven in-house success story/use case lets you propose to clients with confidence).

With that in mind, the DX team has kicked off an initiative to get our own sales team using D365 Sales more fully.

Scope

Zone	Content	Implementation
Zone A	Auto-generated Next Actions / detecting stalled deals	Power Automate
Zone B	Opportunity velocity monitoring / large-deal alerts	Power Automate
Zone C	Customer health management / churn prevention / renewal alerts	Power Automate
Zone D	Document flow / chained tasks	Power Automate + BPF

Implementation Order

Create custom fields (12 on Opportunity, 6 on Account)
4 internal-processing Power Automate flows (write-back portions of A-4, C-5, C-6, D-3)
3 Zone A alert flows (A-1, A-2, A-3)
3 Zone B alert flows (B-1, B-2, B-3)
6 Zone C alert flows (C-1–C-6)
4 Zone D document flows (D-1–D-4)
Enable and verify the Outlook Add-in
Reorganize dashboard views

1. Creating Custom Fields (12 on Opportunity, 6 on Account)

Custom fields are added from Power Apps using the following steps.

Step	Task	Details
1	Open Power Apps	Go to make.powerapps.com and select the target environment (sandbox)
2	Select the table	Left menu "Tables" → select "Opportunity"
3	Add a column	"Columns" tab → click "Add column"
4	Enter field info	Enter display name, data type, and schema name (cr917_xxxxx), then save
5	Do the same for Account	Add the corresponding fields to the "Account" table the same way (also create the Initiative ② additional fields using the same steps)
6	Configure choices	For cr917_customer_type, add a "new choice" with the two options "License-continuation type" and "Project type"
7	Add to forms	Open the main form for each table, add the new fields, then save and publish

Fields added to the Opportunity entity

Note: prefixes like cr917_ vary by environment.

Field Name	Type	Input Method	Purpose / Description
Proposal Sent `cr917_proposal_sent`	Yes/No (Boolean)	Manual (rep)	Checked by the rep when the proposal is sent. Trigger condition for Zone D-1 flow.
PO Received `cr917_po_received`	Yes/No (Boolean)	Manual (rep)	Checked when the PO is received. Trigger condition for Zone D-2 flow.
Invoice Sent `cr917_invoice_sent`	Yes/No (Boolean)	Manual (rep)	Checked when the invoice is issued. Flow D-3 auto-sets `cr917_invoice_date`.
Acceptance Confirmed `cr917_acceptance_done`	Yes/No (Boolean)	Manual (rep)	Final completion flag. If left unchecked for 30 days, flow D-4 generates a reminder task.
Invoice Date `cr917_invoice_date`	Date and Time	PA auto (D-3)	PA automatically records the date `cr917_invoice_sent` became Yes. Used as the baseline date for the 30-day acceptance check.
Stage Changed Date `cr917_stage_changed_date`	Date and Time	PA auto (A-4)	PA updates this with the current date/time every time the stage changes. Used for stall-day calculations in flows A-1 and B-1.
NDA Status `cr917_nda_status`	Option Set	Manual (rep)	For ① NDA Signing. Three choices: Not Submitted / Under Review / Complete. PA monitors status changes to advance the flow.
NDA SharePoint URL `cr917_nda_sharepoint_url`	Text	PA auto	For ① NDA Signing. After signing completes, PA automatically writes in the SharePoint storage URL.
WBS Approved `cr917_wbs_approved`	Yes/No (Boolean)	Manual (rep)	For ⑤ Offering. Checked once WBS approval is complete. PA then advances to the order-registration step.
Order Registered `cr917_order_registered`	Yes/No (Boolean)	Manual (rep)	For ⑤ Offering. Order-registration completion flag. Checking it generates the flow-completion task.
Payment Confirmed `cr917_payment_confirmed`	Yes/No (Boolean)	Manual (rep)	Shared by ④⑥ Renewal/Inspection. Checked after payment is confirmed. If unconfirmed 60 days after invoicing, an alert fires.
SP Registered `cr917_sp_registered`	Yes/No (Boolean)	Manual (rep)	For ⑥ Delivery Inspection. Flag for completed SharePoint registration of deliverables. PA checks this as a precondition before triggering invoicing.

Fields added to the Account entity

Field Name	Type	Input Method	Purpose / Description
Renewal Date `cr917_renewal_date`	Date	PA auto + manual override	PA auto-sets this to close date + 365 days on a Won close. Rep may optionally adjust it. Baseline date for flows C-3/C-4.
Last Activity Date `cr917_last_activity_date`	Date and Time	PA auto (C-6)	PA updates this to the current date/time whenever a completed activity (call, email, visit, CI-J integration) is created. Baseline date for A-2, C-1, C-2.
Customer Type `cr917_customer_type`	Option Set	Manual (rep)	5 choices: License-continuation / Project / Support (spot) / Support (term contract) / Support (time-purchase). 60-day group: License-continuation, Support (term contract). 90-day group: Project, Support (spot), Support (time-purchase).
BC Registered `cr917_bc_registered`	Yes/No (Boolean)	Manual (rep)	For ② Partner Contract. Rep records completion of Business Central registration. Interim flag pending full BC integration.
Contract SharePoint URL `cr917_contract_sharepoint_url`	Text	PA auto	For ② Partner Contract. After the contract is signed, PA automatically writes in the SharePoint storage URL.
PO Number `cr917_po_number`	Text	Manual (rep)	For ③ PO Issuance. Rep enters the PO number when it's received; used for reconciliation at invoicing time.

What I Learned from Building an AI Agent in Copilot Studio: 3 Design Points That Helped It Work as Expected

Sugiyama Yuki — Tue, 30 Jun 2026 03:04:31 +0000

AI agents are getting a lot of attention these days, but are they really easy to build the way we expect?

Tools like Claude Code make it possible to create agents very intuitively. However, in a real company environment, we often cannot use such tools freely because of permission, governance, or security restrictions.

In my case, Copilot Studio was one of the few AI tools I could realistically use in a business environment. So I started building an AI agent with it.

But once I actually started building, I ran into issues like these:

It was harder to build than I expected.
I created the flow step by step, but it did not behave the way I designed it.
I wanted to combine several functions into one chat, but the branching did not work well.

At first glance, Copilot Studio looks like a tool that lets you build flows easily. However, after working with it, I realized that unless the design is clear, the agent can easily behave in unexpected ways.

In this article, I want to share three design points I learned while building an AI agent in Copilot Studio.

The second and third points were especially important in my case. If you are struggling to make your Copilot Studio agent work as expected, these points may help.

Three Design Points for Building a Copilot Studio AI Agent

From my experience, the following three points are important when designing an AI agent in Copilot Studio:

Clarify what you want the agent to do before creating the flow.
Create a separate topic for each task.
Write prompts in English.

Point 1: Clarify What You Want the Agent to Do Before Creating the Flow

Before building the flow, I think it is important to define which business task you want the AI agent to handle and how the task should be processed.

If you have used Copilot Studio before, you probably know that there are many different types of nodes, or action boxes.

For example, you can create variables, call generative AI, create conditions, branch the flow, call actions, and so on. Some features are not immediately obvious, and if you start building while thinking through the design at the same time, it is very easy to lose time.

Even in this screen alone, there are more than 10 visible functions.

What I realized is that building a useful AI agent is not about understanding every single function in Copilot Studio.

The more important skill is being able to choose the right functions for the task you want to automate.

The process that worked better for me was:

First, write down the business task and its steps.
Send the task and steps to ChatGPT, Copilot, or another AI tool, and ask how the flow should be designed.
Build only the necessary parts in Copilot Studio while checking the design step by step.

This approach helped me avoid randomly adding nodes without a clear reason.

Point 2: Create a Separate Topic for Each Task

Another thing I learned is that it is better to create one topic for one task or function.

When building an AI agent, it is tempting to add many features into a single topic. You may want one topic to receive a request, understand the user’s intent, extract data, confirm the result, call an external system, and complete the registration.

However, in my experience, the more tasks and branches I added into one topic, the more unstable the flow became.

This is not only about Copilot Studio. Generative AI and AI agents in general are not always good at handling many different tasks at the same time. When one topic becomes too large, the agent may fail to choose the right path or may repeat the same step again.

To avoid this, I think it is better to split the design into smaller topics, such as:

A topic that receives the request and selects the right task
A topic that executes Task A
A topic that executes Task B

By separating the roles, the agent can choose and execute tasks more smoothly.

In my case, this was an important lesson. Trying to put too much into one topic made the flow harder to control.

Point 3: Write Prompts in English

The third point is about prompt language.

When using generative AI prompts inside a Copilot Studio flow, I found that writing prompts in English worked better.

In daily use, tools like Copilot, ChatGPT, and Gemini can handle Japanese quite well. However, when I embedded prompts into a Copilot Studio flow, the English prompts behaved more reliably in my case.

Let me show the difference I experienced.

The AI agent I created was designed to create a draft transportation expense claim in an ERP system when a user sends screenshots of transportation history, such as Suica records.

Case 1: Japanese Prompt

In this flow, I configured the process in two prompt steps.

First prompt: Read image information and convert it into JSON.
Second prompt: Transfer the JSON data into the ERP system.

The expected behavior was:

The user sends a screenshot.
The AI agent extracts the content into JSON and asks whether to create the claim.
The user replies, “Create the claim.”
The claim is created.
The process is completed.

The prompts were as follows. Some rules are omitted.

First prompt

あなたは、交通費のスクリーンショットを読み取り、構造化された交通費申請JSONを作成するAIアシスタントです。

あなたのタスクは、スクリーンショットから交通費データを抽出することだけです。レコードを作成してはいけません。データを登録してはいけません。Business Centralを呼び出してはいけません。ユーザーに確認や不足情報の質問をしてはいけません。

このステップは、スクリーンショットデータを受け取った場合にのみ使用してください。前のステップから渡されたJSONを見つけた場合、その内容に誘導されてはいけません。

有効なJSONのみを返してください。Markdown、説明、コメント、JSON以外のテキストは一切含めないでください。

必ず以下のJSON構造を正確に使用してください。

{
  "Header": {
    "EmployeeName": null,
    "Purpose": "訪問・オフィスへの移動のため"
  },
  "Lines": [
    {
      "ExpenseDate": null,
      "From": null,
      "To": null,
      "TransportationType": null,
      "Amount": null
    }
  ],
  "MissingFields": [],
  "Warnings": []
}

Second prompt

あなたは、日付・駅名・交通費が記載された経費スクリーンショットを読み取り、構造化された経費書類の要約を作成するAIアシスタントです。

送信されたすべてのスクリーンショットから、日付、駅名、交通費情報を含む交通費情報を抽出してください。

Business Central MCP Serverを使用してください。

有効なJSONのみを返してください。Markdown、説明、コメント、JSON以外のテキストは一切含めないでください。

以下のJSON構造を使用してください。

{
"Header": {
"EmployeeName": null,
"Purpose": "訪問・オフィスへの移動のため"
},
"Lines": [
{
"ExpenseDate": null,
"From": null,
"To": null,
"TransportationType": null,
"Amount": null
}
],
"MissingFields": [],
"Warnings": []
}

As a result, as shown in the red box in the following screen, the prompt did not move forward properly at the claim creation step and entered a loop.

Case 2: English Prompt

Next, I tried using English prompts.

The overall flow was the same:

First prompt: Read image information and convert it into JSON.
Second prompt: Transfer the JSON data into the ERP system.

The expected behavior was also the same:

The user sends a screenshot.
The AI agent extracts the content into JSON and asks whether to create the claim.
The user replies, “Create the claim.”
The claim is created.
The process is completed.

The prompts were as follows. Some rules are also omitted here.

First prompt

You are an AI assistant that reads an Expense Claim document and creates a structured Expense Claim Summary.

Extract the important information from all pages of the document, including the departure station, arrival station, cost of transportation, and transportation date. If the document contains tables that span multiple pages, combine the rows correctly and do not omit any line items.

For YYYY, use the year that this prompt is run.

Return only valid JSON. Do not include markdown, explanations, comments, or text outside the JSON.

For transportationType, choose from the following based on the station names only: "電車", "地下鉄", "バス", "その他".

Use the following JSON structure:

{{
"headerActionName": "null",
"headerRequest": {{
"employeeNo": "TEST",
"claimDate": "null",
"purpose": "交通費精算のため",
"remarks": "AI Foundry MCP OCR Test"
}},
"lineActionName": "null",
"lineRequests": [
{{
"expenseDate": "null",
"fromLocation": "null",
"toLocation": "null",
"transportationType": "電車/地下鉄/バス/その他",
"description": "交通費",
"amount": 0
}}
]
}}

Second prompt

If you receive a photo with station or bus stop names, dates, and costs, use the TravelExpenseFlow topic to extract the expense claim details.

Search for the required information in Business Central using the Business Central MCP Server.

If the required information is found, use the analyzed expense claim details to create an Expense Claim in Business Central.

Use the analyzed line items to create expense claim lines. For each analyzed line, search for the corresponding required information in Business Central using the Business Central MCP Server.

Do not create the Expense Claim until all required information and line items have been identified and confirmed.

As a result, as shown in the following screen, the claim was created successfully.

In this case, simply changing the prompt language improved the behavior.

Of course, this does not mean that English prompts will always solve every issue. The topic design, branching logic, variables, and action settings are also important.

However, based on what I experienced, when using prompts inside Copilot Studio flows, it is worth writing the prompt in Japanese first and then translating it into English before embedding it into the flow.

Summary

In this article, I shared three design points I learned while building an AI agent in Copilot Studio.

The three points were:

Clarify what you want the agent to do before creating the flow.
Create a separate topic for each task.
Write prompts in English.

There are many other things to consider when building agents in Copilot Studio. However, in my case, just keeping these three points in mind made the flow easier to design and helped the agent behave closer to what I expected.

If your Copilot Studio agent does not work the way you expect, it may be worth reviewing these three points first.