Editable Dataset PCF: New SDK Methods

Last week I was just browsing to PCF sdk, in order to post a link for an answer in the Power Apps Community Forum, and I’ve landed to “EntityRecord“. I had the feeling that something was different, so I had a look to the methods available there:

Wait…. What…? Can we change and save with a dataset PCF? I don’t even know since when the functions are available, but this is a big deal! So I had to try it out.

I was able to make them work, and the methods are documented (so basically supported), but the typings “@types/powerapps-component-framework” doesn’t seem to know the change.
Maybe they will be updated soon. Until then, I’ve used //@ts-ignore to workaround the missing of the typeing for now.

Why do we need the dataset PCF save methods?

Well, we could have implemented the saving inside the dataset PCF before too. For that we could have used the webAPI feature of the PCF or even implement our own Requests. But it’s not really the same. Let’s see some differences.

Track changes

Until now, for making changes we had to decide how we want to keep track of the changes. Do we want to show them right away, and provide a save button? Was it a better use case for saving right away (after every click) and calling the dataset.refresh() method, and render the whole dataset (page) again? Usually, we would have built a model to keep track of changes.

With the new sdk methods we don’t need that anymore. We have the dataset itself.

Connection Url

Inside the Canvas App we cannot make use of the WebAPI feature. So if we want the PCF to save by itself, we would have implemented the requests by ourselves. For that we need to define the connection information somewhere (maybe an environment variable). Binding the data to a PCF is really easy with a CanvasApp, but then having an additional configuration for being able to save doesn’t feel comfortable, right?

Another alternative for Canvas Apps was to provide some output parameters (like a string containing the changes data, in a JSON) and use PowerFX to make the saving. Also, not the best experience.


If we had to implement some self made requests, we would have lost the offline capabilities.

Work outside dataverse: opened to connectors

The Dataset PCFs for Canvas Apps and for Custom Pages opened up a lot of possibilities to work with connectors. Suddenly we could use the PCF for external datasources. But making changes inside the PCF was only possible using the tricks like Output Parameters + PowerFX (so outside the PCF itself).

The new Dataset PCF save methods

The EntityRecord methods involved are (available for Model-Driven Apps, Custom Pages and Canvas Apps):

  • setValue(columnName, value) – This is a request to change the value. You won’t see the changes right away, but it will call an updateView. With the updateView we get a new dataset containing the changed data. But the data is changed only in the react store, not on the dataverse/server. So we can decide if we save after every change, row by row or if we want a complete view-save (with a save button).
  • isDirty() – it should return a boolean telling if the record was changed. In my tests it was always false, so I need to keep an eye on this.
  • save() – This will start to save the record changes. Only the changed columns will be submitted with the requests (not all columns). It’ll return a Promise, so you know it succeeded, but even when the promise was resolved, I didn’t had the changed data inside the dataset. But after another updateView call, the changed dataset was provided.

So if we want to save the changes right away, we could have something like this

const record = dataset.records[id];
   record.setValue(columnName, value);  

And here is the result (you can have a look to the code at my github ColorfulOptionsetGrid: https://github.com/brasov2de/ColorfulOptionsetGrid/blob/master/ColorfulOptionsetGrid/App/ColorfulGrid.tsx#:~:text=const%20onChange%3D%20isEditable,%7D%20%3A%20undefined%3B)

Does it work in a Custom Page / Canvas Apps

Oh…yes :-). Besides the methods for EntityRecord above, in Canvas Apps we have also methods to create new records and delete records.

  • newRecord() – Initialize a local record object for control to set the value. The control need to invoke the save() method on the newly created record to persist the change.
  • delete([ids]) – Delete the records from data source.
  • getDataSetCapabilities() – we get to know the capabilities
    • isEditable
    • isSortable
    • canPaginate
    • canCreateNewRecords
So in order to create a new record, we need something like this:
dataset.newRecord().then((rec) => {
    rec.setValue("diana_name","This is created using the dataset features"); 
    rec.save().then( () => console.log("Saved")).catch(console.error) }

After that the updateView will be called, and the dataset will contain also the new created record.

For deleting we don’t need to call the save(); after delete and the following updateView, the records are gone.


I wonder why the newRecord() and delete() methods are available only for Canvas Apps and Custom Pages but not for Model-Driven Views? I’ve tried them out: the methods are not even there inside model-driven forms and views. I’m happy to have them inside Canvas Apps, since we have no other good way to make the creation/deletion for the datasource provided by the connectors. But why are we supposed to make our own workarounds for PCFs inside views in model-driven apps, in case we need to create records?

Chaning the values and saving works in Canvas Apps and Custom Pages similar with Model-Driven view. But there might be small differences. For instance, I’ve worked with boolean column (TwoOptions). In model-driven views we need to set the value on 0 or 1
onChange(currentValue == 0 ? 1 : 0)
while inside CustomPage I had to set the “Id” on a boolean
onChange({Id: !currentValue})

Working with connectors

I love this feature. For instance we can use now dataset PCF to edit data from an external SQL table, and we don’t even need a Virtual Table. Just use a SQL Connector and edit the data with the PCF.

I’ve tried it out with an Excel table. Have a look:

The data get changed and saved. I can also add a new record, my excel get changed (but still have some refresh problems)


We don’t have to do anything to havce it working offline. The platform is making all the hard work for us:


This is a huge step! It’s a new dimension in designing the PCFs! I love it! What do you think?

Photo by John Adams on Unsplash


10 thoughts on “Editable Dataset PCF: New SDK Methods

Add yours

  1. Fantastic! When any changes are performed, updateView will be triggerd?
    And will it work on the complex view source? Such as EntityA linked with EntityB, can the function support to edit EntityB’s attribute?

  2. Hi Diana,
    thanks for the great work!
    Just found your blog and can’t stop reading!

    I have two questions about Dataset PCFs and I don’t realy know where to start:

    I want to create a custom editable grid.
    Editable field types should be “Two Options”, “Text” and “Optionset”.
    Do you have an idea if the save method works with other field types, then shown in your demo video?
    Second question is if it’s possible to define sticky columns for a PCF grid to have maybe the account name persistent when scrolling horizontally.

    Maybe you have some experience with those topics?

      1. Thanks for the update, we will try it out.
        I will keep you posted about our results.

        Thanks for the quick reply and keep up the good work!

  3. Great info!
    I’m thinking about extending the model driven grid to allow for inline create and delete records (via PCF of course)
    Any idea on what approach to take in this case?

    1. Sorry for the last answer… Just saw your question.
      Taff question. The easier way is to use the ribbon for delete and create (creation through quick create) and then refresh the grid.
      If you want to include it inside the PCF, you could use webAPI to create/delete the records, and refresh the grid after that…

  4. Hi Diana,
    I got into a trap with the “save” and “setValue” functions. Basically, the getValue function works using the name defined in the manifest, and, as a consequence, I thought it would work also for the setValue method.
    Actually, you get a strange error message from the internal javascript operation if you don’t use the Dataverse internal name.
    You can see more details in the GitHub issue below:

    I hope that this can save someone else’s time when working with these functions. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Website Powered by WordPress.com.

Up ↑

%d bloggers like this: