Showing results for 
Search instead for 
Did you mean: 
Advocate I
Advocate I

Communication between PCF component runtime and host form's JavaScript environment


Can someone comment on the communication between PCF component runtime and host form's JavaScript environment. It's been stated that "Unlike HTML web resources, code components are rendered as a part of the same context, load at the same time as any other components, providing a seamless experience for the users." 

 However, the runtime environment's "window" object is actually different than the "window" object exposed to the form script, suggesting that they may not be on same frame and share same JS space.  It can be easily confirmed by put a stop point in any PCF code debug session and exam the window object and compare. 

  If the two Js context are different, is there a way to bridge them, so that it's possible to invoke a public function defined in the form script in the PCF code? I can see using a field and pass the value between them, but seems overkill and the model design would be a bit awkward. With web resource it is possible to use the window.Xrm object to bridge the two environment. 


Please comment if you have looked into this issue.

Thanks in advance.


Hi @liun,

HTML Webresources are loaded into child IFrames and even JS Webresource are loaded into the ClientApiFrame which is a child IFrame script host - the PCF code is actually loaded into the main form IFrame window host where the Unified Client HTML is hosted. Although it is possible to hack calling a function on the child JS Frames from a PCF component I would think that this wouldn't a be good idea due to the unsupported nature. 
It is definitely awkward passing values back and forth using bound attribute values - and so I expect that this will be made easier in the future with PCF Framework.
You can still access the Xrm.Page API from a PCF component to grab a reference to an IFrame control - which is also unsupported - but definitely much less unsupported than calling a function directly via the window frames references.

Hope this helps!



@ScottDurow  Thanks! Looked at the debug console a bit more, it looks like the PCF code is at root top frame, but the actual form script is in a child frame, I was thinking the opposite way because the PCF is part of the form.


With that structure, if I want the PCF code to execute a custom function on entity form, I just need to expose that form function to the parent via a separate namespace. It's not really accessing the DOM directly like the getElementById stuff, so I have an argument about "supported" , especially "parent", "window" object is all over the sample code. 


That would save me the need to create dummy fields just for the sake of passing data around, which could get frowned upon by the data people. 


There were talks about "unbounded" control in this forum early on, but seems not getting much attention. 




Currently using the bound fields is the only supported way for PCF control to talk to environment (model form or canvas) and this maintains the PCF isolation and reuse modularity. Form structure and nesting can change under the hood and control functionality can be impacted so using the supported patterns is strongly suggested.  App source validation will flag and block invalid patterns. 


Adding 1st class declarative way for controls to communicate events (or behavior) like canvas apps is in our roadmap. Please use to share community votes which help us prioritize. 



Not applicable

Hi @liun

The idea is create a "common access point" so that PCFs can communicate with each other and receive external commands.

It is similar how the Unified Service Desk use to communicate with the Host Controls.

Define a common interface tho add on controls:


export interface IHostedControl {
    DoAction(action: string, data: string | null): void;


Implement the interface:


export class StaticOrchestrator implements ComponentFramework.StandardControl<IInputs, IOutputs>, IHostedControl {
	public DoAction(action: string, data: string | null): void {
		//your logic


Import the class PCF and on init() method, register the control:


import { PCF } from "./PCF";

public init(context: ComponentFramework.Context<IInputs>, notifyOutputChanged: () => void, state: ComponentFramework.Dictionary, container: HTMLDivElement) {
  this._id = PCF.AttributeLogicalName(context.parameters.sampleProperty);
  PCF.Register(context.parameters.sampleProperty, this);



 On browser, usign Javascript or by other controls, just call:
Sem título.png

Helpful resources

Power Platform Conf 2022 768x460.jpg

Join us for Microsoft Power Platform Conference

The first Microsoft-sponsored Power Platform Conference is coming in September. 100+ speakers, 150+ sessions, and what's new and next for Power Platform.

Power Platform Call June 2022 768x460.png

Power Platform Community Call

Join us for the next call on June 15, 2022 at 8am PDT.

PA Virtual Workshop Carousel 768x460.png

Register for a Free Workshop

This training provides practical hands-on experience in creating Power Apps solutions in a full-day of instructor-led App creation workshop.


New Release Planning Portal (Preview)

Check out our new release planning portal, an interactive way to plan and prepare for upcoming features in Power Platform.

Top Kudoed Authors
Users online (1,576)