SharePoint Rules to Live By

These have been stated by others, I am sure; but  a recent training session led me to jot down a few things that stood out as just plain good ideas:

  • Whenever possible- always create for re-use in the topmost site of the site collection (site columns, content types etc.).
    • It can be so easy to get lazy or bow to the pressure of the squeakiest wheel to just get something done FAST.
    • Take the time and do it right. Get good at speedy configuration of these items!
  • When a list or library breaks permissions inheritance, or uses any advanced features that may affect display of content to end users, SAY SO in its description.
    • I touched on this in a previous post, but it’s just a good idea. It informs everyone, from end users to support staff who need to know what about a particular content element may be different than the everyday OOTB configuration.
    • Especially true of libraries where broken inheritance + versioning + content approval + layers of subfolders x cluelessness = ZOMG where’s the Advil.
  • Whenever you can add a description to anything , DO IT. And make it worthwhile.
    • This arose during a discussion of SharePoint group creation, and led to a deeper discussion around best practices of group set-up… which probably needs its own post later.
    • This discussion included the need to expressly identify what a SharePoint group is for and what types or users are in it- meaning… DON’T simply leave the default group description text in there, for the love of God.

SharePoint Site Permissions and Security 101

SharePoint security uses the inheritance model. This model establishes access at the site level, then passes that access on down to all content inside the site (lists and libraries and the items within).

Compare it to a building where anyone can walk into the lobby. From there, you may or may not be able to go into higher floors or offices/rooms within offices/locked cabinets. 

The company owner or CEO can go anywhere/see anything in the building. His role is seamless- he never encounters a denial of access regardless of where he is in the building. 

A manager can replicate that behavior, but only so far- his role prevents him from entering certain parts of the building or seeing certain materials. The manager’s access is also seamless- up to the point at which his role prohibits him from going any higher. When he meets a locked door, he understands why- it’s part of the job.

General members of the public have the most limited role- beyond the lobby, they can’t do much. They may be able to observe or temporarily visit other parts of the building, but that access is carefully monitored.

Someone has planned all this ahead of time and put controls in place that enable these access roles. How would the building ensure its security if no planning had taken place?

This analogy carries over into the concept of a SharePoint site. Using roles in this manner provides a seamless, streamlined experience for users and ensures that they only have access to content relevant to their role within the site. It ensures the security of the information within the site. It requires (and assumes) thoughtful preparation by those managing the site. 
Continue reading

“Where’s my document?”

Scenario: User reported, “Document X in Folder Y in Library Z should be visible to all users! I can see it but no one else can… What’s going on?”

There are several places to check in a situation like this. Many may assume a permissions issue, especially when folders are involved. Broken permission inheritance, perhaps? I checked the library permissions, folder permissions and document-level permissions. Everything was fine.

Next I wondered if the document was checked out. Nope!

Lastly I looked at versioning settings. Bingo! The library had major/minor versioning enabled, with the most restrictive drafts option selected. The document in question was in draft status, therefore the only people who could see it were its creator and those with Approver permissions. No one else would be able to see it until it’s published to a major version.

To help prevent situations like this, make sure those using the library understand what settings are in place. Versioning applies to the entire library, so only use it when it’s appropriate and logical for all documents in the library. It’s overkill and undue complexity to impose on users when the library doesn’t truly call for it across the board. Make sure all users understand such advanced features.

It’s also a good idea to include something in the library’s description referencing the use of versioning, so it’s not necessary to delve into the settings to discover what’s been put in place. Since permissions can prevent many from accessing the settings, users as well as troubleshooters will benefit from the heads-up.

Also, I would have made sure that the default library view displays both the “Version” column and the “Status” column, so it’s always clear what’s what. If those columns had been in place in this library, it would have been immediately apparent to me that the file was in Draft status and that the version number was indicative of that- it would have been something like 1.3 or 2.2, not the ends-in-zero number indicating a major version (such as 3.0).

Bottom line- if you’ve gone through the trouble of configuring major/minor versioning (including the strictest option for hiding viewing drafts), you should have a good reason. You should also have prepared your users for how that affects their ability to share documents. The command to publish to a major version isn’t glaringly obvious so get that training out there.

Mind the [Knowledge] Gap

Never pass up a chance to leverage work for the next time. Use SharePoint to make less work for yourself, not more.

Mind the Gap

As stated in my introductory post, I help users at all levels. I try not to over- or under-assume anything about their skill level, instead focusing on “meeting them where they live” and building an overall perception of how much or how little tech-speak or deeper SharePoint complexity to introduce into the conversation.

One might think it safe to base such a perception on the user’s permission level- meaning, it’s OK to assume a deeper level of skills & knowledge are present the higher the permissions go. Guess what? NOT TRUE. At least, not in my universe.

This particular user was owner of a SharePoint 2010 site collection (full control permissions, not a site collection admin) managing projects, which includes tracking a lot of contacts from outside the company.

I noticed six individual links to contact lists in the Quick Launch, and assumed that those links were to different views of the same list. WRONG! He’d created 6 separate contact lists. (You probably heard my head explode at that point.) Here was a person who I never would have thought needed to be educated about why what was such a bad idea. He was a site owner!!

When I explained my reaction, he replied, “Are you KIDDING me? All the time I wasted…” I felt terrible but again- this person had Full Control permissions, had recently attended a week-long Site Administrator training course, etc… he should have known better, right?

You may ask yourself, what’s inherently wrong with creating 6 separate lists? A result was achieved and the contact information got created, so what’s the big deal?

Well, the big deal is that it took him all day to create those 6 lists. When a new project site gets added, that site will also need to track its contacts. Will he have a full day to devote to this again, every time, for each new project? I think not. 

Had he called me before starting, I would have recommended: Create one contact list, configure views based on columns in the list and link those views from the Quick Launch. Even further- I would have recommended he build a Project Contact List Template- a reusable, preconfigured blank slate to allow creation of “his” Project Contact list each time one is needed, already set up to facilitate the way HIS team wants to track and present contact data for THEIR projects. We could then re-deploy it across the whole site collection as many times as needed.

  • Start with your data, which leads to development of site columns, which leads to a Content Type, which leads to list design, which leads to the List Template.
  • You get standardization, consistency and a single point of maintenance going forward.
    • If you decide a new field needs to be tracked, all you do is update the content type and that change will roll out to every single contact list where it’s in use.
    • Contrast that with going to every one of those previous 6 Contact Lists and adding the new column. Ugh- who needs that?

Calculated column to enable “does not begin with” list filter

It has always baffled me why SharePoint offered a “Begins with…” filter parameter but did not offer “Does not begin with…” to meet the opposite need. Clare Stone offers a brilliantly simple solution to this aggravating problem in her Pentalogic SharePoint Blog post, “How to Create a SharePoint ‘Does Not Begin With’ Filtered List View.” Calculated columns to the rescue again!

I also recommend downloading their Calculated Column Cheat Sheet for a great resource to keep on hand when you’re stumped about calculated columns.

See all Clare’s posts on the Pentalogic SharePoint Blog

Reusability as a SharePoint guiding principle

There are very few instances where you will interact with SharePoint and NOT find yourself in a position to benefit from re-used content in one form or another. From site columns to site templates, “one-off” content creation has practically no place in a well-planned SharePoint environment. SharePoint wants you to leverage that which has already been created, which is why so many features and tools exist that facilitate this behavior.

Create for re-use
The more you can standardize aspects of your SharePoint site, the better off you are. The more users your site has, the greater this need. Every time you create with re-use in mind, you save time and effort down the road for everyone (even though you may not see instant return on your investment). You also increase consistency, improve adoption rates, boost search results and build integration.

This is important to remember when you’re tempted to just throw another choice column into a default document library or list… instead, stop and consider whether that column should really be a site column. Wouldn’t it be better to place that column in a location where everyone could benefit from it? And while we’re on the subject, why not go ahead and save that library as a template, so no one has to recreate it from scratch? If you thought it was worth creating, chances are someone else will too.

I feel so strongly about this that I will go so far as to say ,“If you create something in SharePoint without first thoughfully evaluating it for re-use (or incorporation into an already-existing content element), you’re doing it wrong.” That evaluation should become second nature and be part of every creation process.

[Keep reading!]

What – How – Why

In the course of a typical workday, I help people at points across the entire SharePoint skill spectrum. Some days I forget that SharePoint is just one tool they use to do their real job. They are not regularly exposed to basic SharePoint knowledge many of us take for granted. Many of these “forgotten” users also tell me that there is plenty out there to show “how” in SharePoint but very little showing “why.” They want more “why” and they want it presented in an easily understandable way. The goal of this blog is to bring “what,” “how” and “why” together in response to this need. I hope it finds an audience who can benefit from it!