Evangelism in a Hostile Land

It may be hard to believe, but there are still organizations out there where “SharePoint” is a dirty word. Maybe they haven’t upgraded, maybe–and this is worse–they do have a SharePoint Site but it’s been badly managed, acting as little more than a badly-setup document storage bin. Users see no reason to switch from their old, bad habits of email, PowerPoints, and storing files in their personal drives (because they know they can find it there).

That was the situation I found myself in when I switched to a new team. They had a Site (because they’d been told to use it) but after years of mismanagement, its faults were far too numerous to get into here; suffice to say, it shouldn’t be deleted but rather preserved for all time in the Museum of Worst Practices as every example of how SharePoint could be misused to prevent people from doing their work. Users were, to say the least, antagonistic towards SharePoint.

All I said was, “You could use SharePoint to do that,” I swear!

Now, they’re using Pages, Lists, and Libraries interchangeably, even customizing their own solutions. SharePoint is looked on as a tool to help them automate their work, not just a filing system. Less and less, I’m asked “Can you make me something to do x” and, instead, I’m told “Look at what I made that does x, y, and z!”

Here’s my approach to go from “SharePoint sucks!” to full adoption.

Step 1: Plan big

Step back and get the ‘lay of the land’, see how the team does their work. Observe existing processes and think about how to streamline them. Look…but do very little…because you have other work to do first.

Think about the end result for your Site and what it could accomplish, the Big Picture. Sketch out what the homepage might look like, what dashboards might be useful. Design a permissions architecture that fits the organization. Draft up some governance rules and policies for how the Site should be run; from then on, use those guidelines in everything you set up. These aren’t etched in stone, you can adapt them later, but it’s better to start with some guidelines and governance than to make them up as you go along.

Once you’ve got your vision of the Big Picture in place, move on to…

Step 2: Start small

Isolate a small sub-team or group within the team at large. Talk to them and get to know their needs, their processes, their inputs and outputs. What do they want to track? What could be automated? How can SharePoint help them?

Figure out how their work will fit into that Big Picture and now start planning. Design your SharePoint solutions for the sub-team with that in mind. What columns in their Lists might be useful to others…and make them site columns. What dashboards do they want that could, later, be trimmed to become the dashboard View at the manager level.

Also, when dealing with the small group, identify potential allies, people who ‘get’ what SharePoint does. With the right encouragement and training, these people can become your advocates later on, your points-of-contact for using and building the Site.

Once you’ve got a good design, get ready because it’s time to…

Step 3: Build small

You might think you want to ‘wow’ them, show off the full power of SharePoint, make them something so pretty and wonderful that they sing its praises far and wide. But a highly-customized solution with a lot of automation might make them wary of the big changes you create. So, when building your solutions, start simple and let them see the gears at work. Put away your javascript codebooks, close SharePoint Designer, forget you ever heard of InfoPath, set aside your content-types and workflows (for now).

You can usually start solving their big issues, the tasks that take up a lot of their time and effort, with a Page or two, a Library, and a few Lists with the right Views for the right purpose. Don’t shoot for a 100%, totally complete solution that does everything for them; aim instead for a simpler solution that they can grasp how it works. Make it vanilla, make it OOTB.

That doesn’t mean you should throw out every cool trick and elegant solution you’ve ever learned how to do. It just means that you should build small enough for them to see “behind the curtain” (The Wizard of Oz, 1939). It will be less daunting for them to use if they know what buttons to push and levers to pull to be wizards themselves.

SharePoint Designer, circa 1930s

Your subteam is set and starting to use their initial SharePoint solutions. Things are starting off well so it’s time to…

Step 4: Move on

Leave your initial group to do their work. You’re not abandoning them, you’re letting them simmer. Go on to another subteam and repeat Steps 2 & 3. Find out what they need and build them something small. Keep on doing this until you’ve got a few groups working on the Site.

After a while (few weeks? a month? hard to define), don’t forget to…

Step 5: Check back

Circle back to your first group. By now, they should be very satisfied with your solution because they can see how it’s helped them do their work. The old ways are happily abandoned in favor of automated displays and dashboards.

They’ll have suggestions, ways to improve their Site. They’ll also have populated enough data–files, items, whatever–that you can use to better ‘see’ their processes at work. Get them to draft up their SOPs for how they work now. Work with them (don’t forget your ID’d advocates! get them to help!) to see what could be made better. Ask them flat-out, “Dream big! What do you wish you had now?”

This is when you pull out the big guns you set aside in Step 3. Customize workflows, add javascript, dust off SPD and InfoPath. Start showing them the “wow” factors…unlike before, they’ll be happy to change their work processes a little because they’ll know, deep-down, where they’ve done the work themselves, how it can be better.

Keep working your way around, moving from subteam to subteam, until you’ve done enough to…

Step 6: Put it all together

The management level at the top of your whole team comes in, basically, two flavors (with variations, it’s a spectrum). One, they want know enough about SharePoint to get it implemented properly and quickly. Or two, they don’t know it at all and are hesitant to change what they do in favor of the latest “fad” (never mind that it’s been around for more than a decade!). Either way, you can’t leave them out of the loop with all of these steps that you’re doing. Just tailor your approach to their attitude.

With the first set of managers, it’s relatively easy. Give them regular updates. Show them how their subteams are working better and faster. The only caution is not to move too quickly; just as in Step 4, the whole team needs to simmer, to adopt SharePoint gradually.

With the second, assure them that the work is still being done. There will still be antiquated processes (daily emails! PowerPoint briefs! weekly activity reports!) to do and none of your subteams should stop doing those in favor of your solutions. After all, your solutions should be aiming at those progress reports as outputs, to make the subteam’s work easier.

Once you have enough to work with, make a manager-level Page, “One Page to Rule Them All” (The Lord of the Rings, 1954). Put in Web Part dashboard Views that display information useful to the manager. Build enough ways to drill down if they feel curious about how everything is going. Show it to them and explain how it can replace some of those old ways. Once they can see it in action, they’ll probably be more amenable when you push for further adoption of SharePoint.

Because you’re not done. Oh no, *wry chuckle* now you’ve got real work to do, it’s time to…

Step 7: Level up

Everything is modular. Nothing is ever truly finished. There’s always more work to be done. However you want to look at it, now that you’ve started bringing the team into a SharePoint future, consider the following:

  1. Formalize your Site governance by writing it up as a policy. Enforce it.
  2. All those Lists and Libraries you made in Steps 3-5? How can you use site columns, content-types, and workflows to make them more efficient and effective across your Site?
  3. Turn your advocates into acolytes. Train them to use SharePoint themselves.
  4. Documentation. Are you writing it all down? As more users adopt SharePoint and the changes start multiplying, do you have a good documentation plan built into your Site governance?
  5. More users, more data. And more headaches. Keep monitoring your Site to see what might’ve worked OK when it was small but is now a problem since it’s grown.
  6. The Big Picture changes, always. That vision you came up with in Step 1? Don’t be afraid to adapt it, tweak it, change it entirely. Be flexible!
  7. We are not alone (Walter Sullivan, 1964). Unless you’re a solo small business, there are always more teams, more levels (up/down/sideways) to deal with in your organization. How does your SharePoint Site fit into what they’re doing? How does your team’s inputs and outputs match up with their inputs/outputs?

SharePoint Workflow Best Practices

Note that I will add some screenshots in the near future.  Comment if there is something that I should expand on.

Automation is key to streamlining business processes to really leverage SharePoint and get a good return on investment in configuring SharePoint.  Most of the workflows you may have already seen were simple and only created an email notification, but out of the box SharePoint Designer workflows can do so much more.

There are two other ways to get a workflow.  You can use an out of the box workflow from SharePoint like Collect Signatures or the three-step workflow, but I’d advocate against them.  Like most things Microsoft did with these workflows or the Fab 40 templates if you can remember when Microsoft released those for SharePoint 2007, they are to be seen as examples of what you can do more than released into production.  You can also create workflows with Visual Studio.  I’d suggest that if you can do it with SPD, use SPD.  If you cannot use SPD or you don’t want to run the risk of having a site collection admin breaking something, use Visual Studio, but hire someone really smart to use Visual Studio and ensure that you work in an environment where it is allowed through governance before you start.  Using Visual Studio expands simple tasks such as inserting logic steps and breaks it down into actual code, making it difficult to debug if something goes wrong.  Save yourself the headache and just use SPD whenever possible.

Here are some of my best practices you should remember when designing a workflow.

1.      Draw out your business work process on paper before you begin.

Most people need this visual aid to show the start, goes to Mr. X, gets reviewed by Ms. Y, and published by Dr. Z.  Draw the stick figures and identify what the triggers are that take you from one to another and the next.  Identify what needs to happen at each stage.  If you know that the reality of the work is to tell Dr. Z that a package is on the way when Mr. X gets it, automate it.  Workflows can take multiple paths and can create, read, update, or delete items in other lists if necessary.  Want to make it pretty and don’t have Visio?—I use Gliffy.com.  Use PowerPoint if you really have no other alternative.  The first time you draw it out, however, should be all of the stakeholders in the room with a big white board.  Challenge everything about that workflow.  Be clear with them to identify the differences between their business processes and the workflow.  The way you need to build it in SharePoint probably won’t look exactly like the swimlane diagram someone hands you.

2.      Write out your workflow in plain words on paper to say what needs to happen at every step in the business work process to accomplish this.

Write out very simply something like this:

start workflow set workflow variable check flag for notification if flag not set, send notification, set flag, create item in package tracker list if status is publish, update tracker list, copy document to published library, and create announcement etc.

All of that will help you find the gaps in where you might need to create that column for each flag (hidden choice columns usually) so that when your workflow runs a second, third, or fourth time it does not create another email notification, another item in a tracker, or another announcement.  You need to identify where you do not want the workflow to run over and over and where you would need it to run over and over.

3.      Get your stakeholders to sign their name to the business process.

Time and time again I have seen pipe dreams sold to me as what the actual process is when it rarely if ever follows the documented process.  If there are more exceptions to the rule or the office cannot agree to what a process is, walk away until that office’s leadership can.  Note that you might be building this for one office who needs input from other offices, so ensure you really know who all of the stakeholders are.

4.      Use an index card to walk your item through the workflow on your desk.

Sometimes I use Post-It Notes ® or Sticky Notes on the computer to show the routing on my desktop if I’m using one of my better resolution screens.  This is just to get good visualizations to explain your user story back to the customer or just help you get your head wrapped around what your customer’s users are doing.  The index card is good so you have room to write down key column names so you can identify where things update.

5.      Name your workflow correctly.

On all of the list workflows, I make precede the workflow name with the name of the list.  It just makes it easier to find in case I have many other lists with their own worklfows.  If the workflow is to change the permissions on a personnel roster, it would look something like this: Personnel Roster – change permissions on change.  If you are using a content type workflow, precede it with the content type name.  If you are using a site workflow, precede it with the site name or Site WF.

6.      Fill in the description.

A good name doesn’t absolve you from adding content to your description.  I don’t know how many times I’ve seen similarly named workflows on the same list that I’ve had to read all of the steps to know which workflow does what.  Include in the description your name, maybe a link to the documentation you have on it, and a revision date.

These little things will not just help you when you are asked to make a change six months after you created the workflow, but it will keep people from badmouthing you if someone is looking at one of your workflows after you left an organization.  Imagine you were asked to change some complex workflow.  You open up SharePoint Designer to open it up and you see all of the documentation linked.  You would want the person who made that workflow on your team again.  Your reputation for how you do this will get around, especially if you speak at SharePoint user groups and remind them that this is what you do. 😉

7.      Rename your stages and steps.

This should be obvious, but I still do it often.  Especially if you have a longer workflow, rename the steps and stages so you can quickly find where things should happen.

8.      Name all of your variables up front and initialize their values.

It is like traditional programming where you declare your variable.  It is just a good thing to do this up front to ensure that a null value doesn’t creep in somewhere.  Null values can suspend your workflows.  After you are done declaring all of these variables, use one logging statement to show all of their values in the history list.  Use good names for all of your variables, and ensure they stand out from the names of your columns.  I usually add var to the front of all of the names of my variables just to be certain not to confuse them with any columns.  I also CamelCase variable names to aid in knowing that these are never displayed.

9.      Comment your workflow before you go to add the actual conditions and actions.

All of the plain English you wrote up in step 2 should be in comments throughout.  If it is a rather simple workflow, you can just add this to the names of your steps, but it is a good practice to support your buddies when you are working with a team of people.

10. Create a load of logging statements.

Every time you set a column or variable’s value, you should log the old value and new value to see it took properly.  Data type mismatches happen a lot, especially if you are using some columns with similar names.  We all make mistakes while making things.  Using the logging statements will help you find your errors when a workflow suspends mysteriously.

11. Log things to a separate audit log list.

I will always use version control with my document libraries where I might need to see the previous version of things, but if I want to see the changes in a single column or a status change, I usually create a previous value column for it.  Assume you have a column, Status.  I would also have prvStatus and make it a hidden column.  When the item is created, I’d set prvStatus equal to Status.  On the workflows based on a change to the item, add the condition:

If Status is not equal to prvStatus Create Item   Title = [Modified by] changed the status from [prvStatus] to [Status] on [Modified].  ItemID = ID (This is the ID of the item you were working with so it can show the relationship.)
You can then add a web part to this audit log to the dispform.aspx page of the list and filter its values to show the history of an item.

12. Use a new workflow history list.

I’m guilty of often using the same history list, and it won’t kill you if you do use the same history lists, but it isn’t wise.  Say you have a lot of testing for a long workflow.  Say you have 20 log statements in the workflow.  You test.  You made a few mistakes, and you get requests to make a few changes.  How many tests do you think you can do?—Only 250.  By default, no history list has its columns indexed, so it will hit that 5,000 item limit threshold like any other list.  If you are using the same history list for a few workflows, you won’t be able to see the results of any of your tests in short time.  Use a new history list.  Index its columns.

In addition, you can create an easy way to turn on and off your logging.  This takes us to the 400-level training, but have another list with Title and a choice column for on and off.  Add an item and call it Workflow XYZ Logging and select on.  When you are initializing your variables, have one for varWFLogging.  Set it to Yes or No based on the value Workflow XYZ Logging in that other list.  In SPD 2013, you can copy and paste, so when you were going to set all of those logging statements, create If varWFLogging equals Yes.  Then put your logging statement inside of it.  Then you can flip it on and off as you test things.  Keep some logging outside of the condition.  It can be overkill for a simple workflow, but if you have a lot of steps, I’d suggest setting this up.

13.  When it is possible, cut up large workflows into small workflow.

Sometimes, just having your workflow cut into stages and steps is sufficient, but sometimes it is best to call a workflow from the first workflow to run only when the conditions are necessary and the steps are repeatable.  For instance, you can have a 2013 workflow that you use for everything when there is a change; but, if the logic calls for it, that workflow could call a 2010 workflow with its impersonation step to change the permissions on the item you are using.

14. Use only one workflow to execute on creation or change.

It can be the same workflow, but do not have two or three workflows that kick off at the same time when an item is created or changed.  It can cause collisions that make things ugly.

15. Add a workflow as an option in the context menu.

If you have a manual workflow to do something to an item, use SPD to create a link to it right in the context menu.  It adds to the UI/UX of the application for a little more spit and polish.

16.  Do not use a pause for more than five minutes.

I bring this up because I often see people try to put a pause of like a week or months even inside of a workflow to archive the item after a long period or to send out a reminder email.  Well, that doesn’t work very well.  When you reboot the services on the box, the workflows get lost.  They break.  You won’t know without checking through all of your content where these orphaned workflows are.  Use an information management policy to kick off a manual workflow to do these things instead.

So when should you use a pause?—At the beginning of a workflow that would start immediately after an item is created sometimes.  What I have found is that copy jobs from one list to another aren’t always complete by the time another workflow might start in the destination list, so it would be good to have a one-minute pause here to ensure all of the metadata is set properly before your workflow starts to run with it.

Other Pro Tips for SharePoint Designer

Use it to help manage your permission groups.  You could have hundreds of permission groups in your site collection.  Managing them all through the GUI could be painful.  Through SPD, you can click on Site Groups and see all of them in one view.  It’ll help you find misspelled and redundant groups.  It will help you update the descriptions of those groups if they are missing.

Use SPD to create your HTML, JS, and CSS files right in the libraries where you’ll keep them.  If you have clicked on All Files in the navigation on the left side of the screen, you can get into any library and look directly at files.  You can create or edit all of your client-side code with a nice UI.  It beats using Notepad most of the time.

SharePoint Permission Pain

<rant>

I just need to go off for a minute.  I just got off the phone with a “SharePoint guy” for the leadership for some potential work that I am not going to do.  These individuals do not know or understand SharePoint from the fundamental understanding of how they’d like to use it for the enterprise to the understanding of where to click to do simple things.  They wanted control so much, they would not give me full control to their site.  They told me they’d give me design but then take it back each day when I had no more need for it.  The “SharePoint guy” doesn’t know SharePoint or else they’d have him build these libraries.  We aren’t even talking hard stuff.

The leadership—these mid-level managers—would have full control.  These are the same people who don’t know how to use SharePoint and could really use a class.  They have full control and the guy (me) who had designed the permission architecture they agreed to kind of sort of use a few months ago—it took this long for them to agree to implement what they believed was a good design—gets design.  I will not have the ability to alter the master so that I could put a disclaimer banner of sorts on each page of the site that regulations mandate they do.  The people running their farm haven’t bothered to implement these banners in the last six or so years they had the environment up and running.

</rant>

It really blows my mind.  I feel like Beatrice from the Essurance ads.  “That isn’t how any of this works!”

So how does this happen?  I won’t say it is Microsoft’s fault.  That would be an easy cop out that a lot of folks use far too easily.  Understanding how to use an expensive platform like SharePoint should fall on the shoulders of the people who decided to purchase it, whether they learn it themselves or trust in the people they decide to hire to manage it.  The problem is that few people bothered to question whether or not Team Site Owners, Team Site Members, and Team Site Visitors are the appropriate permission groups a site should have.

Leadership, those with rank and privilege in the organization, own their content.  No one should ever question that, but when someone creates a new site and sees an owners group, they automatically assume that the data owners are the Team Site Owners.  Now, these individuals who are too busy to take a SharePoint 101 class and probably don’t even have the time to open all of the email in their inboxes are the ones who will get the access requests because they didn’t bother to adequately plan for all of the people who will need to access the site.  They will give all of the underlings, including the younger more technically savvy members of the team, only contribute permissions, often by individually granting them permission rather than putting them in the Team Site Members group.  Often, I’ll see that they will add everyone outside of the team to the Team Site Members group because Microsoft defaulted the description of the group to say something like, “Use this group to grant people contribute permissions to the SharePoint site: XYX.”  Eeekk!!!  “Hey, let’s go create another 100 sub sites with new permission groups for each of them and manage them this way so that Bob Smith needs to be added to 100 XYZ Members groups!”  Some of these people think this is not just acceptable but encouraged because the site creates these groups with that description automatically.

The data owners—leadership of the organization—should get their own group.  That group should be given contribute or read permissions to all of the content they might want, which may or may not be everything on the site.  They might not want to see 50 libraries on the site.  Maybe they only want to see the links to lists and libraries they give a damn about because they only care about the 30,000-foot view of the data and don’t care about how you make the sausage.  That is assuming they are good leaders/executives.

Think about the user experience for yourself as someone who has SCA rights or full control to a site.  You get to see every single list and library as links in the quick launch or global navigation or custom menu thing you’ve built.  That can be a little overwhelming for most of the users.  It is like sitting down in front of the menu at the Cheesecake Factory.  They make a wonderful Cuban sandwich if you haven’t tried  it yet, but do you know how much other stuff I ate before I found the sandwich I hold so dear?  The more things you give them to click on, the longer they will take to make the decision as to what they’d like to click on.  We’ve already discussed that the leadership doesn’t have that much free time.  Why would you agree to make their lives harder because they want to micromanage what you are building for the workers in the team to enable them to be more efficient in what they do?  Push back.  They didn’t get where they are because they are stupid, but they are ignorant or ill-informed because of a lack of training and bad SharePoint people.  You do them a disservice by not educating them when they demand full control.

That is enough for now.  I’m happy to get it off of my chest.

Lessons: Developing a SharePoint app for a high trust environment

I just went through the harrowing experience of developing a SharePoint app for a high trust environment. Some of it was due to office politics, while most was due to plain miscommunication and incompetence.

There are some important lessons to be garnered which I think apply to any instance in which you are contemplating developing an app for your environment.

  1. High trust apps cannot be “ported” to cloud solutions, such as SharePoint Online or Office 365. If you code your app correctly, you can reuse the code and the overall framework of your app. For instance, I coded my app using the Client Side Object Model (CSOM), which is one of the recommended languages that Microsoft wants you to use when building an app; therefore I can reuse my code should my client want to move to the cloud in the future.
  2. If you are going to be developing a high trust application, you need to make absolutely certain that your infrastructure is appropriately configured. This is way too much of a topic to cover as it is expansive, and I don’t say that lightly. It doesn’t help that Microsoft’s own documentation is lacking and in some cases just wrong (I’m looking at you, MSDN Powershell code). If your environment is not configured properly, you will be fighting an uphill battle with an almost infinite number of possible moving factors which might cause your app to fail.
  3. Consider the return on investment (ROI). If you can accomplish the same end goal building a traditional, farm based solution, I would advise you go with the latter and not the former just because it’s newer and shinier. Chances are if you are building an app in a high trust environment, like I was with my client, there is no chance you are going to the cloud anytime in the near future, irrespective of what the Microsoft talking heads are telling you. Plan and build accordingly. Be smart about the choices you make when contemplating the SharePoint app model versus a traditional solution.
  4. LISTEN TO YOUR INFRASTRUCTURE PEOPLE. Just because other developers on the ground happen to be Microsoft, this doesn’t mean they are the best equipped to be giving you input on the solution you are building. Your app will only be as successful as the actual configuration of the environment you are deploying on. Make sure you get all the appropriate certificate serial numbers, issuer IDs, and token information necessary for your app from the infrastructure folks.

With SharePoint 2013, there are some quirks which just cannot be overcome with a standard, traditional farm solution, irrespective of the code you write. In this case, you will have no choice but to write your app using the app model. I had this misfortune particularly with the site collection provisioning process, which at a certain step could not be overridden no matter what using a traditional farm solution, but that is a topic for another time.

What is high trust? High trust is basically the same concept as with a traditional farm solution, in which your app will have “superpowers” to the farm, and therefore can have the same ramifications as a traditional solution if something were to go wrong. Where it deviates is the fact that you can build your app so that it is hosted completely outside of SharePoint, therefore isolating and preventing it from screwing with your SharePoint instance. Therefore, your app can go “down”, and will not take SharePoint with it.

This topic can go on and on, but that is it for now. I’ll have much more to share in the near future.

SharePoint Testing

I just realized I’d left this unpublished from a few weeks ago. This should have been published before my trip to SharePoint Saturday Atlanta.
—-BREAK—-
So I’m working with a new client again, and I’m seeing what I’ve often seen with other previous clients: test sites and test lists and even testtesttest2 lists. This drives me nuts for a few reasons:

  • They are usually old. If you don’t know your job as a SharePoint person and need to create a test list for you to figure things out, admit you don’t know how SharePoint works.
  • They lack any kind of context. It might have just the title column, no records, and modified last 5 months ago. How do I know if it holds any value to anyone whatsoever?
  • Whoever made them didn’t change the permissions or correct the navigation for it. This is what drives me nuts the most. Not only do you obviously not know the platform, you are advertising it to everyone who can see the site that you don’t know what you are doing and are cluttering up their UI.

If SharePoint were your house, we’d already have had an intervention for your hoarding.

Just stop it already.

In another client’s O365 environment, they were looking to create another web application (paying a lot more money by the way) to have a testing area, but they weren’t doing some kind of crazy code affecting O365. It wasn’t necessary at all. I’m glad I stopped them.

So here is my freebie to everyone out there.

O365/SharePoint Online Users

If you are an O365 customer, you might want one site collection as a test environment.

Why?

Because you do need a place to train other people and a place to make new masterpages without deploying the new look and feel right into production. I’ve seen too often someone create a new masterpage and roll it out without being approved properly. Bad idea. Create the new site collection and then a NEW copy of the masterpage. NEVER edit the defaults. Just don’t. Work with it there and fill the site with a bunch of lorem ipsum junk text. You’ll get a better feeling for how things will look. Also, don’t forget to add a few dozen links to your quick launch and global navigation to see how well they look under the new master.

You do not need to put new lists in this environment to test them and then build the exact same thing in your production sites. That is just silly. That is beyond silly. This is not traditional application development with rounds and rounds of software development design meetings and half a dozen folks creating their own pieces of code that others will piece together to make this one beautiful application in six months. SharePoint is a middle platform to create applications in minutes. If you don’t like it, delete it. If you create it properly, use the same content type over and over to make the application for multiple groups of users.  It could also be that place where you and only you have your test lists because you don’t know how to make a feature work properly, but that still wouldn’t be the best place for the test list.

SharePoint 2013 On-Premises Users

You have the world as your oyster with your own environment, but you still load it up with test sites and lists.  Shame on you.  Other options are available and here is what you need.

Scenario 1:  We will write custom C# applications that will need binaries injected in the hive.

Solution:  Build another farm.  Scale it to have the same number of web front ends (WFEs) running the exact same version as production.  You will only need one SQL box on the back end.  All we are trying to do is replicate the environment as much as possible with far fewer resources like memory and storage.  You will need to change files on the WFEs in this scenario.  While highly customizable, this is really only advantageous to very few customers out there doing some really amazing things.

Scenario 2:  We will write some custom JS, CSS, and HTML and use the client-side object model (CSOM) to make things pretty and more functional.

Solution 2:  Still build out a second farm.  BUT why?  If you are an IT systems administrator who has been in this business for more than a year, you will know and will probably have experience of getting a patch that has broken a server or two, especially after you have hardened the servers (STIG’d in my market) to make them more secure.  How do you know which patches from Microsoft or any of the other third party applications that you have running on all of your boxes will not screw up your environment?  You test.  You will only need one WFE.  The SQL instance will be a new instance on a cluster that you are using for ALL of the other SQL things going on in your environment.  Again, we are trying to replicate your environment with as few resources as possible.

But what about SharePoint testing?—Aside from testing a cumulative update before adding it to all of the WFEs in production, you don’t need to use this test environment for anything else.  If you aren’t running any monitoring software that you need to patch on your production WFEs, you might not even need this.  Microsoft has an OK record of not destroying SharePoint farms with patches, but it is by no means spotless.  I do recall a few years ago a 2010 update that screwed up a lot of folks.  Those patches are the only things you are testing.  You aren’t testing lists, web parts, sites, or anything else.  Don’t even give anyone else the URL if you are the systems admin or farm admin for SharePoint in your IT department.

So where do you test things?

In production.  Let me explain it as simply as I can.  When you write up a document in word and it is in draft form, do you keep it on a different computer?  When it is ready to print, do you copy it out of the draft version and paste it into a clean document?  Of course you don’t.

Build the entire application right where you need it.  The key is to change the permissions on the list/library/site/etc. to the pieces of it so only those involved in building it can see it.  When it is ready for go-live, change the permissions.  That is it.  You can even update your navigation, unless you are creating a lot of hard links, because security trimming in SharePoint won’t show those links to people until they have the permission to see them.  If, however, you are using a lot of hard links in the navigation, set the audience on those links to just those involved in building.  When the application is ready for go-live, take the audiencing off.

If you are a client, looking for good SharePoint folks and you see a bunch of test crap in your environment after you hire them, recompete that contract ASAP.

Add a Link to Manual Workflow

I’m building out a little thing for the company’s recruiters for when we add a friend to the list. An email goes to the boss of all of the recruiters saying one dropped. I have a link to the resume and the item, but I also had all of the pertinent information in the email. So even though the boss would be able to click on the link, go to the list item and click on my custom button to assign a recruiter, I thought I could cut out a step. I just created a link to the workflow I use to assign the recruiter.

ManualWorkflowPostPic0

The URL for that looks like this:

https://xxxxxxxxxxxxxxx.sharepoint.com/wfsvc/6f981489c973485293741943682bda4a/WFInitForm.aspx?List={1519fb4a-ef7b-468f-ad4f-7b0b2fea8f6a}&ID=8&ItemGuid={83D33457-7C55-41F9-938D-69143006E3AC}&TemplateID={B7CB07B2-F62C-49D2-9848-11858888F65F}&WF4=1&Source=https%3A%2F%2Fxxxxxxxxxxxx%2Esharepoint%2Ecom%2FLists%2FReferAFriend%2FAllItems%2Easpx

I know that looks like a crazy URL to build, and it is.

First, you can strip off the source. That is so SharePoint knows were to drop you after you submit. It is coming from an email, so we only really need to build this:

https://xxxxxxxxxxxxxxx.sharepoint.com/wfsvc/6f981489c973485293741943682bda4a/WFInitForm.aspx?List={1519fb4a-ef7b-468f-ad4f-7b0b2fea8f6a}&ID=8&ItemGuid={83D33457-7C55-41F9-938D-69143006E3AC}&TemplateID={B7CB07B2-F62C-49D2-9848-11858888F65F}&WF4=1

It comes in a few parts. You know what list this is, so we have the front of the URL, the list GUID, the ID, the ItemGUID, and the template ID. Separating much of these are braces {} so that the URL is constructed correctly. I thought I could use this string:
ManualWorkflowPostPic1

Well, guess what. There is no way to add those braces to a string. Microsoft will send you back this error:

ManualWorkflowPostPic2

That is unless you put those into their own variables. So I made all of these variables for the GUID, ID, open bracket, and close bracket:

ManualWorkflowPostPic3

Then, I changed my string to this:

ManualWorkflowPostPic4

Now I am able to insert it into my email to the management.

ManualWorkflowPostPic5

The management doesn’t like going outside of Outlook for anything, so this is the best middle ground I could do until I build an Office Add-in. I might do that in three years.

Metadata vs Folders

I just came across a group post on LinkedIn this morning about the use of folders in SharePoint document libraries. I made a decent response via my phone, but I wanted to make a proper post.

Current best practice for SharePoint – few folders or no folders?

The last time I looked at SharePoint architecture best practices, the thinking was that it was ok to have a few folders, but that the bulk of data should be in one big pile and filtered through metadata views instead of distinct folder locations.

Has that thinking changed, or is the best practice still to use views predominantly?

You can have the best of both worlds. You have at least two audiences for each library, the ones adding to it and the ones retrieving from it. If you have an old school records manager who works with your paper records, ask them about folder structure. I’d say that if your library has folders, you should do it the same way you would on paper. When was the last time you went to a filing cabinet, opened a folder, and saw more folders inside of it? If you have files at the same tier as folders, it is like putting papers on top of the cabinet because you don’t know where they belong. When you create a folder structure that goes nine nested folders deep, you really hide the content from the person looking for it. Even if you assume that anyone needing this could use search, you’d be fooling yourself. Search is smart enough to know that content that is nine nested folders deep is not as relevant as something that is at the root. That piece of content will end up on page 47 of your search results.

Set up the folder structure, then turn off the ability to add folders. Lock the into that structure so you don’t have the folder sprawl that plagues your shared drives. Then, create all of the views based on metadata and remove the folders from the views except for the view for those putting files in there. You can link to that particular view off the Quick Launch and limit who sees it by audiencing the link.

I’d be certain to invest the energy in creating good content types. You might want the PM’s name for all project plans, but you wouldn’t need it for the office picnic flyer.
Don’t just use one big library. Each library should have like content, not the same content types but similar content. You will end up with libraries that use workflows and libraries with more static content. The main the reasons why you split up your content into more than one library is because the content is very different from the other content, permissions vary, and the use of workflows for approvals and such. Unless a workflow is breaking permission inheritance, don’t break permissions inside of the library. It becomes much uglier to manage and can easily lead to orphaned content.

PSA: InfoPath and Office 2016

Office 2016 was just released today. I was so excited to download and install it. I have my reasons. Just ask those of you who get annoying junk mail notifications in Outlook 2013 how much you hate it. Yeah, Microsoft never fixed it.

I then started looking into how I should upgrade. Most easily done if you have an Office 365 subscription. Ok, cool. I then noticed that the InfoPath icon wasn’t included among the apps. We all know by now that InfoPath has been deprecated. I thought that maybe Microsoft would include the 2013 version with their 2016 suite, since they wouldn’t be upgrading it.

The answer is NO. If you have Office 2013 suite install with InfoPath 2013, that version of InfoPath will get wiped and removed along with your entire Office 2013 suite and upgraded to 2016. In order to create/modify InfoPath forms on Office 2016, you will need to reinstall InfoPath 2013. This will leave you with two “installations” of Office: 2016 and 2013.

Just a friendly PSA. Check here for more info.

Hidden Titles

The primary purpose for me to start this blog was to highlight a few of those war stories I’ve got of saving the day. I will leave the names of the clients I’ve had out of this.

 

So here is a rather recent event. A whole lot of us were on a rather large contract, and the client failed to get paperwork completed on time to keep us on site. We were sent home on mandatory vacation. While on vacation, I learned that there might not be funding for my position after we got back. I spent the time looking for another position. Anyway, three weeks pass and we finally get back to work. A few days later, a guy asks me why he can’t see Title on one of his libraries. After looking at that library for a minute, then others on the same site, then all the way to the Title site column of the whole site collection. Yes, you may have guessed it, Title had been set to hidden and cascaded through the whole site collection.

 

Now, in a happy world, I’d just run to the farm admin and ask him to restore from a backup, but that wasn’t going to be possible. It happened a week after we left the client’s site. It was another three weeks before I learned of this, so all of the documents that had been edited and pages that had been modified would have been lost if we restored from the last good backup. The only other contractor working on SharePoint with me spent seven days going to every single list and library in the site collection, converted all of them to manage content types, and set Title to required, optional, or hidden as required. I spent only two days on the task before I started to work on my last project before leaving to start with a new company.

 

Lessons Learned

  1. Obviously, never screw with the out of the box (OOTB) site columns.
  2. Don’t let qualified people have full control permissions at the root of a site collection. For the record, I had previously stated the one responsible should not have permissions there, but I’m only a contractor.
  3. Your farm admin should have a list of daily tasks and weekly tasks. Somewhere among them should include a series of tests to check for changes via the audit log. You can never expect communication to work properly even if you think you have a good change management process in place, so you need to have someone checking these logs often.
  4. Don’t expect a lot of love from the ones who enabled the person who did this when you fix it. This was a very public airing of dirty laundry. Just do your job and take notes.