Sharing an O365 SharePoint Library External Anonymously

Just a quick post as a response to a question on a Facebook SharePoint group. He wanted to know, “Is it possible to embed a document library into an external web page?” Well, not exactly because we don’t do anonymous access any longer, but you can do this:

 
 

Synchronize a library with a folder in your OneDrive account.

If you click on the Synch button at the top of your library, you will get this:


Then you will see this possibly:


 
 

I had to kill my OneDrive to capture all of these screenshots for you folks reading. This is a person Business account. It isn’t Outlook.com or Hotmail.com. I own madwhitehatter.com, so I need to select Work or School.


Follow the little tutorial.


 
 

 
 

Change the permissions on the folder to allow anonymous access.

 
 


 
 

If you haven’t clicked on any files, click on Share.


I really like how you can set an expiration date, or even allow editing.

 
 

 
 

Take the code from OneDrive and put it on a page.

Click at the top where you see embed. You’ll see a little side window slide in.

 
 


Click on the Generate button. On the external page you are sharing, insert that piece of script.


Voila. You can now share externally. The key thing to remember is that if the person making that code ever leaves the organization, you are screwed. This is why I have a general admin@XYZ.onmicrosoft.com account for every O365 environment I am working with. If you are working with SharePoint 2013 or 2016, I’m sorry. I cannot confirm if the way that one could mirror a library to one’s OneDrive works the same way.

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.

My First SharePoint Saturday

I’m relatively new to SharePoint, compared to most. Also, I came up to the development level from the Power User end, not the IT professional end. Luckily, I found some great mentors who unlocked its mysteries and then introduced me to the greater community of experts and enthusiasts behind this stuff. SharePoint User Groups (aka “SPUGs”) meet, generally, once or twice a month in most major cities (and some towns). Somebody gives a presentation on a facet or feature of SharePoint or Office 365, with plenty of networking and camaraderie all around. If you haven’t joined up with one yet–and you’re reading this blog, so duh, you like SharePoint–you really should.

There’s also these things called “SharePoint Saturdays“, free events held annually in a lot of cities. It’s like dozens of SPUGs all rolled into one. A free conference, with plenty of speakers and hundreds of attendees. I was eager to attend one and I got my chance at July’s SharePoint Saturday New York City, the granddaddy of them all. This was the 10th annual SPSNYC, hosted at the Microsoft Technology Center in Times Square, so there was a very celebratory feel to the whole thing.

The Big Apple. The city that never sleeps. The concrete jungle where dreams are made.

It started around 8am, with time for meeting friends and sharing coffee and news before the opening remarks. There were plenty of sponsors in attendance, all eager to talk to SharePoint nerds like myself. Even if you’re not buying anything, go and talk to them, I guarantee that you’ll learn something new from every stop at a sponsor’s desk. Plus, there’s always prizes to be raffled off!

The day started in earnest, with eleven rooms and five session periods through the day. Needless to say, I had a hard time choosing which ones to attend, even at my junior level. There really is something for everyone, from IT developers and pros down to business/end users. Here’s how I spent my first SPS:

The first session I attended was Enterprise Social Collaboration at Guardian Life by Lonya French. She talked about how she and her team are using Yammer to improve collaboration at a company of 9000 employees, spread throughout the USA and India. She didn’t give tips and tricks on how to use that specific software–she explained the concepts and tactics for using social collaboration (and WHY) to help people get their work done. And not just employees–she described ways to get the leadership on board using social media tools as part of the business processes. Great stuff!

Next up was Gamification & SharePoint (Erika Harris, Cardiolog Analytics). This was a straight-up pitch for using her company’s Gamify and Engage tools as part of a SharePoint environment. Pitch sessions are fine, sponsors make these SharePoint Saturdays possible. However, I would’ve liked to spend more time on the theories and tactics behind gamification as a tool for user adoption and less time getting demos of apps and dashboards available at a price.

This is when we broke for lunch, provided by SPSNYC. Shout out to the people behind the scenes: sponsors, organizers, volunteers, hosts. Everything ran smoothly and was well-run…not an easy feat, when you’re providing a free lunch to 500+ people!

A Day in the Life of an Office 365 Power User (Serge Tremblay from Victrix) was a bit misnamed. It really was more about tips and tricks to use Microsoft Teams. Unfortunately for Serge, most of the people in the room were there for Office 365 and had barely worked with teams. He adjusted well though and showed off some of the really cool features of Teams and how it will enable people to work together better. If you want to know more about Teams, check out his blog; he’s already at the shortcuts-and-tricks stage for Microsoft Teams. He definitely knows his kung fu!

Serge was constantly giving credit to the people who’d taught him, pointing out their strengths and how they helped him understand SharePoint/Office 365/Teams better. All without detracting from his own copious knowledge and deep understanding of the tools. The number of people I follow on Twitter DOUBLED in that hour!

Users…remember them? Well, Stacy Deere-Strole & Sharon Weaver (Focal Point Solutions) sure haven’t. Trash or Treasure? was a session all about knowledge management and how SharePoint can help capture, maintain, and preserve an organization’s collective knowledge They’ve got a great dynamic, not just as presenters, but–I’m sure–as co-workers, two sides of the knowledge management coin. Stacy’s the SharePoint-database-computer side, Sharon’s the business-SixSigma-psychology side. It’s great to see their joint attitude and energy focused on making this wonderful tool do what it was ALWAYS supposed to do: make work easier for humans, not just IT pros.

Speaking of things forgotten in the lofty world of SharePoint development, there’s good old Office (the “365” part is optional) and just how awesome it is, with or without Teams. Scott Shearer (Haystax Technology) wowed us all with Office 365 Hidden Gems–fantastic tricks and ways to do work that are, even to us Microsoft geeks, hidden in plain sight. He showed off features of OneNote, Word, Access, and even much-maligned PowerPoint that we can use every day to make work easier. Find him on Twitter or check out his blog to learn just how much “plain” Office can do.

After the last session, there were some closing remarks (and well-deserved kudos to the organizers, who do this VOLUNTARILY, if you can believe that!) and prize raffles. Afterwards, most of the attendees headed off to a local establishment for a “SharePint”, another tradition of the SharePoint community. You know it’s an energetic and enthusiastic group with lots of esprit de corps when there are ‘traditions’ for an industry that didn’t even exist 15 years ago.

Things to do at a SPS:

  1. Plan your stay. I stayed at a hotel the night before the event close to the venue. Definitely worth it! A lot of people took the bus or train in the morning…that’s an early start to a long day. The conference is free, so you might as well spring for a hotel room.
  2. It’s a marathon, not a sprint. 8am to 6pm is a long day, even without an early travel start. So, get your rest, get your caffeine (or whatever) of choice, and be prepared to hit the ground running. You won’t stop running (metaphorically) all day.
  3. Get yourself out there. Introduce yourself around. Talk to the other attendees. They’re here for the same reason you are, learning more about SharePoint, so you’ve already got that in common.
  4. Go to the sponsors. They’ve got stuff to sell, sure, or they’re looking to market YOU. But you know what? These SPS’s are free because of THEM and THEIR money. So, deal with it, talk with them. You’ll still learn something.
  5. Plan your afterwards. SharePint is designed for networking, relaxing, and sharing ‘war stories’ from the trenches of SharePoint. Get to know these people. If you’re into SharePoint, well, so are they. Welcome to the tribe!

All in all, I’m incredibly glad I attended. It’s been almost a week and I’m still digesting everything that I learned. The passion and energy–bordering on mania, but in a good way–that every attendee, speaker, and organizer displayed only gave me more encouragement and eagerness to keep learning more and more. Can’t wait for next year and SPSNYC 11…oh wait, there’s one in Pittsburgh in September…and Baltimore in October…

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.

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?

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.

Views Instead of Permissions?

Recently, a former Site Collection Administrator tried to convince me to use views instead of permissions. Why would anyone want to do this? Their thinking was to allow for easy document placement on different pages (one site collection) using views and filters. There are times when using views or audience targeting to solve what an audience can see is effective, just remember this is not always the case. Adding site pages can add an additional layer of security by requiring permissions to view the page first, and then the content on the page. Can we discuss the 2 kinds of users who can still find the content not meant to be seen? The first group of users are the ones who aren’t familiar with SharePoint or who aren’t “tech savvy” and just click around and find content by mistake. The second group of users are the more advanced users who will look at URL structures and navigate curiously through them.

Using views, a person can limit what information is seen by the naked eye. Those list items or documents are not secure by any means, just hidden from plain sight. Let’s never forget the basics of SharePoint. One of the main advantages of using different document libraries or lists are the fact that each one can be locked down with unique permissions. Segregating the data can make it more secure but also makes it challenging to present it to the intended audience in the exact way that is envisioned.

In SharePoint, there are always multiple ways to accomplish the same goal. Don’t skimp on security in place of functionality. Security is about risk & risk mitigation. In dealing with government networks and corporations, the stakes of security is extremely high. Content ranges from trade secrets to classified information. Even small and medium sized business have internal documents that only warrant certain eyes.

Security must always be a priority when designing SharePoint sites and content. Views can hide content from certain users, but security through obscurity can only be used when the content isn’t sensitive. First secure the content appropriately, and then figure out how to deliver it to those who need access.

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.