PowerAppsPuzzle: @ vs # == Cryptic Error

Hey folks!  We are back with another PowerAppsPuzzle this week. This time we are trying to track down the source of a very cryptic error message. I am working on a solution for a PowerApp that integrates with SharePoint Online and for this particular solution I cannot rely on the built in form functionality that we get when using the wizard — “App from data”. So this time I had to manually create the form by adding controls to a screen and then using the Patch() formula.

As of the time of this blog post, some of the functionality is still evolving and in order to Patch() a SharePoint list that contains certain fields — like Choice, Lookup, Person — you need to supply some extra context in the form of records. Here is one example:

Color:{'@odata.type':"@Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",Value:Dropdown2.Selected.Value,Id:LookUp(testCollection1,Title = Dropdown2.Selected.Value).ID},

So in the sample code above, I’m attempting to patch a SharePoint list that contains Title (single line of text), Color (lookup), and Manufacturer (choice). A simple field like Title is easy enough, you simply pass the data you want to update in that field. For the other two fields we need to define more information. So for Color, we pass the @odata.type in addition to the Value and ID.

There are plenty of blogs and samples of how to do this, but whenever I executed Patch() I was greeted with the following error:

The requested operation is invalid. Server Response: A value must be provided for item

Well… this wasn’t very helpful in and of itself so I started scouring the net and stumbled on the following discussion thread: https://community.powerapps.com/t5/PowerApps-Forum/Not-able-to-Update-Dropdown-value-to-a-sharepoint-List/td-p/13550

Towards the end of the thread is where I found my solution. I’m curious who has seen it in my sample code above? The corrected code is:

Patch(Cars, Defaults(Cars), {Title:TextInput1.Text,
Color:{'@odata.type':"#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",Value:Dropdown2.Selected.Value,Id:LookUp(testCollection1,Title = Dropdown2.Selected.Value).ID},

In case you still miss it (as I did for quite a while). The key is in the @odata.type. The actual value should be prefaced with ‘#’ instead of ‘@’. One of the reasons this was such a challenge is that it wasn’t flagged as a syntax error.

Hope this helps someone else along the way!

Happy PowerApping!


Implementing Managed Tabbed Navigation with SharePoint – Part 1

Recently, I changed roles and have more opportunity to work in areas that have more of a development slant to them. One of my customers recently wanted to convert their Intranet portal into a more friendly navigation experience on SharePoint 2013. They also want it to be responsive, but we’ll tackle that later.

I’m going to break this post up into a series of posts due to the length and number of topics:

Part 1 – Basic overview of implementing Tabbed Navigation with SharePoint

Part 2 – Investigation into the necessary CSS classes and HTML structure for Tabbed Navigation

Part 3 – Explanation of the JavaScript to render the HTML from part 2

So in my discussions with the customer we arrived at a decision that they would be using Managed Navigation and they wanted it to be in a tabbed format similar to this:


I won’t get into Managed Navigation here, but suffice it to say that it’s a feature that was added to SharePoint 2013 that uses the Managed Metadata Service and terms that you define to provide navigation items. It’s highly dynamic and easy to change, if needed. SharePoint creates a control and adds it to the default master pages so you don’t really have to do much, but they aren’t very attractive out of the box.


There are a ton of ways to do any one thing with software development – some more efficient or better practice than others, but still a wide variety…this is simply the way I picked. Smile  I began by looking at Bootstrap as not only does it have easy to use classes right out of the gate for navigation (including tabs), it also makes responsive (the next thing we’d have to look at it) much easier as well. After searching around a bit for Bootstrap and SharePoint I happened to stumble upon some code from a fella named Tom Daly. He had already tackled a good bit of what needed to be done and code-reuse is a popular topic today, right?

Installing the code as downloaded from GitHub, we get a look like this:


Obviously this is not the result that any of us wants to see so using Tom’s code as a base, I had to tweak a little bit of the Javascript and some custom CSS to get the display that I wanted. The first thing that I wanted to do was to remove the out of the box Navigation using some custom CSS:

.ms-core-navigation, #DeltaPlaceHolderPageTitleInTitleArea, #DeltaTopNavigation {

That, at least, allows us to only see one set of navigation elements (and the ones we want, I might add). Next was to begin changing the type of navigation from Tom’s code from dropdown classes to using tabs. There are actually a lot of steps to this and that is why I’ll dive further into those steps in the next two parts to this series. I *highly* encourage you to review the code in Tom’s solution to understand the steps and ask questions in the comments. One of the important parts to understand is that using Tom’s code we make a call to the REST endpoint “/_api/navigation/menustate?mapprovidername=’GlobalNavigationSwitchableProvider’” and this returns an object containing the Navigation Nodes (all levels).

So stay tuned and watch for Part 2 of this series when I start discussing the CSS classes needed to get the layout that I wanted. (Including the somewhat embarrassing fact that my teenage son had to help me with part of it.)


CSS and Javascript


When Using SharePoint, Don’t Use $

Hey folks!

I ran into an interesting issue while onsite with a customer the other week and I thought maybe someone else could benefit from this. The scenario had to do with the Distributed Cache and we were trying to correct some issues that they had.

The basic steps were to Remove/Add the SPDistributedCacheServiceInstance using powershell (PS) in order to ‘fix’ it. When we executed the Add-* PS cmdlet we ended up seeing the following error:


This was most vexing as the user running the PS cmdlet was a Farm Admin and local admin on the server in question. I consulted with several of my peers when it occurred to one of them that the referenced path appeared quite interesting:


The actual user account was not test18172account, but was test$account. Now if you have done your homework, there is a specific supportability statement with regards to SharePoint service accounts:

Do not use service account names that contain the symbol $.

So there is a small bit of room for discussion about this since the article states “service account names” and in this scenario we weren’t using a service account. However, as it turns out this restriction apparently applies to accounts used running certain PS cmdlets.

As soon as we moved to another admin account that didn’t contain a $ everything worked as expected. So the morale of the story is to avoid using special characters in your account names — or at least $ (dollar signs).  🙂

Reposting the error in text for search-ability:

Add-SPDistributedCacheServiceInstance : Could not find a part of the path
At line:1 char:1
+ Add-SPDistributedCacheServiceInstance
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (Microsoft.Share…ServiceInstance:SPCmdletAddDist…ServiceInstance) [Add-
   SPDistributedCacheServiceInstance], CmdletInvocationException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletAddDistributedCacheServiceInstance