Are We on the Cusp of a Citizen Developer Revolution?

I ran across an article on ZDNet today entitled The advent of the citizen developer. In the article,  posits that we may finally be at the cusp of a citizen development revolution.


I’ve been arguing for years – in one way or another (See, for example, The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint) – that the citizen developers in any organization are the lynch pins to IT success. This gray area, where the work isn’t just configuration and isn’t “real” development has been critical to the success of SharePoint in many organizations for years. What we call it is less important than what it is: the lifeblood of technology use and success in the modern organization.

Unfortunately, the response from most IT departments is that these very capable citizen developers will simply screw everything up and – oh, no! – require support the IT department can’t provide. This attitude is truly at IT’s peril. Instead of being seen as having a customer service attitude, they become known as the “NO! people”. “NO!” should almost never be the answer; this simply sends end users off to use external tools, which are usually far better that what IT provides to the organization. Thus, the very security that IT claims to be protecting falls apart. The end users are happy, but only in violation of corporate governance, whether it is explicit or not.

When I speak at conferences I often talk about IT offering Functions as a Service (FaaS) to the organization. (For example, see slide 12 in my recent presentation at SharePoint konference 2016 in Munich Alternative Approaches to Solution Development in SharePoint and Office 365.) By providing a set of reliable building blocks, whether vetted external JavaScript libraries or internally developed functionality that citizen developers can incorporate in their solutions, IT simply must get on board with this work. Offering consultative services in support of citizen developers must be cheaper and more productive than not doing so in the long run, though I can’t point to a study to prove it.

Even Microsoft is starting to understand how important these citizen developers are. At the recent SPTechCon in Austin, Seth Patton, the Global Senior Director for SharePoint and OneDrive product marketing even had a slide in his keynote acknowledging that citizen developers *exist*, which is a HUGE step forward. If Microsoft is thinking about empowering citizen developers, shouldn’t you be?

Continued developer empowerment

‘Continued developer empowerment’ from Seth Patton’s SPTechCon Austin 2016 keynote

Here’s hoping that now and into the 2020s become the decade(s) of citizen developers, even though they have been around as long as there has been computing. If it weren’t for the dabblers and hobbyists inside organizations, we wouldn’t have evolved to the places we’re in now. These people are the ones who push the envelope in directions that makes sense to the business, not just to some power grabbers in IT.

Finding the Elusive ‘Set Up Groups for this Site’ Page

When you create a new subsite In SharePoint 2013 or SharePoint Online (Office 365), you have the option to use the same permissions as the parent site or use unique permissions.

Use unique permissions

Use unique permissions

If you use unique permissions, you’re taken to a page where you can set up the special groups for the subsite.

Set Up Groups for this Site

Set Up Groups for this Site

Generally, this is a “set it and forget it” page; once you’ve done what you need to do here, you rarely need to go back to the page.

However, sometimes you may decide that you’ve been too granular or not granular enough when you set the groups up. In that case, you may want to go back to the page and change the settings.

Unfortunately, the page is hard to find unless you know exactly where it is. Unless I’m missing it, there’s no navigation option to get back there in the UI. The fact that I can’t find it says that it’s at least too obscure.

If you need to get back to the page, navigate to your subsite and append this to the end of the URL:


So, for example, if your URL is

it would become

This is another one of those posts I’m doing so I can find the answer on my own blog the next time. I hope it helps you, too!

Looping Through Content in a SharePoint 2013 Site Workflow – Part 3 – High Level View of the Workflow

As I discussed in the first part of the series, my goal is to find all the sales opportunities in a Site Collection and process them based on their characteristics. To do this I’ve created a Site Workflow – SharePoint 2013 flavor – that makes a set of REST calls to traverse the Site Collection to get the items we want to process.

Site Hierarchy
I’m working in a Site Collection with a fairly simple hierarchy, most of which I inherited. There’s a root site, of course, then a number of subsites – one per business partner – and one subsite for application management. The workflow will run in the management site (only Site Owners are allowed in there) and reach out across the rest of the sites in the Site Collection.

Looking at the details of a workflow like this right off the bat is probably a little too detailed, so let’s look at a conceptual picture. If you’ve used SPServices or REST calls to traverse sites before, this may not seem too complicated for you. If not, it may look like a nice picture (maybe – the colors are a little much!), but otherwise not make a lot of sense.

Conceptual overview of the workflowWorkflow Steps

The orange boxes represent App Steps. App Steps are only available to us if we give the workflow app permissions, as we did in the previous article. We need the App Steps so that we can make REST calls into sites other than the one where the workflow is running. When I tried to run my workflow without setting up the app permissions, each of the REST calls (now contained in App Steps) failed due to an authorization issue.

Stage: Get Authorization info

The first thing we’re doing is getting a digest token, which amounts to a way to authenticate the workflow when it does writes back to any of the lists. When we read information in the workflow, we don’t need this authentication info, but we do if we want to write anything. I’ve included the step in my workflow because I’m pretty sure I’ll want to be able to update some of the sales opportunities based on their status.

Stage: Get Webs

The next stage is where we make a REST call to retrieve the list of subsites (also known as Webs) which sit directly below the root site of the Site Collection. To do this, I need to make a call to the Webs REST endpoint. This is why we needed to set the workflow up with app permissions at the Site Collection level.

Stage: Process Webs

Once we have the list of subsites we can loop through them to process them.

Loop: Process Web

This loop contains the logic I use to process anything I need within each subsite. In the first few actions in this loop, I parse out the details about each subsite (title, relative URL, etc.) into variables.

Step: Process Opportunities

Using the variables I set up in the beginning of the Process Web loop, I make a REST call into the subsite to see if the Opportunities list is there and has sales opportunities in it which meet our criteria. (For example, we might filter out the opportunities which are already sold.)

Loop: Process Opportunity

If I do get a list of opportunities back from the call above, I process each of the individual opportunities in the Process Opportunity loop. This loop is where the “meat” of the workflow lives. All of the other steps simply exist to get us here so that we can take actions on each of the opportunities that meet whatever criteria we have defined. As the business process gels more (we’re designing it as we build the workflow), we may end up with multiple loops like this. For instance, we could have one loop which sends out emails about opportunities that are late; another loop to alert the sales team about big opportunities of note; and another loop that bumps up the commission percentage based on the quality of the opportunity, etc.

Building and Debugging

Thinking through how your workflow should work at a high level like this is sometimes useful. I’m more of an iterator, though. I tend to build one part of things and test it, then bolt on some more logic and test it, etc.

One thing I’m a huge fan of is emitting some sort of debugging messages along the way. This probably harkens back to the good old days where that was the only debugging technique we really had.

In any case, each of the phases, steps, and loops above emits something into the workflow history list using the Log to History List action.

Log workflow messages

As I build up the workflow, having a clear log of what’s happening in the workflow history list is a great debugging tool. The screenshot below shows the kind of thing I tend to do.

Workflow log messages

In this case, I can see that I found 15 subsites. Then when I processed the first subsite, I found 3 opportunities to work with. For each opportunity, I can see the customer name (this is test data, of course!), and so on.

The workflow will get more and more complex, but by emitting these messages, I have a fairly decent way to see what’s going on. Debugging these workflows is not a lot of fun – it’s slow going and sometimes hard to see what’s gone wrong – but at least I can look at my log and see where things might have failed.

In the next few articles, we’ll look at each of the phases, steps, and loops I’ve outlined above to see what’s going on in more detail.

SharePoint: Enabling Knowledge Management

I had the chance recently to have chat with TechnologyAdvice’s Josh Bland (@JoshBlandTA). This interview was a part of the TechnologyAdvice Expert Interview Series. The series explores a variety of business and technology landscapes through conversations with industry leaders.

There’s plenty of great content there, including interviews with some of the speakers for the SharePoint Technology Conference – SPTechCon Austin – coming up February 21-24. If you register with code ANDERSON, you’ll get an extra $200 off any other discounts you might receive.

In this episode we discussed how I see SharePoint fitting into a successful knowledge management strategy, how modern work happens, big things that happened with SharePoint in 2015, and of course, the upcoming SPTechCon. If you enjoy this interview, you might want to check out the one I did with Josh last summer, just before SPTechCon Boston: Software Adoption: A People Problem, or A Technology Problem?

Below is an excerpt from the conversation:

Josh: What would you say, Marc? How would you sort of summarize the year? What sort of big developments occurred and what would you say were some of the highlights from 2015 in SharePoint?

Marc: One of the biggest things is that the hybrid story that Microsoft is just telling is getting richer and richer. We saw some capabilities that are available on Office 365 starting to filter back on Premises, and that’s via hooking up to a SharePoint online instant. So that you can sort of take advantage of the best of the cloud but still keep your content in-house. And of course, we’re seeing tremendous strides forward in Office 365 as well. It’s hard at this time of the year to look back and try to remember, how many of these things actually got stuffed into this one year? And it’s pretty incredible when you look at how many things have changed over the last year in the SharePoint space. We have things like Delve and groups and the video portal, and all these things that have really come into their own this year and shown that Microsoft is not sitting still, that they’re — I’m very bullish on Microsoft in what they’re doing with Office 365. And I’m not an easy one to convince [chuckles]. But I see them doing some very cool things – Planner – just all kinds of new experiences as they say, with fantastic user interfaces that really are bringing the whole platform ahead in leaps and bounds.

Josh: I want to hear what were some of the sort of difficulties that you have experienced, not only with your customers, but just in general that you think the industry has seen from SharePoint?

Marc: An ongoing challenge for anyone using these platforms is that the development story continues to evolve. And that’s not a bad thing, but for your average developer who’s trying to sort of swim with both hands tied behind their back, sometimes, keeping ahead of what the enterprise wants, it’s difficult because we look at the different– historically we’ve had features and solutions, we’ve had the sandbox model now. We have the apps crossed out, add-in model, and we’ll probably see some evolution from here. People are continually having to keep their skills fresh. Now, that to me is a damn good thing. Anybody who stops learning and thinks that what they know now is going to serve them forever is sort of letting themselves die intellectually. The fact that we have to learn new things all the time is a good thing. We’re seeing an evolution from server site code toward JavaScript and client site code to a degree that is really — it’s been a bumpy ride for some people over the last couple of years to make that mental switch. As we’re seeing better experiences coming out of Microsoft, we’re seeing these challenges for the developers inside enterprises who are trying to build bespoke functionality that is unique to that organization, or something that that organization wants that Microsoft does not provide exactly. It’s that 20% that’s actually the hard part. That’s going to be an ongoing set of challenges – understanding how this hybrid model, as you mentioned fits into the organization’s ethos – is going to be a tough one for a lot of people to get to.

Two years ago we would have been talking about the tremendous fear about security and, “Does the cloud make sense?” And, now we always talk about it as, “Which part of the cloud makes sense to me? Which parts should I take advantage of? Where am I going to get the bang for my buck?” So, we’re on a different part of the learning curve for all of that. But the development story is tough. And that hybrid aspect just adds a little bit of complexity to the whole thing.

Josh: One final question here on SPTechCon 2016. Do you see a lot of differences between Boston and Austin? All that to say, what do you think will be different about this year, Austin 2016 vs. Austin 2015 or Boston 2015?

Marc: The obvious difference is that we’ve got SharePoint 2016 coming up. So — Yeah, new software smell. There are a couple things there. One is obviously there is some new software out there; new bits. So, people will be able to hear some good information about what’s there, why would you be interested in it, how does it work and that sort of thing. One of the best things though about SPTechCon is that they’re very careful to manage the mix between: here’s the shiny new stuff and here’s that stuff that you are actually still stuck working with [chuckles]. There are still a lot of people in the crowd who use SharePoint 2010, there’s still a lot of people who are using 2013 obviously. There’s a great mix of content across that spectrum as opposed to just going for the new stuff. Go to the Microsoft conference for that. They’ll only talk about the new things. But SPTechCon has been traditionally very good about having that balance, so that everybody who comes to the conference gets a lot of depth out of it.

This podcast was created and published by TechnologyAdvice, an Inc. 5000 company looking to help buyers find the best cloud storage, payroll systems, and more. Interview conducted by Josh Bland.

Looping Through Content in a SharePoint 2013 Site Workflow – Part 2 – Setting Up App Permissions

Site Workflows are great, but if you want them to reach across into other sites you’ll probably have permission issues. By giving these workflows App Permissions, you’ll be able to let your workflow access content across your Site Collection.


In part one of this series I described the basic task we’re trying to solve. We want to create a SharePoint 2013 site workflow that can iterate through subsites and then take some actions on each item that meets some criteria. At the end of that article, I said that the first step is that we’ll set up the workflow with proper permissions so it can traverse content across the Site Collection. So now you’re thinking, “Great. The problem is defined. Let’s pop over to SharePoint Designer and create a workflow.” Unfortunately, that isn’t the right thing to do. I know because I tried that, and I’m writing this series to pass on the lessons learned.

Before we can even think about writing the workflow, we should set up the authorization side of things. It wasn’t enough to get the digest token from the server for the REST calls. (More on this later.) When I tried to make the REST calls I needed from one subsite into the root of the Site Collection or another subsite, I got authorization errors.

Instead, there’s more heavy-duty permissions set up required to make the REST calls into other Webs (sites to normal people). We need to give our workflow App Permission, which isn’t obvious as you’re working on the workflow in SharePoint Designer (SPD), nor is it possible to do so in SPD.

Luckily I have good friends in the community. Matt Bramer (@ionline247) was the first person who replied to one of my tweets, and he gave me some good tips. Through him I found that Fabian Williams (@fabianwilliams) had written several blog posts about the trials and tribulations he went through so that I  wouldn’t have to. (I added links to Fabian’s blogs at the end of this article.) But setting up workflow App Permission is still confusing, in my opinion.

You’ll go through two two main steps to set these permissions. I found the steps generally documented in the MSDN article, Create a workflow with elevated permissions by using the SharePoint 2013 Workflow platform, but here’s my version.

Step 1 – Allow the workflow to use app permissions

Go to Site Settings in the site where you want the workflow to run and turn on the Workflows can use app permissions feature. You can do this by going to Site Settings and in the Site Actions section, choose Manage Site Features. Toward the bottom of the list of available features, you’ll see Workflows can use app permissions. To activate it, (figure 2) simply click the Activate button and wait for the activation to complete.

Workflows can use app permissions

Figure 2: In Site Settings / Site Actions / Manage Site Features you need to Activate the feature to allow workflows to read from and write to all items in the site.

Step 2 – Grant full control permission to a workflow

This step gets pretty weird. We have to give this workflow the permissions to run as if it’s an app add-in. (Though one might say that it’s an app add-in already – everything is an app add-in, right?)

In the site where you want the workflow to run, navigate to Site Settings and then under Users and Permissions, go to Site app permissions. If things have gone according to plan, you should see Workflow as one of the two or more items listed here.

What you want to grab is the yellow text in figure 3. It follows a bar character – “|” – and precedes an “@” character. I’m not sure exactly where this GUID comes from, but it’s what you need.


Figure 3: Copy part of the Workflow App Identifier

Now you have to navigate to a hidden, super-secret page at:


In the example on MSDN, they send you off to the /sites/AppCatalog Site Collection for this. That’s only because they are showing an example interacting with a list there. You should go to the secret page in the Site Collection where you want the workflow to run. (Yes, I was down a rat hole on this for a while. Maybe I was just being stupid. It seemed like the good folks who wrote the MSDN article were telling me I needed to give permissions on the App Catalog site for this to work – but that wasn’t the case.)

The should look something like figure 4. The page doesn’t have a title like most SharePoint pages (hey, it’s super-secret), but the hover text for the info icon at the top of the page says “Grant permission to an app.”

Set the app permissions

Figure 4: You’ll paste the Workflow App Identifier into the Add Id field on the secret page.

Now as you can see in figure 5, you paste in the yellow text from above, and click the Lookup button. The next three fields will be filled in. You shouldn’t need to change anything in those fields.

Paste in the App ID

Figure 5: Paste in the App Id that you copied from the workflow in Site app permissions (figure 3).

Next, you need to paste some XML into the last field called Permission Request XML. Don’t try to get all smart about it like I did: paste in EXACTLY this XML— don’t make any changes.

You have two options here (the first option adds /web in line three) and I’ll explain the difference below the XML snippet:

  <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />


  <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />

In this case, I went with the latter; I want my workflow to have permissions on the entire Site Collection. The former would give my workflow permissions only in the subsites of the Site Collection; I needed permission on the root of the Site Collection because I wanted to iterate through the subwebs (subsites) from there. So with both the App Id and the XML pasted, the app identity and permission look like figure 6.


Figure 6: We’ve identified the workflow’s app’s identity and indicated where it has permissions to be used.

Click Create.

Next you’ll be asked if you trust the workflow. One would think this would be a given, but click Trust It.

 Site App Permissions

At this point, you have the permissions set up that give you the possibility of looping through the subsites off the root, even though you haven’t created an actual workflow yet. (Or, if you’re like me, you beat your head against the workflow first and then realized you had to figure this part out.)

In the next article, we’ll talk through what the workflow needs to do on a high level to be useful.

References for this step

This article was also published on IT Unity on 1/25/2016. Visit the post there to read additional comments.