KM Failure #1: Starting New Documents from Emailed Templates

This is going to be the first of many posts on knowledge management failures I have personally noticed over the years. I’m going to point out the problems and provide suggestions on how to address them. Please provide feedback and insight if you have had any success in combating these problems or if you finally meet with success if you try one of my suggestions.

Problem

Have you ever seen someone start on a new project plan, risk management plan, memorandum, or other document by deleting content from the last document they made and giving it a new name or by searching for the organization’s template for them from their email? I have. I’ve done it myself quite a few times, so I bet you have too. I see this a lot with PowerPoint presentations as well. This is a problem because these templates change often, and people in your organization do not know always when those changes happen. I’ve seen so many people with hundreds of unread emails that it is never a surprise to me that they don’t know they received an email with new organizational templates if they were emailed to them. Most people just do not have the time to read all of communications coming down from on high, so they focus on key people who send them emails and believe they’ll eventually catch up on the rest. It is difficult at best. I have even seen people delete all of the emails they had come in while out on vacation and say that they will get a new email if it was really important.

If your staff can still get the job done with little disruption, why is this still not a good idea? Maybe you do not have a policy on the styling of documents in your organization. That is probably because efforts to standardize have been futile because everyone has his or her own two cents about how it should be and are at odds with others. In very large organizations, especially within the federal government, every head of a directorate might dictate his or her own way style—among so many other things that go contrary to higher guidance. Sometimes, that higher guidance is at odds with the rules of English even. As someone who used to teach English, you can imagine how frustrating I found making soldier a proper noun in all of my Army writing when I was active duty. In common Army writing, you might not ever see the subject in a sentence even. The first sentence will often begin, “Request units send…” Who is making this request?

It is not a good idea for your staff to start from a blank document ever. How many of your standard reports and plans have fixed sizes for tables? It would be much more painful. You might be using styles if you are lucky, but when you want to send it out for comments and changes, copying and pasting the changes back into the original could lead to weird results.

Suggestions

So what are you to do?

Use styles

What prompted me to start with this particular problem was spending a few hours helping my wife with a couple documents she was asked to markup and submit back to her office for some guides they were putting together. She is a non-native English speaker as is every other person in her office. She was given a time slot of today (a Sunday) to make her comments because they did not want collision with people saving the file while someone else was working with it. The documents were essentially 80% the same with additional pieces for different audiences. This meant that when we found a mistake in the third paragraph in one document, we had to comment the third paragraph in the other two documents. No where in the document were they using styles. If you don’t know what I mean by Styles, open MS Word and look at the ribbon. Because I chose Blog Post as my template in Word, this is what I get by default:

I always use styles. Sometimes I make my own, but sticking with the defaults in Word isn’t bad. If you have a communications office in your organization, I highly suggest that it come up with a solid group of styles that you apply for all of your documents with the right fonts. As time goes on, revisit these styles. See if there are studies suggesting that some fonts are easier to read than others. That is my subtle way of saying to stop using Times New Roman. Not only does it show that your organization hasn’t evolved since 1997, it really is hard to read when most people read their documents electronically today rather than printed. Studies show that sans serif fonts like Arial and Segoe UI are far easier on the readers’ eyes than serif fonts like Times New Roman and Gothic when reading them on screens. On printed documents, serif fonts provide some value. Scanners prefer serif fonts if you need to PDF old records for which you no longer have other digital records. Most of all, however, styles cascade. If you use numbering for your paragraphs or want certain titles to be in bold and in a larger font, realizing that pages of content should be nested under a different title could mean making dozens of changes. I found in her documents some of these changes, so I typed out a comment, copied it, and made that comment to change that one thing over and over and over again.

Make a policy you can enforce

One of the biggest problems in the government isn’t a lack of policy but the lack of enforcement. This is why so many business processes use guides rather than policies to define how the staff should comply. Nothing happens to those who go their own way, so they will continue to do it. If you are stuck in one of these situations where you wouldn’t be able to enforce the policy, make it guidance, but do every other thing you can to make it easy for users to comply with it. I’ve run into this a lot when coming up with governance for SharePoint environments. Governance needs three pillars to support it: policy, monitoring, and enforcement. If it is not feasible to check all of the pages out there to see that they use the right fonts and colors and when nothing happens to those who choose to use something outside of what you defined in the policy, it is pointless to even include it in your governance. To get people to follow the guidance, make it difficult for them to deviate from it. Make them realize they can save time and effort by going with what you just made them. It might require training your staff, but the return on investment can be worth it. How much do quality technical editors cost if they must focus on just getting everything into the right format?

Create your documents from set applications

I create a lot of things on top of Microsoft’s SharePoint platform and have for the last 10+ years. I love the application. If your SharePoint staff don’t understand what content types are, you are not getting your money’s worth. Document libraries use a default document content type. If you click New, you get a blank Word document. You can create templates of risk management plans, project plans, white papers, activity reports, etc and make your own content types. When you click New, you could get the default project plan with all of the title sections created and sample content included, or get presented with several content types to choose from. You can even use what are called Quick Parts to autofill sections of the document. One thing I’ve done successfully many times now is to create document sets that come with three or four different types of documents include in them. They are essentially pretty folders with metadata, but that metadata uses the quick parts to fill in information in the documents so that you don’t need to worry about your staff making the same updates over and over again. Changes to the metadata is reflected in all of the documents immediately. It can tag those documents with metadata that allows you to more easily find the content years later. You can even use the search to pull out every project plan with Bob Smith as the project manager between 2008 and 2016 if you wanted to have metrics for some kind of award or something.

Guess what you have there?—WIIFM… What’s in it for me? You want your user to fill out that metadata, so give them a reason that benefits them other than efficiency. Efficiency is never enough when it comes to the government. I was once building an application for an office. When I told them that it would save them enough time that they could task three people with other work, they had me stop. They don’t want anyone to lose their jobs. No one wants replaced by automation. They don’t seem to realize that there is more than enough work to fill the void with other things, but it took a few months to convince them of that.

I don’t know what antiquated system my wife was told to use, but she had to download these documents, make her comments, and upload them back. I guess that is far better than emailing documents around, but the business process there put everyone in serial rather than parallel editing mode. I am bias toward using SharePoint for a variety of reasons, but this is where it can shine best. Using SharePoint, users can get Word Online. It makes it so that several people can open the same file at the same time using Word in the browser. With paragraph locks, people can edit different sections at the same time. SharePoint even maintains version control, so you don’t end up with people naming stuff like document_SRB_Editsv5_draft_final_final-5Aug18.docx. Oh that kills me. Adding a date like that won’t help you ever search for anything, and it can be misleading when the last modified date on the document doesn’t match. The date could have multiple meanings to different people. Calling anything a draft is pretty much a given until you publish it, so that is pointless to add. Using metadata, you can make the crazy filenames you have seen irrelevant.

Lastly about these applications, don’t just make a site with a library named documents and put a few thousand documents in it. That is no way to organize content. Not to go off another tangent about information architecture, plan this out well. Keep similar content together. Project plans do not go into the same library as the office picnic flyer. Make pages on that site that will show a view that highlights the content and wraps it in context. If you want everyone to use the application to start their documents, write paragraphs to the side of the library in that defines the work process and why they need to do it how you are outlining that process. Provide help. Provide sample content of what makes good content. Provide links to your style guide and any writer references you use THAT POP UP over the page instead of redirecting them to another site in the same window.

Protect It while you Build It

A long while back I typed up a post about test environments. For the same reasons, I need to explain how you can help prevent giving yourself and your users some headaches. Another contractor working SharePoint—I’d rather not call him a SharePoint developer even though it is his title—with a client has a production version of his application on an existing 2010 farm, but it isn’t functioning yet on Office 365 because of all of his coded customization (stuff we should have done out of the box with SharePoint). People continue to hit the site and request elevated rights over the read rights they already have. If they had no rights to the site, this would not be a problem.

The permissions mess is a much longer post, but I need to explain how you build your sites and apps. I immediately remove all permissions from a site, list, or library when I create it to give me time to build it correctly before exposing it to the rest of the users. Why?—

  • People shouldn’t see anything under construction, especially when there is a production version running elsewhere. It leads to mass confusion.
  • It allows you to screw everything up without others noticing. No one knows everything when it comes to SharePoint, and you may want to try a web part you haven’t used before. Do you really want everyone else to take notice that your web parts are all funky?
  • Rarely, should you have the exact same permissions on a site, list, or library that mirror the parent exactly, so you should be breaking inheritance anyway. Like all other basic IT security rules you should know, we want to grant rights based on the on the principle of least privilege. That means that you trim away access for people who don’t need it. People could need contribute rights to all of the other lists on a site, but if their role determines they should not be adding to the list you are making, you grant only read to the role they are in.
  • It really can help with testing purposes. You might need to cycle your testing folks through different permission groups separately before you go live, and it is just way easier to kill all of the other permissions until you are ready to go.

So please just stop. Think about what you are doing. Every setting in your list should have been addressed, and you should have made a conscious decision as to how you would configure that setting before you allow anyone access.

Knowledge Curation

I was working with a group of folks the other day who wanted to redesign the site. They had a lot of ideas for one page. They had no ideas for the data that supported what they wanted to present on that page. The site collection already has very poor architecture. When one goes to the root site to the site collection, that person gets two redirections to the final page on a subsite. Whoever created it that way caused all of the lists and libraries on the root site to go untouched for about a year.

In my discussions with them, I had to give them the analogy of a kitchen remodel. One doesn’t just put in a new kitchen. You need plans. You need to do demolition work. You need to account for the electrical, gas, and plumbing that you cannot move. You also need to figure out what you are going to keep from your cabinets. They had a good 30 or more lists and libraries that hadn’t been touched. I’m not going to just leave those defunct lists and libraries there. A new page would be a mere façade over a weak structure.

Over the coming weeks, they are to look at the existing content and identify what they are going to keep and what they want to kill. This is always the first step in redesign work with SharePoint: Knowledge Curation. It could be information curation, but we need to identify why and they are vetting the value of the information, so I elevate this to knowledge. They aren’t just checking to see if something is properly tagged. They are doing more than content management, and it is grunt work because no one had previously built the tools for them to sift through it more easily.  To learn more about knowledge curation, here is an article I looked up from KM World.

The next step will be to identify the data definitions of those things they would like to present on the page like pictures on a carousel. I’d rather them not need to do a lot of work to keep their content there, so they need to identify what determines whether or not a picture will be displayed, how they want to add a new picture, if they link, etc.

We will go about creating their content management plan and will have a section for knowledge curation. It should be a continuous process, not something you do once a year. It is like brushing your teeth daily versus getting a scaling once a year by your dentist because the plaque looks like you have fused your teeth together. At some point, your dentist will recommend pulling your teeth and getting you dentures. This is why you see so many people start over with SharePoint sites. They neglect them for so long, they would rather just build a new one. It takes discipline, and it takes a plan.

Scott Brewster works for Data Analytics Solutions. He is got his Certified Knowledge Manager (CKM) credentials through the Knowledge Management Institute (KMI), and he has been working on both the farm administration and front end solution architecture of SharePoint since 2008.

The Importance of User Groups

Just wanted to say a few things about why I harp on getting people to attend the user groups. Microsoft leads in the enterprise primarily because there are many more trained and qualified technicians with lots of reachback into blogs and documentation who work on the Microsoft stack than there are with niche Linux distributions. It helps Microsoft’s business to push Channel 9 and other things because this free training helps to evangelize those who use it to recommend additional Microsoft products and the ones in which they already specialize.

For the same reason, not only is it in Microsoft’s interest for you to have your user group to share knowledge, but it helps you as well. As SharePoint becomes more in demand because you and the others who attend push for its use in the enterprise, you become more valuable as one of the few who have the knowledge and experience that you have built yourself but the knowledge others have shared with you. It makes you stand out from those who have not been learning from and sharing with their peers. The user groups you attend become hubs of knowledge that help you gain knowledge, but when you get ready to share, you also tend to learn more about the subject so that you can be the authoritative source when you present to your peers. It makes us all better.

Hoarding knowledge does not improve job security, but a great many people tend to think it will. The truth is that you will be known as a thought leader in the material the more you share. That makes you stand out as the subject matter expert you become when you are active in your user groups.

I stress to you that, even if the topic of the night falls outside of your role when it comes to SharePoint, you should attend all of the meetings you can. It strengthens the group because a group really is more than the sum of its members. It helps you network. You might not be actively be seeking new work, but opportunities pop up in odd places. You will learn that someone new to the group is having an issue that you or your company is uniquely suited to tackle, and you can help grow your company and become more valuable within it.

While this post has focused on SharePoint user groups, it applies to all user groups, communities of interest/practice, and professional associations. A lot of SharePoint Saturday conferences have lost a lot in the way of sponsorship dollars over the years, and these events are where some of the best in the industry get together to share their knowledge with you for FREE. Speaking obviously helps their resume and helps to get their company’s name out there, but you should rarely avoid free knowledge. You might think you know it all, but that speaker might share one little tidbit that will change how you do everything and could make you so much better at your role. Go to your groups. Evangelize SharePoint or whatever product/platform/practice you use. Stand out among your peers.

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.

Permissions 101

The basics of SharePoint permissions haven’t changed too much over the versions, but there are things Microsoft has done with SharePoint 2013 with sharing I do not appreciate. Worse is the newer permission level of edit. Maybe my users are worse than your users, and you’ve been able to train people to not add columns without planning to lists and libraries. I’ve not met users who don’t eventually do something undesirable with edit permissions. Contribute used to be the default permission level for regular users/members of a site. I’d suggest changing it back to contribute for all of your future sites.

 
 

The worst thing that Microsoft did with its permissions has everything to do with semantics. At least with my clients in my market, they like to be in control of their empire, regardless of how small it is in a 50,000-person organization. When Microsoft automatically creates for you ABC Visitors, ABC Members, and ABC Owners when you create a new site, the management of the office often insists it is in the Owners group. This means that the people who often have the least technical skills in the office have the power to create apps and will see more things to click on than they should. Data owners are not the same as site owners; trying to explain that in such a large organization is difficult but possible. You just need to fight lots of little battles and ruffle a lot of feathers. The easy way around this is to create a new group called ABC Leadership and put them in there while you rename the default owners group to ABC Site Administrators. You could use ABC Management instead, but calling them leadership makes them feel better. Words have meanings, and you should pay attention to the emotions they can elicit.

 
 

If you take away nothing else from this writing, please use that advice on renaming the groups.

 
 

You should have created your groups before you created your site, assuming it is not the root site of the site collection. Do not let SharePoint create them for you. You should already know the different audiences of your organization and most of the different roles you will encounter. You will want a single group to represent everyone in your organization. I’d suggest that this is your ABC Visitors group or an equivalent. Add everyone to that group. Never again should you create another visitors group with the same population inside of it. It is one of the most common things I see. I’ve looked at many site collections where there are multiple owners groups and visitors groups with the same handful of people in many owners groups and the entire organization in all of the visitors groups. Imagine cutting down the number of groups to manage by up to 66% by just not creating all of those redundant groups.

 
 

SharePoint permissions pass down from the site to the subsites and lists and even the items inside until you break inheritance. A site’s overall permissions are by default the permissions of the Pages and Site Pages libraries you might have on your site and, therefore, the home page of your site. Ask yourself if everyone who has contribute rights on your site should have the ability to modify the home page of the site? Maybe, but probably not. Often times, I see the site administrators lock down the Site Pages library to prevent people from making edits, but they often make it so that the organization cannot even view the homepage. Be careful how you do that. I’d suggest that you break inheritance on the library, not just on the page. Like with all places where you break inheritance, it isn’t obvious that the permissions on one object might have different permissions than another or its parent. For this reason you should be careful to break inheritance only when you need to. It would be a wise move to not only document a matrix (permission map) of all of the permissions each group has compared to each list or library on the site but to also add in the descriptions of each that it has unique permissions and what that means for the people looking at the list or library.

 
 

I’d also suggest that you do not break inheritance at the folder or item level within a list or library unless it is highly documented or—even better—controlled by a workflow so that you remove the human element from being able to accidentally grant or deny people you should not. Everything is truly business requirement specific when you make these decisions, but a good example of this would be to an human resources library where you have a folder for everyone in the organization. You would likely allow HR to have contribute to all of those folders, the individual to have read or contribute no delete (you should probably create this permission level), and each individual’s supervisor to have some level as well. The beauty of this is that HR will see all of the folders, supervisors would only see their own and those of the people they manage, and individuals would only see their own.

 
 

This is because security trimming in SharePoint does not allow a user to see that an object even exists if that individual cannot access it. Alternatively, you can use audiencing to selectively show web parts and links. Audiencing is not a method of security. It just allows you to better advertise directly to the right consumers. This is very important because most apps you build will need to have at least two very distinct audiences: those who add the content and those who consume the content. Sometimes they are the same groups of people, but usually it is a smaller group to create the content than to consume it. So the links in your current navigation could go to a number of extra views that matter only to the creators of content if without cluttering up the list of options for external visitors of your site. Everyone might have access to the same list, but you don’t need to advertise all of the views the creators might want. Could you imagine going to a restaurant and seeing all of the dishes that have an ingredient you don’t want automatically removed from the menu? That is exactly what you are doing when you use audiencing. Use it wisely, and document it.

 
 

When creating all of the groups to your site, you may be tempted to use the ABC Members group and groups like it in ways that are not desirable in the long run because of the management burden. If you had an HR directorate in your organization with branches A, B, C, and D, you would likely create HR A Members, HR B Members, HR C Members, and HR D Members. That would be totally reasonable. So if you had an HR site and a subsite for each of the branches, you might have already created an HR Members group. This is why you should plan all of these groups on paper long before you build. Because you know you’ll already need to create sub-population groups, it is against your best interest to have a group where you have put them together as well. This is because the parent HR site should have the following groups with these default permissions:

HR Site Administrators

Full Control

HR Leadership (don’t forget this tip)

Contribute

HR A Members

Contribute

HR B Members

Contribute

HR C Members

Contribute

HR D Members

Contribute

Org Visitors (everyone)

Read

By creating an HR Members group as well, you’d have yet another group to update as people joined and left HR. By mapping out all of the groups you’ll need at the smallest manageable group, it becomes much easier to get granular without the management overhead you’ll have with SharePoint creating all of these groups for you.

 
 

At the same time, I’ve sometimes seen site administrators add users from other organizations to the default members group of the site. Assume that a few in Legal often work with the folks in HR B. If you add them to the HR B Members group, you’ll inadvertently give them access to things that you might not want them to access. This isn’t about you not trusting them, but they might not like it either. You could have a workflow that sends out email notifications when anyone in the company updates a service feedback survey for when HR helps people. If that workflow uses HR B Members as the distribution of that notification, you’ll start spamming the Legal people. Use role-based access control (RBAC) when planning your groups. If you add Legal Members as another group that can contribute to the library where they collaborate with HR B, you fix all of these issues. You also save yourself some pain when Legal hires a new person. By just adding that person to the Legal Members roles, the new person gets all of the accesses of all of the other Legal people where he or she should have that level of access. You should not ever need to hit 20 sites to add the person to a different group because that is where the other Legal people have access.

 
 

To document all of these permissions well, you need to create a permission map for each of your sites. You can just create a little table in Excel or on a wiki page. It doesn’t matter what your preference is as long as you do it for all of your sites and preferably the same way. It’ll eventually look something like this:

 
 

  

Description

HR Site Administrators

HR B

Agency Members (everyone)

Legal Members

Customer Feedback Survey

Survey that goes out periodically to those who HR B supports after fulfilling a request.

Full Control

Contribute

Contribute

  

Disciplinary Documents

Collaborative library where HR works with Legal to process disciplinary actions.

Full Control

Contribute

  

Contribute

HR eFile

Folders exist for every employee in the agency. Each employee can see his or her own file.

Full Control

Contribute

Dynamic – Workflow

  

HR FAQs

Frequently asked questions regarding HR functions.

Full Control

Contribute

Read

  

Leave Calendar

Internal calendar for the office to track who is in the office.

Full Control

Contribute

  

  

Office Calendar

Calendar for everyone in the agency to see when HR is hosting seminars about benefits as in and out briefings among other things.

Full Control

Contribute

Read

  

Shared Documents

Not used because of changes to the library made by the publishing feature.

Full Control

  

  

  

Site Assets

Keeps pictures for the pages along with some custom CSS files for the site.

Full Control

  

Read

  

Site Pages

All of the pages that add the context for the content in the lists and libraries.

Full Control

  

Read

  

Team Tasks

Used internally to assign taskers to different members within HR B.

Full Control

Contribute

Read

  

 
 

After you have mapped out what the permissions should be, you can use this as a checklist to ensure that they stay that way. Inevitably, you’ll add someone to your site administrators group who will mess it up, so periodically review the lists to ensure that you have the permissions set according to your plan. Of course this is just an example. You’ll likely have many more lists and libraries as well as groups to map out. Like all settings for a list or library, you should make a very conscious decision about what the permissions should be for each of them and add it to the map you’ve made.

 
 

Sometimes you will want to create some special permission levels. For HR, you might have a few libraries where you want everyone to be able to submit a form but not be able to modify it or even read it afterward or maybe read only your own. Create the additional groups with caution as some features might need a particular setting to work correctly. A general rule in SharePoint is to never mess with the out of the box configurations but to copy and modify to create new. So don’t open the contribute permission level and remove the ability for people to delete. Instead, create a new permission level Contribute No Delete. You can do a lot of unique things. I’ll repeat this ad nauseum: document what you do. When you get a promotion or go on vacation for two weeks, someone else will need to step into your role in case a change needs to happen, and that person will need to understand what you have made, how you made it, and why you chose one way vice another.

 
 

What you should not do is give a group multiple permission levels. I have seen many times over the years where a site administrator—or more often a person who got permission because of rank in the office without the technical training to support the duties—has given a group View, Read, and Contribute. That is so very redundant. I’ve even seen a group get Contribute and Contribute No Delete on the same library, and the person who did that cannot understand why the group can still delete things. SharePoint grants most privilege when there are competing permission levels. Grant each group the least amount of privilege it needs to do its job on the corresponding lists, libraries, and sites.

 
 

Sometimes, you might need to have a list that has thousands and thousands of items where HR A, HR B, HR C, and HR D have different levels of access as the item goes through its workflow. You have the option of copying the item to a new list with the different permission settings for that item to inherit the permissions from its new parent, or you can elect to keep the items in the list and have the workflow adjust the permissions. If you have only a handful of ways you would like to adjust these permissions, you can create folders in a list and assign different permission levels to these folders. Then your workflow can change the path of the item so that it inherits the permissions of that folder and then the next and so on. You would build your views to not see folders, but the folders would affect the permission levels. This is so that you only need to worry about a handful of permission scopes rather than thousands if you were to have the workflow change the permissions on each item. While a list can support up to 50,000 unique permission scopes, it is a pain in the butt to manage that way. Additionally, the extra folders can help you get over the 5,000 items in a view threshold even if they are never visible to most of the users of the app. This is also best for data integrity. If you were to move things from list to list to work through the permission changes, you would probably end up with new Created dates that don’t align to the items properly, so you’d need to add additional columns just to track the original created date. Version control would be almost useless.

 
 

Pet Peeve

When I look at permission groups while doing a site audit to find what all is broken, I often find these common issues:

  • No text is in the description.
  • The group is owned by the individual who created it.
  • The group’s membership is visible only to those who are members.

 
 

Why is this bad?—

Everywhere you see a place to add a description, I’d beg you to add it except in your lists’ columns. A description for a permission group should probably include why it was necessary and no other existing group would work along with the date you created the group. Annotate in the description when you might have had to rename it. How often have you seen an office change its name? Don’t create a new group and delete the original. DON’T. It can create all kinds of issues later. If Human Relations changes to Human Capital, just change all of the HR references to HC. It’ll save you a lot of pain.

 
 

Groups should never have a single point of failure to update the membership, and you are that failure if you list only yourself as its owner. Make either the site’s administrators group the owner, or create new groups just for managing the membership. Assume your office is structured like CFO 1, CFO 2, CFO 3, CFO 4, CFO Leadership, CFO Front Office, and CFO Site Administrators. As the site administrator, your function is to build apps, and all of that stuff. You should not need to be involved in the office administration of bringing on new staff or removing them when they leave for a better position. If you make the CFO Front Office staff the owner of the CFO 1, CFO 2, CFO 3, CFO 4, and CFO Leadership groups but give them adequate training to understand why they shouldn’t allow someone from CFO 4 into the leadership group, there is little reason they cannot fulfill this duty better than you can. This is because you shouldn’t have all new users run through you. When I see this, it is usually because even the SharePoint site administrators now what their own little empire that so many others had been guilty of creating.

 
 

Lastly, unless you are a SharePoint site collection administrator for the Masons, everyone should be able to see the membership. Microsoft defaults this way in the rare event that your SharePoint environment is facing the open internet, and you don’t want someone to punch in the URL for each group to figure out who to phish. Obviously, if your SharePoint environment does have the open internet accessing it, lock that stuff down as much as you can and preferably with AD security groups so bad actors with nefarious motives cannot use the URLs to scan through all of the users of the environment. I usually find this kind of problem not during a site audit but when someone says their workflow won’t work. If your workflow wants to email everyone in the Leadership group but your average user doesn’t have access to see who is in that group, the workflow cannot create the email. And what does it say about your or the organization if you don’t trust your coworkers enough for them to know the membership of such groups? Should someone be walked out of your building because you believe they are a security risk?

 
 

To wrap this up, plan your permissions before you implement them, never grant permissions directly to individual users, and document everything you do. I hope that you have gotten something out of this.

 
 

 
 

SharePoint Saturday Pittsburgh

For the second annual SharePoint Saturday Pittsburgh, I got to speak again. Great venue at Carlow University, but I’ve not got the best AT&T coverage. I don’t know if it is the building or the location of the nearest tower. I stayed at the Hampton Inn in Irwin because it was very nice and less expensive than the Hampton Inn right next door. Plus, I didn’t want to worry about rush hour traffic leaving Pittsburgh when I was arriving on Friday night.

 

The schedule for this was great. I love that I know most of these speakers already. Some really great folks signed on for this. I decided to sit in on the following sessions:

 

John Ramminger’s Leveraging External Data in SharePoint Online and On Premises

Learned a lot here. Helping me to finally try to use Business Connectivity Services.

Tim Beamer’s Document Security in SharePoint, permissions aren’t enough

I think I can comfortably set up Data Loss Prevention in SharePoint for one of the guys I’m working for. I don’t know if I read about this or saw another session on it a year or more ago, but I could swear that I’d seen a lot of this content before.

My own session, SPS Analyst Series: The Build Process (I’ve given the same session over and over for a couple years now, but I do make tweaks.)

Wish I could have seen Joe McShea’s session, Spice Up Your forms and Views with Client Side Rendering (CSR), or Nikkia Carter’s session, BI: From the Basics. She is really good, but I see and talk to her often enough that I might be able to pick her brain another time.

 

Mohamed Derhalli’s Styling SharePoint Pages without Writing Code never happened.

He didn’t make it, so a bunch of us stayed in the room and just talked about crazy stuff we were running into. That is the best. A conversation is better than a lecture any day.

 

CA Callahan was the main reason I stuck around until the end of the day when I knew I’d have a five-hour drive going home. She had Now where did they put that? Overlooked web parts, features, and templates of SharePoint.

I always learn something new when I listen to her. The main thing this time was Word Automation Services. I had never even heard of that. One can create aspx files from Word documents with this. I really need to see it in action. To convert the content in a Word document from someone’s user guides or standard operating procedures, I had been publishing the Word document to a wiki then copying the html out of the body into the page where I wanted it. The best part of this was being able to have pictures come through properly formatted, and it is great for creating knowledge base articles. You can even make properly formatted Word templates for each kind of KB article you have so that the fonts, colors, and formats are all locked in place from a document library that has the template in its content type. This is definitely something I need to investigate further.

 

Sponsors of SPS Pittsburg included the following:

 

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.