Custom field rendering in modern list views


Hi SharePoint Developers,


We're working hard on making modern lists and libraries more extensible.  One feature that we're working on right now is a SharePoint Framework component that allows you to customize the rendering of fields inside modern list views.  In other words, this is a modern version of the classic Field.JSLink extensibility point.  We want to work with you guys on fleshing this out and enabling real scenarios that are currently blocking modern adoption. 


We'd like to gather more real-world examples of how people are customizing fields inside list views today.  Please help us out!  To get things started, below are a few field customization patterns that we're aware of and are considering how we can make them work with this new framework component.   We want to hear from you examples of scenarios that fit one of these patterns as well as scenarios you've encountered that are totally different.


Conditional formatting.  This is applying a different style to a field depending on its value.

Example:  I have a number field in a custom list called "KPI."  I want values between 0-20 in this field to be shown in the list view as red; 21-40 as yellow; 40+ as green. 


Supplementing the output of a field with more information.  This is displaying additional data inside a field alongside the data that's displayed by default.

Example:  I have a person/group field that stores contact information.  I want to display the name of the person's division next to their name.


Inserting links to actions.  This is placing links to actions on a list item within that list item's row.  Think of this as like a URL-based customaction, but the action is invoked by clicking the action's URL in the view instead of selecting that item and clicking a button.  We've heard that sometimes it's easier to train people to click a link in a row than it is to train them to select the item and find the right button in our menus.

Example:  I have a field in a document library called "Kick off Approval Workflow."  Client side code constructs a URL that kicks off an approval workflow (in SharePoint or in another system) for the item in question and places that URL inside that column.


40 Replies

The modern version of the classic JSLink is definatelly important feature for my cusomers to use modern lists and libraries.


An example scenario for JSLink today:

väljastatudarved.pngClient has a list with project data and there's a column for the budget (maksumus). Project budget will be filled partially every month. With JSLink there is a link and a table to insert and display monthly payments. Total amount of monthly payments are calculated to Total field (Arveldatud summa).

I know, its quite trivial, but similar scenarios are very common where I need to display data from another list in dispform.aspx or editform.aspx.


I hope my example will help to develop modern version of the classic Field.JSLink.

Good luck!

So you are **not** going to allow generic Client Side Rendering/Display Templates/JSLink scripting
as was implemented in SharePoint 2013.

But instead, you are working on a technology to only allow specific scenarios?


I would like what you described

+ interactive elements ("Who needs Forms?") like de CSR library:


I would like to continue working with the CSR editor Andrei Markeev developed: (the best thing since sliced bread)
Cisar editor:

Generic scripting is powerful, but it tends to be fragile - customizations tend to break when we change our default UI.  Just ask our support team!  So we want to focus more of our efforts around making specific scenarios work in a robust, guaranteed way.  We want to build developer contracts that ensure certain scenarios (and scenario patterns) will work consistently as we make continuous updates to the service.  


All that said, we have definitely not precluded giving developers the ability to do generic JSLink/CustomAction scripting on our pages - but we're trying to figure out how far we can get without doing that.

Interesting word choice and double negatives refering  to double negatives. Are you sure you are in a Dev team and not from Legal?
I am not a native speaker, so interpretation took some minutes..

So, the answer is: Yes, Microsoft is working on scenarios to NOT allow generic scripting.

I have no idea how you want to support certain scenarios only without customers beeing upset again. I am pretty sure you still remember very well what happend when you released the modern document library.


But I think it is a very good idea to ask the community before the rollout this time. So thank you for that! Now I only hope that you will think again about the idea to support certain scenarios only. A generic solution will be much better....


Here is a very good list of what people have been doing and what was possible with jslink in the past:


If you can support all those scenarios, I think you are on the right track!


But most of those MSDN Client Side Rendering examples are .... okay I'll be nice because you can't expect all "Programmers" to understand WebDesign.... not really smart 


What a Fronteer wants is to be able to use the standard Browser technologies.

Why (For G. Sake!) create HTML and apply styling with code if the Browser can do it for you ???


 That means we need to be able to set HTML5 Data-Attributes on DIVs that make up the rows/cells in the Modern Experience "Tables"

All we need then to color a whole row is a CSS selector like:


TR [data-priority*='High'] {




Note: this idea/application is now (C) Danny Engelman


So NO Microsoft!
Do not built this as a "scenario", because I will sue you
We want 100% JavaScript access in the Modern Experiences

Danny, what you are proposing is what we are planning on building.  Through a stable API, we plan on making available the DOM elements that contain list view fields, so you don’t have to search for specific elements via ID, attribute, etc.  Once you have the DOM element, you should be able to do anything you want to it.


The reason we talk about this work in terms of “scenarios” is because we plan on being pretty selective about which DOM elements on modern pages that we support being accessed and manipulated in this manner.  We will start with a small set and enable more and more as time goes on, based on feedback from the community about the customization scenarios that are necessary.  The reason we’re doing it this way is because we want to guarantee these customizations will work going forward as we evolve our UX. 


We are aware that once we give developers the ability to place custom code on pages in SharePoint, the developer has access to every DOM element on the page, not just elements that we provide through our stable API.  However, we don’t guarantee good results if you take advantage of this; these customizations tend to break when the product team makes changes to the out of the box pages and controls.  This is really nothing new – it has always been the plight of the SharePoint developer.  The difference is that today, we’re trying to give developers better options in the form of scoped APIs that allow you to create customizations that are robust against future product changes.  If the scoped APIs don’t do what you want right away, you can either give us feedback and we’ll try to build the right APIs in the right order to address most common needs, or you can try to do things the “old way” with all the known caveats.

>> If the scoped APIs don’t do what you want right away, you can try to do things the “old way” with all the known caveats.


Is this the Classic mode option or can we apply scripts in Modern Experiences?


At the moment all my clients are forced to use Classic mode because I am unable to give them what they want,

in Modern Experiences.

I am not doubting technology choices

I am faced with Clients who have had nice colored tables and Priority fields since SP2013,

moved to the Cloud and now want those in SPOnline too.



I have actually lost a Client because she wouldn't believe me it wasn't possible in Modern Experiences,

she said a MVP at a conference told her Everything was possible now with React.

I am not an MVP with all the insights, priviliged information and a year headstart in all this,

I am just an a*hole trying to making a living in a market in flux.


So, Yes, I rant and shout and curse 





You rant and shout and curse?  I hadn't noticed!


We are talking about custom script in the modern UI here.  The custom scripting story for classic UI is unlikely to change too much going forward.


Dont't forget to include promises for getting field value when saving, e.g. on saving I need to get other field value and then recalculate using values from other list.




Hi there,


Ability to trigger async refresh of a view would be much needed. For example clicking an action on a list item opens a dialog and on dialog close you need to load the new values in the view without reloading the page.


Alex M.

Hello Lincoln,

Thanks for the great efforts of checking the community for the featuresand ensuring supporting the most prevalent scanarios in the modern UIs.


In my shop we are on Office-365 and Sharepoint Online. I had couple of naive queries.


a) We migrated from on-premise SharePoint 2010 into the Office-365. I see some of the lists has conditional formatting and the conditional formatting reflect fine in Office-365 as well.  I am not sure if the vendor who helped migrate to Office-365 did any manual tweaks in the code to have the conditional formatting remain as is.  I was trying to find out if there is a way in office-365 and SahrePoint Designer 2013 to conditional format the columns.  Although I see the conditional formatting working in lists, but I am not able to figure out how the conditional formatting was put in place for this list. The SharePoint Designer 2013 doesn't have any conditional formatting options (although SharePoint Design 2010 had those option I assume). Please correct me, does SharePoint Designer 2013 not have the conditional formatting options? I must be wrong, please guide.


b) To achieve the conditional formatting in Office-365 I was contemplating the option of putting HTML code in the 'formula' of the field (instead of modifying the out of the box HTML code using SharePoint Designer 2013). e.g. to color a field 'A' based on the values from field B, put an HTML in the 'formula' of field 'A' as below:

="<DIV style='background:"&IF([B]<15,"lightcoral",IF([B]<30,"yellow","white"))&";color:black;font-weight:bold;text-align:center'>"&[B]&"</DIV>"


Is this option safe and advisable to use if the point (a) above is true and we don't have yet the other "out-of-box" means to do conditional formatting in Office-365.


c) With the recent Office-365 release in April, 2017, one of the user expereienced an 'unwanted' UI change and I was not 100% certain if this is release related. Please see here


Many thanks.





Is this the right room for the old Calculated column HTML render trick?


It was lovely being able to dynamically render a JS button or an HTML link in a SharePoint column and would dearly love this to be made available again please? It was so easy and provided many solutions.

Yes - we're working on a new, improved way to accomplish those same tricks that isn't, at the same time, a way for site contributors to put arbitrary script on list view pages.  We will announce more in the next month or two.

Hello @Lincoln DeMaris

Thanks for guidance. Are there plans for SPD 2013 to have the conditional formatting options like the one available in SPD 2010 ?


In SharePoint Online, for conditional formatting we tried putting HTML code in the column's "formula" field and it does work. From the overall stability point, is this "work around" advisable or are there other preferred techniques I should read about first. At our shop (being small setup) we follow the policy of 'no customization' to out-of-box features, hence wanted to check what would be best for us in the meanwhile SPD 2013 has all the features.


Appreciate the guidance.

We do not have any plans to add functionality to SharePoint Designer.  We're working on some in-browser stuff for specifying field formatting for modern list views.  Scenarios that are top of mind for us:

  • Creating "action buttons" that point to a parameterized URL based on metadata on the current item
  • Conditional formatting
  • Severity coding - highlighting items that need attention
  • Lightweight data visualizations, like data bars and trending indications

Anything else come to mind?


For the time being, if you want to accomplish this stuff, you'll need to look at JSLink and CustomAction (if you're in classic) or the SP Framework Extension stuff that's in Developer Preview (if you're in modern)

Thanks so much for the directions. I'll checkout the JSLink and CustomActions.

Will add to list if anything else comes to mind. One thing a user asked recently was to see the 'Modified Date' in classic date/time formats (like YYYY/MM/DD HH:MM), instead of "June 9" or "Few seconds ago" etc. I know the 'shaded' view shows dates in classic format, but in shaded view, I vaguely recall there were other features which were not desirable. So the "display" of date could also be customized within the "list settings" or "site settings". I know there is one setting at the "collection level" but that impacts the whole organization.

So, I'm sure someone else has already spotted this, but if I create a new page with the modern UI and add the Lists (preview) webpart and select my list with the calculated column in it, my button renders!!! If inspect the element the URL is correct, however if I click the button itself it takes me to the item form rather than the URL defined in the HTML. Bizarre and inconsistent behaviour. Capture.JPG


Anyone else seeing this and even better, explain this???

You're right. This will be fixed in the service in the next two weeks.