Tag Archives: JS Link

Top X Things Needed To Make PowerApps Awesome for SharePoint

While chatting about PowerApps recently, someone told me that I should always know my ‘top x’ things I want fixed, added, changed, etc. I can see where that might be handy to talk about with Microsoft, with other implementers, etc. It’s a quickly changing community and product and hey, they *are* listening. For PowerApps my current focus is on how it integrates with SharePoint. With that in mind, here’s my top 2. I’ll come up with more later. These are the ones I think are *really* important. 

  1. Embedded
  2. Embedded

PowerApps has great potential and already has a running start. But it has to nail the embedded story. If the integration of SharePoint and PowerApps is going to be *really* successful and gain the love of SharePoint users it needs to be easy and seamless. That means when a user selects a PowerApp in SharePoint it’s not going to jump to another application. It needs to run within the SharePoint interface.

So why do I list ‘embedded’ twice? Not because I really, really want it (I do) – but because there are (at least) two distinct embedded use cases:

Embedded Forms

EVERYONE has been talking about forms – which is well and good. They should be talking. They should (and have) been yelling. The gap is obvious and a solution is WAY overdue. With the scheduled end of InfoPath and the rudely unscheduled end of SharePoint Designer’s (SPD) visual designer, users have been left with one of the community’s longest and most obvious gaps. Thanks to third-party offerings (K2, Nintex, etc.) and community-efforts (Stratus Forms, etc.) certain needs have been met, but there are still gaps and it’s been far too long for a Microsoft-sponsored solution for business and power users.

Note: I don’t want this coming off as an anti-Microsoft rant. That is definitely not my intent. There were plenty of reasons for the delay. What they want to do and need to do is not trivial and the standards are extremely high. The integration we’re talking about also requires collaboration (see what I did there?) between two separate, complex, and rapidly changing products and teams. The PowerApps and SharePoint teams are also in different reporting structures within Microsoft. Fortunately both teams understand how important it is to get this particular integration done. The good thing is that there are many indications that this time around they’re going to make it – and maybe even exceed your expectations.

PowerApps needs to be able to replace existing SharePoint forms – the standard New, Edit, and Display forms – as well as add additional forms to a list or library. Form editing needs to be easy and intuitive in terms of which fields are displayed, how fields are laid out and formatted. Beyond that, there are plenty of other features we’d love to see, but the ones listed here are the core. Talk to anyone that’s used InfoPath or SPD and you’ll quickly get a list of wanted features.

We have every indication that Forms and the embedded experience will be addressed. Microsoft has gone as far as announcing that PowerApps IS the replacement for InfoPath. It is important to remember however that the features are coming iteratively, little by little, but continuously. So be patient.

Embedded Views

The embedded story that folks aren’t talking about as much is for Views. SharePoint views have historically been a powerful tool for business users. And while they are powerful out of the box, power users continue to find that they’d like to extend views beyond the out of box capabilities, and extend without involving developers when they are able.

Again, power users were once able to do some limited, yet still extremely useful, view customizations with SPD, but lost that power with the deprecation of the designer view. For the last few years, some customizations were again available using Client-Side Rendering (CSR) and the JS Link property of web parts. While extremely flexible, this approach was beyond most typical business users as it crept into a grey area between out of the box and ‘real’ customization and development. The approach never gained mainstream support or adoption. Now, as O365 continues to mature and lock down features that have the capability to jeopardize platform stability, CSR and JS Link are also going away from fringe power users and exclusively back into the hands of developers (good for the platform, unfortunate for those that were using it). 

Users need a way to get the benefit of SharePoint views, specifically choosing a list of fields, the order of the fields in a grid or spreadsheet format, the filter for the list of items, and how they are sorted. Once those core features are available they’re going to want the ability to customize that view using PowerApps’ ability to change field formats, apply conditional formatting, and other rules.

PowerApps today are surfaced in O365 SharePoint Online via the view dropdown.


Selecting one of them initiates the loading of a PowerApp, but only give the user a button to open the PowerApp – opening the client application.


Embedding the PowerApp would (hopefully) spin up a PowerApp right in the SharePoint window – just like any other view – rather than having to launch a client application – which is a fairly jarring experience for users.

I think there’s some interest in this use-case in the community, but it’s definitely less discussed than the forms example. I’m not sure what the interest level is, but I imagine anyone that was doing CSR and JS Link work would be interested in it. We’ll just have to wait and see.

#3 – A View Template

OK. So I did think of a third item on my list.

The current SharePoint template for PowerApps starts with a SharePoint list and creates a series of three forms in PowerApps. It would be great is there was a PowerApps template that took the selection a step further – into the current views for a list (or library) – and had a default layout that looks more like a traditional SharePoint view – a table/grid layout. This feature alone would allow SharePoint users to leverage their existing investment in views straight into extending them in the PowerApps interface. 


PowerApps is a powerful addition to the suite of tools Microsoft is making available for power users – many of which are currently using SharePoint. The PowerApps team wants to see user adoption grow and has a large group of potential users in the existing SharePoint user base – and SharePoint folks are an eager bunch. We’re already intrigued by the potential PowerApps brings to the table. If Microsoft is able to smoothly embed PowerApps into SharePoint (and Teams!) pages, users will be chomping at the bit to use PowerApps (and Flow) even faster than they already are.

Display Links to SharePoint Item Attachments using CSR

I had an inquiry this week regarding whether or not CSR could be used within a SharePoint list view to display links directly to an item’s attachments. It took a bit of tweaking code around a bit, but Raymond Mitchell (@iwkid) and I were able to get it working.

Background: SharePoint lists may allow for attachments to list items. SharePoint also has a default column that can be used in a view for displaying whether or not an item *has* one or more attachments. (Is that Clippy in disguise?)


A user experience (UX) stumbling block however is that you have to open up an item view in order to see the list of items and links to them. If you’re familiar with SharePoint, not a huge UX issue, but still somewhat irritating compared to just seeing the list of items in the view directly. If you’re *not* SharePoint-savvy, then you might not know at all whether an attachment exists or how to see attachments.

We’re aiming for something like this:


The CSR JavaScript file can be found here: CSR_ViewAttach.js

Note: I’m sure the JavaScript gurus out there will find more code cleanup that can be done and methods that can be used to improve it – this should get you started. We’ll add new versions as improvements are made.

Instructions for use:

  1. If you don’t already have one, create a ‘scripts’ document library on the Office365 / SharePoint site you’ll be using the CSR file on.
  2. Download the JavaScript file from here
  3. Edit the JavaScript file to work with your column, list and site URLs (see more in the sample file or below)
  4. Upload the edited JavaScript file to your ‘scripts’ library.
  5. jQuery is required for this CSR to work. If you don’t have jQuery already, upload it to the same scripts library. (See this post for more information on using jQuery with CSR)
  6. Add the Script Editor web part to your page or use the ‘Embed Code’ option to add a reference to jQuery.
    Ex. “<script language=”javascript” type=”text/javascript” src=”../Scripts/jquery-2.1.3.min.js”></script>”
  7. Your list: If you don’t have a ‘spare’ text column you can use to override in a view, create a new text column (ex. ‘ViewAttach’).
  8. Create a view for your list that includes your new column. You can still use all the same sorting, filtering, and other other view configuration settings for this view.
  9. When using your list view, edit the web part and add the link to your JavaScript file to the JS Link property of the web part. It will look something like: ~site/Scripts/CSR_ViewAttach.js

If everything is in place, attachments in your list should now be listed in the column you identified. (If not, check the common troubleshooting items for CSR… hmm, that sounds like another post…)

Items to configure in the JavaScript/CSR file before it will work in your environment (these are also noted in the file itself):

  • The (internal) name of field being overridden. In the example code below we’re using the ‘Body’ column (which is the internal name for the ‘Description’ field) of a task list. You can override any text field and/or create your own.
  • The siteURL variable.  — See example in the CSR file itself
  • The listName variable.  — The list that includes the attachments you’re displaying links to (example in file)
  • The attachPath variable.  — Link to where attachments are stored (example in file)

Thanks, Notes, and References:

Please let me know how this works for you!

JS Link – Using CSR for KPIs

OK. Someone asked me today if CSR and JS Link can be used incorporate KPIs into a list view. The answer of course is ‘yes’. This is a wonderful example of how CSR can be used.  Smile

Background: If you’re wondering what a ‘KPI’ is – it’s a ‘key performance indicator’. You can find more about them here: http://en.wikipedia.org/wiki/Performance_indicator   What we’re talking about specifically in this case is a visual KPI in a SharePoint list view – something that can be used as a quick visual cue as to what the data is showing.

If you’re wondering what CSR and JS Link are referring to, take a peek at my “JS Link – Hello World” article.

With all that settled, here’s a quick example of one way KPIs could be incorporated into a list view using CSR and JS Link:

  • Create a list (yes, you can use an existing list).
  • Add or identify a column that’s going to be used as a value to test.
  • Add or identify a column for where the KPI indicator can be displayed – a graphic will override whatever data might be in this field. The title of the column can be useful to indicate which KPI is being displayed…
  • Identify the locations of graphics to be used as the KPI indicators. I put mine in the Site Assets library for this example, but they could be stored just about anywhere.

Here’s the sample JavaScript:


Note: You can update the fully qualified links to the image to relative links:  src=”/TeamSite/CSR/…”  (still need the rest of the URL, but dropping the beginning part)

In the example code, we’re checking the value of one field and displaying the image in an override of a second field.

Again, this is an extremely simple example – the logic for the KPI could be much more complicated as needed. There could be one or more KPIs per item. Lots of ways to improve on the concept.

The example ends up looking something like this:


NOTE: For this quick and dirty example I created a field in the list that is essentially used only as a field to be overridden with an image. If I want to make the solution cleaner and more UX friendly I could do an Item override which would allow me to skip adding the new ‘container’ field. I could just bake the image into the rendered HTML directly.

Reference to where the images came from: http://commons.wikimedia.org/wiki/Category:Light_icons

Another much more complicated example:

Client-Side Rendering (CSR) demystified – Slides

At SPC14 – the SharePoint Conference 2014 – I initially presented a session on Client-Side Rendering in SharePoint 2013 as implemented using JS Link through the web interface. CSR and JS Link using uploaded JavaScript files and the JS Link web part property pointed at the appropriate JavaScript files – to be differentiated from JS Link baked into managed code.

The recording and slides for the SPC session are available here – on Channel9: http://channel9.msdn.com/events/SharePoint-Conference/2014/SPC318

This content has also since been presented (in slight variations of the original) at a few SharePoint Saturday events.

JS Link – Highlighting a Row with CSR

One conditional formatting scenario in SharePoint 2010 and SharePoint Designer 2010 was to highlight a row in a list view based on a rule: data within the item/row. SharePoint Designer 2013 unfortunately does not have the same design view available, so we need to use some relatively simple code to get the same results. This article discusses one method to get the same results using SharePoint 2013 with Client-Side Rendering (CSR) and the JS Link web part property.

Referring back to a few of my other posts you can get an idea of the general approach using CSR here:

When creating the JavaScript file this time we aren’t doing any Field or Item overrides, but we are using the PostRender functionality:


OverrideCtx.OnPostRender = {

As the name describes, we’re tweaking the page output after the rest of the page has been rendered. Using Field overrides we could alter the formatting of text, but not cells and wouldn’t have access to the row either. Using the Item override we could build the row from scratch and highlight the row, but it would take a lot more work rebuilding the view when we can just use the PostRender method to tweak the existing view.


I won’t get into all the JavaScript details but want to highlight what’s important to replicate this functionality on your own. The code essentially steps through each item/row in the table and runs the logic on each item.

There are only a few snippets you need to customize to fit your scenario:

if (listItem.Priority == “(1) High”) {

The code above is your condition / rule. ‘Priority’ is the column you’re checking the value on – remember that ‘Priority’ is the internal name of the column. You can use any column that’s included in the view for your rule criteria.

row.style.backgroundColor = “rgba(255, 0, 0, 0.5)”;  //red

This (above) is setting the row background color. You can set whichever color you need. You can have multiple rules checking different rows and applying various colors if you wish.

OK! Once the JavaScript is written and uploaded to the site (see other posts for details) and the JS Link property is set, if everything is working the list should now show a highlighted row for data that matches the rule:


Using the PostRender approach makes highlighting an entire row pretty easy. If you wanted to highlight a specific cell, it would be possible but would take some more code (we’ll show that another time) to get the right column selected. It’s not as easy as just calling out the column/field name. Depending on what you’re trying to accomplish on the cell/field level, that kind of change might be easier using the Field override.

Thanks again to Jon Campbell (MS), Raymond Mitchell and Phil Jirsa for hammering through much of the JavaScript details on this one. Jon clued us into some of these JS Link innerds back when he was on the SharePoint team. 🙂

SPC14 MySPC, Sessions and Schedule

SPC14 is going to be pretty darn cool. Looking at the sessions and how things are going to be organized is amazing. Microsoft is doing a great job integrating Yammer into the mix for this conference.

If you haven’t already, sign in to MySPC and then link your Yammer account to MySPC. Once you’ve gotten into the SPC 2014 network in Yammer, you’ll be able to search by session numbers to find session presentation information, slide decks, related links and files, etc. The Yammer network integration and ‘second screen’ experience is going to change how you experience the conference – before, during and after the event.

Be sure to check out the sessions you’re interested in on the Yammer network to properly set expectations for what you’re going to see during the presentations.

Here’s information about my session:
#SPC318 – Client-Side Rendering (CSR) demystified
MySPC Link | Yammer Link

It is a developer session and I will be talking about JavaScript code that applies to the web interface, specifically list views but also touching on forms. From a practical viewpoint the content I’ll be covering can be used by what I would call power users, citizen developers, etc. –> folks comfortable tweaking HTML, CSS and a little JavaScript given some guidance.

There’s more information available on the Yammer page. Log on, ask questions, participate in the conversation and I’ll see you on Tuesday!

JS Link – Hello World

JS Link and CSR (Client-Side Rendering) for SharePoint 2013 are often used interchangeably, but they aren’t exactly. The JS Link web part property is a way to add CSR template overrides to your page.

This quick post walks through a ‘Hello World’ scenario that doesn’t do any CSR, but makes sure your JavaScript file is working and that the JS Link reference can find it.

I’ve got a longer post on more of the details and use of JS Link for CSR in SharePoint 2013, but this is a quick ‘Hello World’ version for JS Link. There are three main components:

  1. Create a JavaScript file
    This file, saved as [yourFileName.js] literally only needs to have a single line:
       alert(“Hello World”);
  2. Put the file in a location where your JS Link reference can see it.
    • One common location to upload to is the Master Page Gallery though other locations can be used. This does require higher permissions on the site, however.
    • Using this ‘Hello World’ approach is a great way to test the location of your file, the permissions to that file and the JS Link string (next step) used to get everything working.
    • If you are a site collection administrator you can use SharePoint Designer 2013 to view ‘All Files’ in the Master Page Gallery and add a new JavaScript file that way.
  3. Point your web part to the JavaScript file.
    You are changing the properties of a web part here. Technically you can edit the web part of a standard view for a list, but I generally don’t do that.
    1. For this example create a page on the site and drop a web part from your test app (list or library) on to that page.
    2. Edit the page and Edit Web Part. At the far bottom of the web part properties, under the Miscellaneous grouping is the ‘JS Link’ property.
    3. Enter the following and click OK.
  4. If everything is working as planned, as soon as you click ‘OK’ you should get a JavaScript alert that says ‘Hello World’.

Now, you can start playing with CSR or other functionality with the JS Link. Check out my Primer post… more examples are coming shortly. Smile