For as long as I can remember, SharePoint lists have kept a clear separation between viewing and editing. As soon as you needed to modify fields, you had to switch to a different screen, whether it was the grid view (Excel style) or a single item edit form. The alternative was to assemble your own layout, using a List View Web Part, InfoPath, programming, or more recently Power Apps.
A while ago, I also came up with my own solution, which I called the HTML Calculated Column (HTMLcc).. It later evolved to work with client-side rendering (CSR) in SP 2013. However, those classic approaches were sunset with the move to modern SharePoint and restrictions put on client-side scripts.
I had some tough years after modern was released, because of the huge feature gap. We were sent back to square one, with lists missing even the basics, such as form customization, templating, or calendar views. For many, classic lists were still the go-to choice.
Fast forward to 2021. Major changes have happened, especially in the past year. Forms can be customized out of the box, templates are back, and so are calendar views (well, month view for now), plus now board views. The integration with the Power Platform has matured, and you can today include a Power Apps form, a Power Automate flow, or a Power Bi report directly in your list customization. We also get offline access and half-baked mobile access (iOS but not Android, really?). A new branding reflects these changes, we are now calling them Microsoft Lists and they can live in SharePoint or OneDrive.
And now the cherry on the cake: setValue.
With this newfound ability to mix read-only and edit fields, view formatting is moving one step closer to what you can find elsewhere on the Web, or build with development frameworks such as SPFx. Microsoft Lists also become a more sensible alternative to Power Apps for simple scenarios.
One downside I see to this action is that it’s pure UI and doesn’t validate the user’s actual permissions. If you have read access only, or item level permissions are turned on in the list settings, you’ll still see the button and get an error message when you click. Personally I can live with that.
But how about Power Automate buttons?
Before setValue was released, list formatting already offered a custom action called executeFlow, allowing you to trigger a Power Automate flow. While the action itself is much more powerful than setValue, it has a major drawback from a UX standpoint: the delay between the user click and execution. While update and UI refresh are almost instant with setValue, it could take a few minutes for the flow to run and the change to be reflected in the UI.
I recently demonstrated setValue to someone who was new to list formatting. Much to my dismay, he was not impressed at all by the new capability, simply because he considered it the normal way things should work. And as you can guess he deemed field updates through executeFlow unacceptable… which from today’s perspective sounds about right.
Try it out! Some samples spotted in the wild
Clearly I am not the only one excited about this new action, and some samples have already popped up in the community. Microsoft MVP Tetsuya Kawahara published formatting for switches and checkboxes to the Github PnP repository. The above screenshot shows them in action in a turn-taking application I built last week. In my scenario, volunteers can come to the list and update their weekly availability (check the days they are in, or turn the Active switch off when they are out of the office). Power Automate flows run on top of that and assign action items to the volunteers available on a given day.
Michel Mendes published a sample with approve/reject buttons. Below a screenshot from his blog:
Another blogger, Dennis, published a use case for course registration.
Let’s not forget inlineEditField
Another recent addition, inlineEditField, allows you to make a specific field editable in list formatting. Also a convenient feature, for example to allow users to directly update a choice field like a status directly in the view.
inlineEditField will honor permissions, and only users with edit access will get on click the conversion to an edit control.
This open door to new dynamic behaviors got me excited like it was 2008 again, and I started brainstorming scenarios that go beyond simple row rendering. Hopefully I’ll have some creative use cases to share in the coming months! Just the few examples shared by the community in the past couple days show us how the new capabilities can help build simple apps with a more user-friendly interface, without the need for a bigger hammer such as Power Apps.