The out-of-the-box D365 Copilot is pretty limited because its data context is restricted to the current form. For a patient management system, clinicians need an AI assistant that can:

• Summarise communication history across emails, notes, phone calls, and appointments
• Fetch related patient information from multiple tables (conditions, medications, care plans, referrals)
• Recommend next steps based on clinical context and protocols

This requires richer context than the built-in copilot provides.

Scenario: Patient Communication Agent

A clinician opens a Patient record in a Model-Driven App. In a side pane, a custom copilot agent:

1. Automatically receives the current patient’s record ID
2. Can query Dataverse for all communication activities (emails, phone calls, appointments, notes)
3. Summarises the communication timeline
4. Fetches related clinical data (conditions, medications, care team)
5. Recommends next actions (e.g., “Patient hasn’t been contacted in 30 days - consider a follow-up call”)

Architecture Options

There are two viable approaches to build this. I recommend Approach B for production solutions today, while Approach A is worth watching for the future.

Approach A: Native Agent APIs (Future - Preview Only)

Since July 2025, Power Apps provides native Xrm.Copilot and PCF context.Copilot APIs that directly invoke Copilot Studio topics from within MDA - no separate authentication, no Direct Line token, no external SDK needed.

⚠️ Note: As of June 2026, this feature is still in Public Preview and is not suitable for production solutions. Preview features may change, have limited SLA, and are not covered by Microsoft support. Monitor the release planner for GA announcements. Once GA, this becomes the recommended approach.

Reference: PCF + Copilot Studio: First Look at Agent APIs (Diana Birkelbach, July 2025)

Prerequisites

• Use https://make.preview.powerapps.com/
• Early release cycle environment
• Configure an App assistant agent (formerly “Interactive Agent”) in your MDA (App designer > Agents tab > App assistant agent > Configure in Copilot Studio)
• Docs: Add agents to your app
• Docs: Add app assistant agent

Frontend Architecture

┌─────────────────────────────────────────────────────┐
│  Model-Driven App - Patient Form                    │
│                                                     │
│  ┌─────────────────────┐  ┌──────────────────────┐ │
│  │  Patient Form        │  │  Side Pane           │ │
│  │  (Main Content)      │  │  ┌────────────────┐  │ │
│  │                      │  │  │ Custom Page     │  │ │
│  │  Name: John Smith    │  │  │ ┌────────────┐ │  │ │
│  │  DOB: 1985-03-15     │  │  │ │ PCF Chat   │ │  │ │
│  │  Conditions: ...     │  │  │ │ Component  │ │  │ │
│  │                      │  │  │ │            │ │  │ │
│  │  [Open Agent] btn    │  │  │ │ Uses       │ │  │ │
│  │                      │  │  │ │ context.   │ │  │ │
│  │                      │  │  │ │ Copilot    │ │  │ │
│  │                      │  │  │ └────────────┘ │  │ │
│  │                      │  │  └────────────────┘  │ │
│  └─────────────────────┘  └──────────────────────┘ │
└─────────────────────────────────────────────────────┘

The API

Two methods are available:

// Execute a specific topic by registered Event Name
Xrm.Copilot.executeEvent("PatientAgent.SummariseCommunication", {
    patientId: "00000000-0000-0000-0000-000000000001",
    scope: "last30days"
}).then(response => {
    // response contains text + attachments (Adaptive Cards, etc.)
});

// Execute based on natural language trigger queries
Xrm.Copilot.executePrompt("Summarise recent communications for this patient")
    .then(response => { /* render response */ });

Within a PCF, use context.Copilot instead of Xrm.Copilot:

// Inside PCF updateView or a button handler
this.context.Copilot.executeEvent("PatientAgent.SummariseCommunication", {
    patientId: recordId
}).then(response => {
    this.renderAgentResponse(response);
});

Passing Parameters

The Agent API automatically provides the current form’s entityName and recordId via global variables:

• Global.PA__Copilot_Model_PageContext.pageContext.id.guid
• Global.PA__Copilot_Model_PageContext.pageContext.entityTypeName

For custom parameters, pass a JSON object as the second argument to executeEvent. In Copilot Studio, parse Activity.Value using the “Parse value” node.

Pros & Cons of Approach A

Pros:

• No Azure Entra app registration needed
• No token endpoint management
• No external SDK dependencies
• Native integration - the platform handles auth
• Automatic form context (entity name + record ID)
• Works directly in PCF via context.Copilot

Cons:

• Requires early release cycle environment (as of mid-2025, may be GA by now)
• Must use “App assistant agent” (not a standalone Copilot Studio agent)
• Limited to executeEvent and executePrompt - no streaming/conversational chat UI out-of-the-box
• For a full chat experience, you still need to build your own chat UI in the PCF

Approach B: Custom Canvas via Direct Line (Recommended for Production)

This approach uses the Bot Framework Web Chat SDK to embed a full conversational chat interface powered by a standalone Copilot Studio agent. All components are GA and production-supported.

Frontend

• D365 side panes by using a client API ✅ Link valid
• Custom Pages in Side Panes (Diana Birkelbach) ✅ Link valid
• Inside the Custom Page, build a PCF as the chat interface using Bot Framework Web Chat
• Use the Copilot Studio Token Endpoint + Direct Line to connect
• Register an Azure Entra app for SSO authentication
• Docs: Customize the default canvas
• Docs: Configure SSO with Microsoft Entra ID
• Samples: CopilotStudioSamples on GitHub

Passing Record ID to the Custom Page

Yes! The navigateTo and pane.navigate APIs support passing recordId and entityName to a Custom Page:

// From form scripting - open side pane with patient context
async function openPatientAgent(formContext) {
    const patientId = formContext.data.entity.getId().replace(/[{}]/g, "");
    
    const pane = Xrm.App.sidePanes.getPane("PatientAgent") 
        ?? await Xrm.App.sidePanes.createPane({
            title: "Patient Agent",
            imageSrc: "WebResources/agent_icon",
            paneId: "PatientAgent",
            canClose: true,
            width: 450
        });
    
    pane.navigate({
        pageType: "custom",
        name: "cr123_patientagentpage",  // logical name of your custom page
        entityName: "contact",           // available via Param("entityName")
        recordId: patientId              // available via Param("recordId")
    });
}

In the Custom Page (Canvas App), read the parameters:

// Power Fx in Custom Page
Set(varPatientId, Param("recordId"));
Set(varEntityName, Param("entityName"));

Token Endpoint & Direct Line Connection (in PCF)

// PCF component - initialize Web Chat
async function initializeChat(tokenEndpoint: string) {
    // 1. Get token from Copilot Studio token endpoint
    const response = await fetch(tokenEndpoint);
    const { token } = await response.json();
    
    // 2. Get regional Direct Line URL
    const envEndpoint = tokenEndpoint.slice(0, tokenEndpoint.indexOf("/powervirtualagents"));
    const apiVersion = tokenEndpoint.slice(tokenEndpoint.indexOf("api-version")).split("=")[1];
    const settingsUrl = `${envEndpoint}/powervirtualagents/regionalchannelsettings?api-version=${apiVersion}`;
    
    const settingsResponse = await fetch(settingsUrl);
    const { channelUrlsById } = await settingsResponse.json();
    const directLineUrl = channelUrlsById.directline;
    
    // 3. Create Direct Line connection
    const directLine = window.WebChat.createDirectLine({
        domain: `${directLineUrl}v3/directline`,
        token: token
    });
    
    // 4. Render Web Chat
    window.WebChat.renderWebChat(
        { directLine, styleOptions },
        document.getElementById("webchat")
    );
}

SSO Configuration

To avoid the user being prompted to sign in again inside the chat:

1. Create an authentication app registration for user auth in Copilot Studio
2. Create a canvas app registration (SPA) for your custom page/PCF
3. Configure Token Exchange URL in Copilot Studio security settings
4. Use MSAL in your PCF to acquire a token and pass it to Web Chat

Reference: Configure SSO with Entra ID

Pros & Cons of Approach B

Pros:

• Full chat UI with conversation history, typing indicators, Adaptive Cards
• Works with any standalone Copilot Studio agent
• No dependency on preview features
• More flexible - can use any Web Chat customization

Cons:

• More complex setup (Entra app registration, token management, SSO)
• External SDK dependency (Bot Framework Web Chat)
• Must manually pass context (record ID) via activity payload
• More moving parts to maintain

Backend: Copilot Studio Agent Design

Regardless of which frontend approach you choose, the Copilot Studio agent design is the same.

Topics to Build

Data Access - Custom Connector or Plugin Actions

Copilot Studio topics can call:

1. Power Automate Cloud Flows (simplest)
   • Flow receives patientId as input
   • Queries Dataverse for activities: GET /api/data/v9.2/activitypointers?$filter=_regardingobjectid_value eq '{patientId}'&$orderby=actualend desc&$top=50
   • Returns structured JSON to Copilot Studio
2. Custom API / Plugin Actions (more performant)
   • Register a Dataverse Custom API: new_GetPatientCommunicationSummary
   • Input: PatientId (Guid)
   • Output: structured JSON with activities, timeline, key dates
   • Invoke from Copilot Studio via connector
3. Dataverse Knowledge Source (for grounding)
   • Add your Dataverse tables as Knowledge in Copilot Studio
   • The agent can directly query patient-related tables

Example Flow: Summarise Communications

Trigger: Copilot Studio calls flow with patientId
    │
    ├─ List Activities (Dataverse connector)
    │   Filter: regardingobjectid eq patientId
    │   Select: subject, description, activitytypecode, actualstart, actualend
    │   Order: actualend desc, Top: 50
    │
    ├─ Compose: Format activities into structured text
    │   "Email (2026-04-01): Subject - Follow-up on lab results..."
    │   "Phone Call (2026-03-28): Subject - Discussed medication change..."
    │
    └─ Return: Formatted summary text to Copilot Studio

Copilot Studio then uses the AI model to:

• Synthesise the raw activity list into a natural language summary
• Highlight key themes and recent interactions
• Generate next-step recommendations

Generative AI Orchestration in Copilot Studio

Configure the topic to use a Generative Answers node:

1. Feed the structured patient data as context
2. Use a system prompt like:

You are a clinical communication assistant. Given the patient's recent 
communication history, provide:
1. A brief summary (3-5 sentences) of key interactions
2. Any notable patterns or concerns
3. Recommended next steps based on gaps in communication

Patient Data:
{Topic.PatientActivities}

Approach C (Bonus): MCP Apps / Custom UI Widgets in M365 Copilot

As of April 2026 (Public Preview), there’s a third option: Custom UI Widgets powered by Power Apps that render inside M365 Copilot Chat.

Reference: Inside Built-In and Custom Copilot UI Widgets powered by Power Apps (Diana Birkelbach, May 2026)

This approach:

• Exports your MDA as an MCP server package
• Deploys to M365 Copilot via Teams sideloading
• Custom tools provide rich HTML UI widgets inside the chat
• Uses the @modelcontextprotocol/ext-apps npm package for host-view communication

When to use this: If you want the patient agent to be accessible across M365 (Outlook, Teams, Copilot Chat) rather than only inside the MDA form. It’s great for scenarios where clinicians are working in Outlook and want to quickly check a patient summary without opening D365.

Limitation: This is in preview, requires M365 Copilot Premium license, and deployment requires Teams/M365 admin access.

Recommended Implementation Plan

Phase 1: Foundation (Week 1-2)

1. Set up environment: Early release cycle Dataverse environment
2. Create data model (if not existing): Patient (Contact), Communication Activity custom table or use OOB Activity entities
3. Create App assistant agent in MDA App designer (Agents tab > App assistant agent > Configure in Copilot Studio)
4. Build first topic in Copilot Studio: “Summarise Communications”
   • Trigger: Custom client event PatientAgent.SummariseCommunication
   • Parse Activity.Value for patientId
   • Call Power Automate flow to fetch activities
   • Use Generative Answers to produce summary

Phase 2: PCF Chat Component (Week 3-4)

1. Build PCF control (React-based) with:
   • Chat message list UI (using Fluent UI v9 components)
   • Input box for free-text prompts
   • Button bar for predefined actions (Summarise, Overview, Next Steps)
   • Calls context.Copilot.executeEvent() or context.Copilot.executePrompt()
   • Renders response text and Adaptive Card attachments
2. Create Custom Page containing the PCF
3. Wire up Side Pane via form script on Patient form’s onLoad event

Phase 3: Enriched Agent (Week 5-6)

1. Add more topics: Patient Overview, Recommend Next Steps
2. Add Knowledge sources: Clinical protocols on SharePoint, Dataverse tables
3. Add Custom APIs for performant data retrieval
4. Test with real patient data (anonymised)

Phase 4: Polish & Productionise (Week 7-8)

1. UX polish: Loading states, error handling, conversation history
2. Security review: Ensure patient data access respects Dataverse security roles
3. Performance testing: Token caching, response times
4. Deploy to production environment (once Agent APIs reach GA)

Key Links & References

Conclusion

Verdict: This is absolutely feasible. The recommended path for production is Approach B (Direct Line + Web Chat). It uses GA components (Side Panes, Custom Pages, Bot Framework Web Chat, Copilot Studio token endpoint) and gives full control over the chat experience.

Approach A (native Agent APIs) will simplify the architecture significantly once it reaches GA - keep an eye on it. When it goes GA, you can migrate the PCF from Direct Line to context.Copilot.executeEvent() and drop the Entra app registration and token management entirely.

For cross-M365 access (Outlook, Teams), consider adding Approach C (MCP Apps) later as a complementary channel.

Can I pass the form context record ID to the custom page? → Yes! Use pane.navigate({ pageType: "custom", name: "...", entityName: "contact", recordId: patientId }) and read it in the Custom Page via Param("recordId").

Entity-Specific Templates

Entity-specific templates are tied to a particular table (entity) and can resolve fields from that table automatically via the template editor UI. However, there is a significant limitation: you cannot create entity-specific email templates for custom entities through the standard UI. This restricts their usefulness in solutions with heavy customisation.

Global Templates

Global templates are not bound to any specific entity, which makes them more flexible. To use dynamic text with custom entities in a global template, you need to manually write the mapping syntax.

Text fields:

{!EntityLogicalName:FieldLogicalName;}

Example — pulling a user’s address:

{!User:Address;}

Lookup fields (to resolve the display name):

{!EntityLogicalName:LookupFieldLogicalName/@name;}

Tip: If your syntax is correct, the dynamic value placeholder will turn yellow in the template editor after saving. If it stays plain text, double-check your entity and field logical names. For example, is the column doesn’t exist in the table or spelling errors.

How to Test a Template

There are a few approaches to validate that your template resolves correctly:

1. Manual test — Create an email record, insert the template, and set the regarding record. Confirm the placeholders resolve to actual values.

2. InstantiateTemplate action — Call the InstantiateTemplate Dataverse action programmatically. Tools like the Dataverse REST Builder XrmToolBox plugin can help. The workflow in REST Builder is: build the request in Configure mode → switch to Fetch mode to generate the request code → move to Editor mode to execute. It’s not the most intuitive flow, but it works.

Implementation Scenario(s)

Power Automate — Use an unbound action step in a cloud flow to call InstantiateTemplate. This is especially powerful for integrating with the rest of your business process or logic.

Complex Data Mapping

When out-of-the-box dynamic text isn’t enough (e.g., you need conditional logic, formatted dates, or data from related records beyond a single lookup), use Power Automate:

• Define your own placeholder syntax in the template body (e.g., ``).
• Build a flow that retrieves the necessary data, performs transformations, and replaces your custom placeholders before sending the email.

This pattern gives you full control over the email content while still leveraging templates for the static structure.

Reference

• Email dynamic text - Microsoft Learn
• https://himbap.com/blog/?p=4541

Integrations can be either inbound or outbound. This article will focus on outbound integration—specifically, using a Managed Identity to allow Power Platform (Dataverse) plugins to securely call external Azure resources.

Overall Goal

The primary purpose of configuring a Managed Identity (MI) is so that Microsoft Entra ID will trust the calling plugin assembly. This allows your custom Dataverse code to securely authenticate against external Azure services without embedding credentials.

Step-by-Step Implementation

• Certificate: Generate the .pfx file containing the key pair.
• Certificate: Import the .pfx into the Windows certificate store.
• Azure: Create a user-assigned managed identity.
• Dataverse: Create an application user and link it to the managed identity record.
• Dataverse: Assign the required security roles.
• Development: Build the plugin .dll.
• Security: Sign the assembly using the generated certificate.
• Deployment: Upload the signed assembly to Dataverse.
• Configuration: Link the assembly with the managed identity in Dataverse.
• Azure: Add federated credentials and role assignments with the Azure managed identity.
• Validation: Test the integration.

Generate a Self-Signed Certificate

Your certificate must contain a key pair (both private and public keys) to sign the assembly. Below is a PowerShell example to generate one.

$kuCodeSigning = "1.3.6.1.5.5.7.3.3";

$cert = New-SelfSignedCertificate `
  -Type "CodeSigningCert" `
  -KeyExportPolicy "Exportable" `
  -Subject "VivoAirManagedIdentityPlugin" `
  -KeyUsageProperty @("Sign") `
  -KeyUsage @("DigitalSignature") `
  -TextExtension @("2.5.29.37={text}$($kuCodeSigning)", "2.5.29.19={text}false") `
  -CertStoreLocation "Cert:\CurrentUser\My" `
  -KeyLength 2048 `
  -NotAfter ([DateTime]::Now.AddYears(1)) `
  -Provider "Microsoft Software Key Storage Provider";

$emptyPassword = [System.Security.SecureString]::new()

Export-PfxCertificate `
  -Cert "Cert:\CurrentUser\My\$($cert.Thumbprint)" `
  -FilePath "$env:TEMP\VivoAirManagedIdentityPlugin.pfx" `
  -Password $emptyPassword;

The ku in kuCodeSigning stands for key usage. The example provided in standard Microsoft documentation is typically for secure email signage, which is not designed for signing plugin assemblies. The OID 1.3.6.1.5.5.7.3.3 explicitly ensures it is valid for code signing.

You need to register the keys of the generated .pfx file within the Windows certificate storage. Ensure it is placed in both the Personal and Trusted Root Certification Authorities nodes for successful signing.

Signing Tool

Use the Windows SDK SignTool to apply the certificate to your assembly.

Create a Managed Identity Record in Dataverse

You can establish this link by creating an application user in the Power Platform admin center.

Calling Managed Identity for Bear Token

        public string GetToken(List<string> scopes)
        {
            return _managedIdentityService.AcquireToken(scopes);
        }

Add Federated Security in Azure

When configuring the federated credentials in Azure, the subject string is used to pinpoint the intended caller plugin assembly. Note that the expected subject format has changed from v1 to v2.

Managed Identity Basics

There are two types of Managed Identities: System-Assigned and User-Assigned. For Power Platform plugins connecting to Azure, we create and utilize a User-Assigned Managed Identity.

References

• Set up managed identity for Power Platform Plugins
• Power Platform Plugin Package – Managed identity
• Set up Power Platform managed identity for Dataverse plug-ins or plug-in packages
• SignTool.exe (Sign Tool)
• New-SelfSignedCertificate

Future Posts

• Managed Identity with Plugin Packages
• Managed Identity with vNet and apim

We need CI/CD and ALM in Power Platform to move from ad‑hoc manual exports/imports to predictable, governed delivery.

Key Pillars

Development Experience

• Plugin Registration
• Codegen
• Unpack Solutions
• Pack Solutions

Strategies

Solution Segregation

Option 1: Split by Features But you will still need a core solution for shared components, and if the core solution becomes too big, you need to split it.

Option 2: Split by Components Customization, Plugin, Workflows and etc.

Layering

The final product is like a cake and each solution is like a layer of the cakse. The solution importing sequence is important because it dictates if and how solution layer are stacked and which overwrite which.

CICD Experience

• Deployment targeting - you can target multiple systems, so called fan out. You can keep the deployment mapping configration in the json.
• PR merge gate with Pre-validation and code review.
• Deployment gate - approver before deployment goes ahead
• Deploy - ADO stages and steps and tools.
• Post Deploy - master data import

Evolution

Manually export solutions in a folder

Back in the bad old days, the packaging are handled manually, meaning the dev team will manually export solutions and put them in a folder in the source repository. Later the CICD pipeline will deploy the solutions from the repo. Optionally, you can provide CICD pipeline with powershell scripts to unpack the zip solution and inject the built plugin dlls and re-package.

Code Based Package

We moved away from committing exported solution .zip files. Instead we use PowerShell with the pac CLI to unpack solutions and commit only the unpacked XML (solution definition) to source control. This gives us:

• Meaningful diffs (component level instead of opaque binaries)
• Better traceability (who changed which attribute/artifact)
• Easier observability and code review

Discipline is critical. The unpacked solution definition in git must always mirror the originating environment. When drift appears, developers are tempted to hand‑edit XML to “force” a change into the next environment—slow, brittle, and error‑prone.

Repository & branching: all squads contribute to the same repository and share a single release/trunk branch (with short‑lived feature branches). We previously experimented with letting squads keep divergent copies of the same solution for “parallel development” and then hand‑merge XML. Outcome: frequent pipeline failures, sprawling merge conflicts across many XML files, and elongated release cycles.

Lessons learned:

1. Don’t manually merge unpacked solution XML. Treat the environment as source of truth; always re‑export/unpack/overwrite instead of editing.
2. Maintain one authoritative branch lineage per solution; avoid long‑running parallel variants.
3. Automate sync validation (pre‑PR or pipeline) to catch drift early.
4. Flow changes forward only (dev → test → prod). Avoid reverse edits by hacking XML.
5. Make pack/unpack scripts idempotent and run them locally and in CI to eliminate divergence.

Core principle: no code‑level merging of solution definitions; solution evolution moves one way toward higher environments.

PPDO

Power Platform Devops is community initiated toolkit which helps with packing, unpacking, codegen, configuration data export and other packing related tasks.

ALM accelerator

ALM Accelerator for Power Platform is microsoft initiated toolkit which helps with packing, unpacking, deployment mapping, pipeline yaml templates and etc.

Power Platform native git integration

Git integration in Power Platform is the Power Platform native support for solution sync and deployment.

// Does not work
ClearCollect(
    colEmployeesGrouped,
    ForAll(
        Distinct(colEmployees, Department),
        With(
            {
                currentDept: ThisRecord.Value,
                matchingRecords: Filter(colEmployees, Department = ThisRecord.Department)
            },
            {
                currentDeptTest: currentDept,
                matchingRecordsTemp: matchingRecords,
                matchingRecordsCount: CountRows(matchingRecords)
             }
        )
    )
);

// Works
ClearCollect(
    colEmployeesGrouped,
    ForAll(
        Distinct(colEmployees, Department),
        With(
            {
                currentDept: ThisRecord.Value
            },
            {
                Department: First(Filter(colEmployees, Department = currentDept)).Department,
                EmployeeNames: Concat(Filter(colEmployees, Department = currentDept), FullName, "; "),
                JobTitles: Concat(Filter(colEmployees, Department = currentDept), JobTitle, "; ")
             }
        )
    )
);

The top code snippet doesn’t work is because ThisRecord.Department doesn’t exist. It will not throw any errors but you will get empty collection rather than expected data.

The problematic code

Filter(colEmployees, Department = ThisRecord.Department)

To fix it, use ThisRecord.Value instead.

Filter(colEmployees, Department = ThisRecord.Value)

So, the takeaway from this is when looping with ForAll, the current record context is super important, i.e. This Record.

ThisRecord example

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined),
        With(
            {
                currentOrigin: ThisRecord.Value,
                matchingRecords: Filter(colCaseParties, CasePartyOriginCombined = ThisRecord.Value)
            },
            {
                CasePartyOriginCombined: First(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)).CasePartyNameCombined,
                CasePartyRoleNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyRoleName, "; "),
                CasePartyLawyerNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyLawyerName, "; ")
             }
        )
    )
);

The value of ThisRecord changes depend on the scope.

currentOrigin: ThisRecord.Value 

The scope of ThisRecord is Distinct(colCaseParties, CasePartyOriginCombined)

matchingRecords: Filter(colCaseParties, CasePartyOriginCombined = ThisRecord.Value)

The scope of ThisRecord is colCaseParties

Nested With

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined),
        With(
            {
                currentOrigin: ThisRecord.Value,
                matchingRecords: Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)
            },
            {
                CasePartyOriginCombined: First(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)).CasePartyNameCombined,
                CasePartyRoleNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyRoleName, "; "),
                CasePartyLawyerNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyLawyerName, "; ")
             }
        )
    )
);

The above code will not work because of currentOrigin is not recognized inside Filter(colCaseParties, CasePartyOriginCombined = currentOrigin).

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined),
        With(
            {
                currentOrigin: ThisRecord.Value
            },
            With(
                {
                    matchingRecords: Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)
                },
                {
                    CasePartyOriginCombined: First(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)).CasePartyNameCombined,
                    CasePartyRoleNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyRoleName, "; "),
                    CasePartyLawyerNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyLawyerName, "; ")
                }
            )
        )
    )
);

The above code works

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined),
        With(
            {
                currentOrigin: Value,
                matchingRecords: Filter(colCaseParties, Value = ThisRecord.CasePartyOriginCombined)
            },

                {
                    CasePartyOriginCombined: First(matchingRecords).CasePartyNameCombined,
                    CasePartyRoleNames: Concat(matchingRecords, CasePartyRoleName, "; "),
                    CasePartyLawyerNames: Concat(matchingRecords, CasePartyLawyerName, "; ")
                }
            
        )
    )
);

Works

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined) As DistinctCaseParties,
        With(
            {
                currentOrigin: DistinctCaseParties[@Value],
                matchingRecords: Filter(colCaseParties, ThisRecord.CasePartyOriginCombined = DistinctCaseParties[@Value])
            },

                {
                    CasePartyOriginCombined: First(matchingRecords).CasePartyNameCombined,
                    CasePartyRoleNames: Concat(matchingRecords, CasePartyRoleName, "; "),
                    CasePartyLawyerNames: Concat(matchingRecords, CasePartyLawyerName, "; ")
                }
            
        )
    )
);

Works with a disambiguation operator.

Record scope is for each record of a loop function like Filter.

Value is a special field for single columns data table sources.

ThisRecord symbol is for the most immidiate data context.

References

Debugging with local testing harness

npm start or npm start watch

You can debug the PCF code component locally but the problem is it will not load the real data therefore you cannot test it with real data.

Debugging after deployment

After deploy, you can use browser’s developer tools for debugging.

Debugging without deployment

It definitely makes the dev/test feedback loop a lot faster with the benefit of testing it with real data.

Requestly

Fiddler didn’t work for me either. My browser kept saying there was a suspicious network activity when Fiddler was turned on.

So, I tried the other method (Requestly) based on the following msdoc articles - Debug code components - Power Apps

Just at couple of things to note: You need to build your PCF control in production mode in order to get the bundle.js as build output I am using Requestly Chrome add-on for redirect network traffic to my local PCF component bundle.js. The standalone Requestly app may also work but I struggled a little bit and gave up.

References

• https://learn.microsoft.com/en-us/power-apps/developer/component-framework/debugging-custom-controls#using-requestly

Okay, here’s a revised and enriched version of your blog post draft, incorporating details from the Microsoft documentation while maintaining your personal experience and perspective.

Debugging Your Power Apps PCF Controls: From Local Harness to Real Data

Developing Power Apps Component Framework (PCF) controls unlocks powerful UI customizations, but debugging them effectively can sometimes feel tricky. Fortunately, we have several methods available, ranging from quick local checks to debugging against live Dataverse data without constant redeployments. Let’s explore the main approaches.

1. The Local Test Harness (npm start watch)

When you first start building your component logic, the quickest way to see visual changes is using the local test harness. Running npm start or npm start watch in your project directory builds your component and pops it open in a local web page.

• Pros:
  • Fast Feedback Loop: Changes to your index.ts, imported modules, CSS, or resource files trigger an automatic reload in the browser. Great for rapid UI tweaks and basic logic testing.
  • Form Factor Testing: Easily switch between Web, Tablet, and Phone form factors to test responsiveness.
  • Basic Input Simulation: Allows you to provide mock data for properties defined in your manifest. For datasets, you can even load data from a CSV file.
• Cons:
  • No Real Data Context: This is the biggest limitation. The harness runs entirely locally. You cannot interact with actual Dataverse data.
  • Limited API Support: Features like context.webAPI, dataset paging, sorting, filtering, complex lookups/choices, or navigation APIs won’t work. They’ll typically throw errors because the harness doesn’t provide the necessary Power Apps runtime context.
  • Property Updates: The updatedProperties array in updateView isn’t populated correctly when you change inputs in the harness.

Verdict: Excellent for initial development and UI layout, but insufficient for testing logic that interacts with Dataverse.

2. Browser Developer Tools (Your Best Friend Everywhere)

No matter which debugging method you use, your browser’s built-in developer tools (F12 or Ctrl+Shift+I) are essential.

• Key Uses:
  • Inspecting the DOM: Use the ‘Elements’ tab to see the HTML structure your component generates and debug CSS styling issues.
  • Debugging JavaScript: Use the ‘Sources’ tab. Thanks to source maps (generated during development builds via webpack), you can usually find your original TypeScript (.ts) file (often under webpack://), set breakpoints directly in your TS code, step through execution, and inspect variable values.
  • Console: Check for errors and log output using console.log().
  • Network: Analyze API calls (though less relevant for the local harness).
• Tip: In Power Apps Studio, the F12 key might be mapped to something else. Use Ctrl+Shift+I to reliably open the developer tools.

3. Debugging Against Real Data Without Constant Redeployment (The Redirect Method)

This is where things get powerful. You need to test your component with real data and interact with Dataverse APIs, but constantly rebuilding, deploying (pac pcf push), and publishing after every small code change is incredibly slow.

The solution is to deploy your component once to your Dataverse environment, and then use a tool like Fiddler or Requestly to intercept the browser’s request for your component’s code and redirect it to your local machine where you’re running npm start watch.

• The Concept:
  1. Deploy Once: Build and deploy your PCF control to your target Dataverse environment. The Microsoft documentation recommends deploying a production build (PcfBuildMode set to production in .pcfproj or using npm run build -- --buildMode production before pac pcf push). This ensures the component structure matches what the platform expects and avoids potential size limits of development builds.
  2. Run Locally: Start your local development server using npm start watch. This continuously rebuilds your component locally as you make changes.
  3. Intercept & Redirect: Use Fiddler or Requestly to tell your browser: “When you try to load the bundle.js (and related CSS/HTML) for this specific PCF control from Dataverse, load it from my local development server instead.”
  4. Debug: Open Power Apps (model-driven or canvas) where your component is configured. Your browser now loads the code directly from your local machine. Set breakpoints in your TS code using the browser dev tools, interact with your app, and debug against real data! Make code changes, save, let npm start watch rebuild, refresh the Power Apps browser page (a hard refresh Ctrl+Shift+R might be needed initially), and test the new code instantly.

• Tools for Redirection:

  • Fiddler: A powerful web debugging proxy. The MS docs detail setting up its AutoResponder feature with REGEX rules to match requests for your component’s files (bundle.js, CSS, etc.) and map them to your local output folder (e.g., YourProject\out\controls\YourControlName).
    • My Experience: As noted in my draft, I personally ran into issues where my browser flagged Fiddler’s HTTPS decryption as suspicious network activity, making it unusable. Setup can also involve certificate installation and specific rule configurations.
  • Requestly: A browser extension (and standalone app) focused on modifying network requests. This often feels simpler for this specific use case.
    • My Experience: This worked much better for me! I used the Requestly Chrome add-on. The standalone app might work too, but the extension felt more straightforward.
    • Simplified Requestly Setup:
      1. Host Locally: Ensure your local build output (e.g., C:\PCFProject\out\controls\MyControl) is accessible via a local web server. Enabling IIS on Windows and setting up a simple website pointing to this folder on a specific port (e.g., http://localhost:7777) is one way described in the docs.
      2. Install Requestly: Add the extension to your browser.
      3. Create Rule: Create a “Replace Host” or “Redirect Request” rule.
         • Source Condition: The URL should contain a pattern unique to your deployed component, like [YourOrg].crm.dynamics.com/WebResources/your_namespace.your_control_name (the exact pattern might vary slightly).
         • Destination: Redirect to your local server address pointing to the specific file being requested, often the bundle.js. You might need a rule like: Replace https://[YourOrgUrl]/.../WebResources/your_namespace.your_control_name/bundle.js with http://localhost:7777/bundle.js. You might need separate rules or a more flexible rule for CSS/other resources if applicable.
      4. Activate & Refresh: Enable the rule in Requestly. Clear your browser cache and perform a hard refresh (Ctrl+Shift+R) on the Power App page the first time. Subsequent code changes should only require a normal refresh.

Key Benefit: This redirect method provides the best of both worlds: the rapid feedback loop of local development combined with the full context and real data of a live Dataverse environment.

Final Tips

• Source Maps: Ensure source maps are generated in your local development build (npm start watch does this by default). They are crucial for debugging your original TypeScript in the browser’s developer tools.
• ES5 vs ES6: By default, PCF components target ES5 JavaScript for broader browser compatibility. If you only need to support modern browsers, changing the target in tsconfig.json to ES6 can sometimes lead to cleaner transpiled code and slightly better debugging experiences, as ES6 features like classes map more directly to TypeScript. Remember to switch back to ES5 before creating your final production build if needed.

By understanding these different methods, you can choose the most efficient approach for debugging your PCF controls at each stage of development. While the local harness is great for quick UI checks, mastering the redirect technique with Requestly or Fiddler is key for efficiently tackling complex issues involving real data.

Datetime

const date = new Date("2025-03-31T20:00:00Z");
console.log(date.toString()); // Outputs: "Tue Apr 01 2025 09:00:00 GMT+1300 (New Zealand Daylight Time)"
console.log(date.toISOString()); // Outputs: "2025-03-31T20:00:00.000Z"

Without the suffix Z, the date time string is considered in local time zone. If it is actually in UTC, you will have an time zone offset issue.

const mydate = new Date("2025-03-31");
console.log(mydate.toString()); // Outputs: "Mon Mar 31 2025 00:00:00 GMT+1300 (New Zealand Daylight Time)"
console.log(mydate.toISOString()); // Outputs: "2025-03-30T11:00:00.000Z"

FakeXrmEasy made unit tests D365 really easy.

Unit testing CRUD operations is well proven and on the beaten path, however, the framework still have gaps in implemented fake message executors. For example, if the function you are testing contains QueryExpressionToFetchXmlRequest.

FakeXrmEasy.PullRequestException: Exception: The organization request type 'Microsoft.Crm.Sdk.Messages.QueryExpressionToFetchXmlRequest' is not yet supported...

Soution

Implement a FakeMessageExecutor

Futher limitation and a workaround

In the QueryExpressionToFetchXmlRequest instance, the FetchXml property of the QueryExpressionToFetchXmlResponse class is readonly.

So, let’s look into the matter. The QueryExpressionToFetchXmlResponse class inherits from the fundamental Microsoft.Xrm.Sdk.OrganizationResponse class. This base class provides a standardized structure for all responses returned from messages executed via the IOrganizationService. A key component of OrganizationResponse is the Results property.  

The Results property is of type ParameterCollection. This collection functions much like a dictionary, mapping string keys to object values. It serves as the standard mechanism through which output parameters from any organization service message are communicated back to the calling code.

So the solution is rather than populate the FetchXml property, populate the Results collection in the underlining class.

var response = new QueryExpressionToFetchXmlResponse();
response.Results["FetchXml"] = sb.ToString();

.Net library Requirements

Add System.Runtime.CompilerServices.Unsafe nuget package to your test project.

References

• http://www.bwmodular.org/blog/mocking-unimplemented-organisation-requests-in-fakexrmeasy
• [FakeXrmEasy v2 and v3 Custom APIs]https://dynamicsvalue.github.io/fake-xrm-easy-docs/quickstart/messages/custom-apis/

entry point input: context

output has two parts: the notification party and get output part

component property bags

service layer: json parsing

date time type

UserSettings > getTimeZoneOffsetMinutes https://learn.microsoft.com/en-us/power-apps/developer/component-framework/reference/usersettings/gettimezoneoffsetminutes

For format date time if we use format string we need moment If we use Locale string we need resx

Utility > Lookup property https://dianabirkelbach.wordpress.com/2021/06/19/lookup-pcf-lets-dive-deeper/

Notification bar

UI >

MessageBarType

Scenario: Title and details message

https://developer.microsoft.com/en-us/fluentui#/controls/web/messagebar

Scenario: Dismiss

onDismiss

Scenario: Multiple notifications

NotificationMessage[] then map to MessageBar JSX

Scenario: Timeout

Pagination:

https://markcarrington.dev/2021/02/23/msdyn365-internals-paging-gotchas/?utm_source=FetchXMLBuilder&utm_medium=XrmToolBox#multiple_linked_entities

### Browser event

In the Power Apps Component Framework (PCF), browser events are primarily managed through the notifyOutputChanged method and custom events defined in the component manifest.

It works better with canvas app but one issue I had is it triggers the whole PCF to refersh which leads it to loose all its states…

Install the PAC CLI tool for both the VS Code and Command Prompt for Windows

Install Power Platform CLI using Windows MSI

## Create a PCF solution folder

mkdir FileExplorerV9

Initialize the PCF solution structure

pac pcf init -ns Kys.CustomControl.FileExplorer -n src --template dataset -fw react -npm

pac pcf init --namespace SampleNamespace --name LinearInputControl --template field --run-npm-install

Initialize the Dataverse solution project

pac solution init --publisher-name KelvinBytes --publisher-prefix kys

pac solution add-reference --path FileExplorer