Use Calendar alerts to make sure you don’t miss out on new events

I know that I have posted this before, but it bears repeating. Our division calendar is full of events and important dates, and I love that I can connect it directly into my Outlook and have a side-by-side comparison with my own calendar. I often do that at the beginning of the week, just to make sure I’m not missing anything.

As convenient as all of that is, there is one piece missing. How do I know when new events have been added? Or, for that matter, when events have been removed?

Luckily SharePoint has the alerts feature built into most out of the box applications, and thus you can be alerted about almost any changes made to items on your SharePoint site.

You may need to set up two alerts: one for new items, and one for deleted items. A weekly summary should suffice to make sure you’re kept up to date on new events.

To set up alerts

Activate the calendar page so that only the calendar is showing on your page. Above the site logo are several tabs.

  • Click on the CALENDAR tab
  • Choose Alert Me
  • Set an Alert on this list

From the New Alert screen, I recommend that you add the site name in front of the title so that it appears in the subject line of your email.

Change Type: If you choose immediate notifications, I recommend you choose New items are added rather than All Changes.


How not to roll out SharePoint

We are in what is probably the third roll out or adoption push for SharePoint Online and Office 365. A few reasons for this have to do with how all this was rolled out to start with, and it may serve as a lesson to you if you’re thinking of planning your own adoption.

First, there was no real plan. There was a desire to build an intranet, but no real idea of how it would work and how we would end up collaborating. Going from email as your only collaboration tool to SharePoint and OneDrive is quite the leap, and our division is still getting used to the idea.

Second, I believe we are on a backwards implementation track. We should have implemented Exchange Online first since a lot of Office 365 and SharePoint Online features need the integration of Exchange Online in order to take full advantage. Instead, Exchange Online is the last piece of the puzzle that we’re implementing.

Third, we have little buy-in from leadership. While the initial push came from the Vice President, after getting the project going, there has been little interest to bring that around to actually encouraging top-down adoption.

To recap our experience, we essentially went from a horrible roll out with a foreign login process with only private team sites and lots of access error messages, to creating somewhat public sites along the private team sites so if you click on something you at least get *somewhere*.

From there we simplified the login process (future posts to provide painstaking detail on consequences so you’ll know why you want to fix this up front) and started teaching everyone the tricks for connecting their lists and libraries to Microsoft Outlook. Of course that doesn’t help the Mac users, but the PC users love it. In the next few posts I will walk through how to set alerts and how to connect your SharePoint calendar, discussion lists, and announcement lists to your Microsoft Outlook application.

Moving document libraries between sites

Last week one of our groups presented an interesting challenge: how to move document libraries from two sites to a third one.

The challenge was to move these two document libraries without losing any of the documents or without losing any of the settings we had created.

Generally, there are two ways to handle a challenge like this.

  1. Create a document library in the new location, then download all the documents from old library and upload them to the new library.
  2. Save the original library out as a template including all the content, and then installing it as a new app on the new site.

I used both methods in accomplishing the challenge, the second method proving itself to be my preferred. While the process is fairly quick, because the second method requires assistance of a site collection administrator such as myself, in some cases it may be easier for you to recreate the library, especially if you do not have a number of custom features attached.

However, if you have bunch of columns and special settings, perhaps some custom views and, in the case of one of our document libraries, it also had a template attached, it just makes sense to save your library out as a template when you’re trying to move the content between sites.

For one-time implementations like this one, I just deleted the template after I had implemented it, but if there is a need to copy the settings for a list or library, you can leave them on the site and install it later as an app on any SharePoint site in the site collection. It can save your site owners a lot of time.

Be careful with granular permissions

This weekend my husband complained that “Technology has given us the capability to turn the simplest thing into something extremely complicated.”

We were trying to look up what time a band was playing at a festival. The festival had developed a mobile website which contained no information about the cost of events, and didn’t contain the schedule for the day in question. In the end, we had to look on the band’s website to confirm that they were indeed playing, but that also did not contain a date or time. We ended up going to the festival location and asking someone in an information booth.

Why do I bring this up? I am often met with the question of whether certain groups should have subsites, or if content can live all on one site. The answer to this question is two words: it depends.

In a high tech environment we can often overcomplicate permissions required for certain systems or processes. While I am conscious of making sure that certain systems or processes should be protected, I have found that in general, people don’t tend to go to places they shouldn’t, and if you make it just a little more cumbersome for them to get somewhere, they generally don’t bother.

In certain situations, it is absolutely warranted to create a subsite accessible by only certain people, or to lock down certain document libraries for a minimal number of eyes. Sensitive information such as a department’s HR files should of course be kept confidential, and shouldn’t be accessible or even viewable by anyone without a specific charge.

When it comes to some things however, such as a basic task list, or a collection of general documents, having those extra layers of security may not be necessary, and may actually complicate matters in the long run. Having several task lists just makes it difficult to keep track of your todos, and SharePoint is supposed to make things easier, right?

I prefer to keep granular permission setting (at the item or list level) to a minimum and when I see it happening on a site, you can expect a phone call or an email from me to ask for clarification as to why it’s being handled this way. Sometimes it makes absolute sense to use your devised solution, and other times there may be other ways to handle the privacy of your processes without needing to specifically grant or deny permissions.

Setting the “My Tasks” view as default

Site owners have the capability to make some basic changes to your team sites. One of these changes is the ability to change the default view for any kind of list.

SharePoint has a great built-in feature called the Task List. The original default view of the task list is that you get to see every task that was created by anyone on your team. Wouldn’t it be great if, when we clicked on tasks, we would only see our own tasks? That was the viewpoint of several departments within our division.

As site owner, you can handle this request by opening the Task list, then from the LIST tab, selecting the “My Tasks” view from the Current View dropdown. From here, click on the Modify View button, and then click the checkbox next to make this the default view.

Now when someone clicks on the Tasks list, the default view is their own assigned tasks.

Moving Web Parts within a page

In Internet Explorer, it is possible to move web parts around on a page, so if you have a 3-column text layout page, and you want to move the content from one column to another, you can easily click and drag the web parts.

This can be especially helpful when you have a lot of text content on a page. Organizing that content in Content Editor Web Parts can really save some time down the road.

Unfortunately, some people have a tendency to type all of their content into the large “zone” areas of a page, rather than using the Content Editor web part. I am guilty of this myself as well.

Dealing with the Content Editor web part can be a little cumbersome, and it seems that there is an extra step to using them, and that is why people sometimes choose not to use it as much as they should. It’s hard sometimes to think in the future and the possibility that you might want to rearrange the content on a page.

By not using the Content Editor Web Part you will have to copy and paste text from one spot on the page to another, and sometimes formatting gets lost – especially on links. I have found myself needing to recreate links more often than I care to know, and each time I do, I come to the realization that I probably should have used a Content Editor Web Part from the outset.

So to recap: to add content to a SharePoint page, use the Content Editor Web Part.

How to do that:
From the INSERT tab, choose Web Part
From the Media and Content folder, choose Content Editor.

To change the header, click on the little triangle, choose Edit Web Part, then under Appearance, change the heading from Content Editor to your preferred header. If you do not wish the header to show, select None from the dropdown under Chrome Type. The header will continue to show in edit more, so you will see it until you hit Save on the page.

To change the content, the Content Editor Web Part needs to be in edit mode. You can then click on the content within the web part itself and make the changes you need to make.

NOTE: Only site owners with full control access have the ability to edit Content Editor webparts.