Showing results for 
Search instead for 
Did you mean: 
Not applicable

PCF - Can you load native JS into the controls themselves (i.e. The CRM Xrm api)?

For instance, we would like to build a masking control. That would format a number based on the country the record is associated with. Furthermore we are adding the control to Dynamic CRM. Is there a way the we could load/access the form API (i.e. Xrm.Page.getAttribute("name").getValue()) vs making a call to the database?

Power Apps
Power Apps

XRM should not be accessed from controls as controls are modular units bound to framework APIs and values.

For your scenario you can create additional input property to the control and that will surface in the control configuration . Use that to pass in the country value. That way the control is generic and can be configured to any field on any entity and also on canvas apps eventually.

Using the control input property is of course the best solution for this use case, because it keeps it generic.

But what if the rules for the masking control should be stored somewhere else, allowing the customizer to define their own rules, based on the country? This configuration is not on the form.

1. One option would be to have a custom entity, where each record represents a country and a masking rule. In this case we can access the database using the Xrm.WebApi since that is stated in the sdk( The problem with that is that we need to install default data, that makes it harder to transport the solution).

2. The second option would be to store the configuration in a webResource (like a JSON config). But it seems to me that the context.resources.getResource method from the sdk ( is only designed to load resources from inside the control, that are not accessible to a system customizer. To write our own resource loader (for a normal webResource) we would need some context informations like the clientUrl which I didn't found, so also not possible. 

3. Or is it recommended wo use another input property with a fixed value, pasting the whole JSON configuration inside?

Best regards,




Interesting options Diana, nice writeup. I am thinking for option 1, in order to address limitation of migrating sample data to the custom entity, may be control can have the base rules for the country in the code which control can write to custom entity when loaded first time (using fixed guid). These rules can then be edited by the customizer to fine tune in the org as needed. Something like

1. Control load very first time in the org, checks the config entity with given guild (webAPi retrive) and sees record not present. Creates the record with base rules present in the control  (TS or XML). 

2. When the control loads next time it finds the rules and uses them. Also control writes the relevant rule info into local storage using SetState PCF api so that the server call is not needed next time control loads. Uses the cached value to load immediately and sends a call in background to check if there is refreshed data. 

3 Control can also surface the link to config entity if there is user specific customizations need, like toggle to  address validaor by pressing ctrl + Y. User might be in a fixed timezone but does not mean that the addresses he is entering are same country. Toggle at the top and show hide controls default vs custom is another option. 

Verry interesting ideas Hemant. Thank you for sharing Smiley Happy

You've mentioned  saving in local storage using SetState PCF api . Unfortunatelly i didn't found this feature. 

Is the documentation refering this still to be done, or am I just missing it? Or maybe there is an example for that?

Best regards,


Not applicable

Are the input controls static? If so, I do not think this would work as our most common use case would be creating a new lead/contact. And in that scenario, we would not know the country they belong to until it was populated (i.e. when the form loaded we would not know the country as it is blank).

Not applicable

Hemant, unless I am missing something. This will only load files that I have pre-defined. In this scenario, the Xrm API would not be available until run time, as it is full managed by the application itself.

XRM should not be accessed from the control. Only framework APIs.
Not applicable

It sounds like the PCF is not the right fit for a scenario like this.

Helpful resources

New Badges

New Solution Badges!

Check out our new profile badges recognizing authored solutions!

New Power Super Users


We are excited to announce the Power Apps Super Users!

Power Apps Community Call

Power Apps Community Call: February

Did you miss the call? Check out the Power Apps Community Call here.

Microsoft Ignite

Microsoft Ignite

Join digitally, March 2–4, 2021 to explore new tech that's ready to implement. Experience the keynote in mixed reality through AltspaceVR!

Users online (69,267)