Email alerts allow users to receive a notification in their inbox when something changes in SharePoint. Alerts are available on most SharePoint apps such as calendars, contacts, lists and so on. In this case we’ll look at configuring an email alert on a SharePoint Document Library.

The first step is to navigate to the location within SharePoint where you wish to configure the alert.

If you then select the Library tab in the top left of the page this should reveal the Ribbon Menu as shown above.

You need to locate and select the Alert Me button in the middle of the ribbon in the Share & Track section.

This will reveal a drop down menu as shown above. Select the Set alert on this library option to continue.

This will open a new dialog like that shown above.

You can now customise what the name of this alert will be called using the Alert Title box at the top of the page. Best practice is always to make it as meaningful as possible.

The Send Alerts To box should already be populated with the name of the current user. You can add additional names here if you have the appropriate security settings, however it is generally best practices for users to individually configure their own alert settings.

If the option is available it may be possible to configure the alert to be sent via SMS, in which case you would need to enter the mobile phone number. However, in most cases you will select the E-Mail option.

The email address to the right will automatically be taken from the Office 365 profile of the current user.

Depending on the frequency of change that occurs in this location you may wish to not receive alerts for every change that occurs. You can use the Change Type selection to determine what you wil be alerted to. Remember that the default All changes option means you will receive an email alert when anything changes in that location, that is when new items are created and when items are changed and when they are deleted.

Best practice is to use SharePoint email alerts only to inform you of the important changes that take place in that SharePoint location. Having the frequency of alerts set too high can result in a significant volume of emails. Best practice is therefore to start with the most infrequent option and increase the frequency as required.

You can of course edit and adjust any of these alert settings at any point in the future.

The Send Alerts of These Changes option allows you to further customise the frequency of receiving alerts from this area. Again, best practice is always to set the least frequent alert option and adjust if required.

The final option allows you to determine when an email will be sent informing you of the changes you selected previously. Electing to be alerted immediately can be very distracting when set on an area in SharePoint that is changing regularly. In most cases best practice is to set the option for a daily summary.

When you select either a daily or weekly summary you will be prompted to enter a time when the alert will be delivered. The suggested times for a daly summary are either first thing in the morning or last thing in the evening.

Once you have made all the desired configuration changes, scroll down to the bottom of the page and select the OK button to save you changes.

You should immediately receive an email notifcation confirming the settings that you have just configured. If you did not receive an email firstly check you junk e-mail folder and then verify the configuration settings via the process above.

This email is your confirmation that your alert settings for the area in SharePoint have been set. The email should provide a link to the area in SharePoint that you configure the alert on (here Demo) and a link to where you can change all the alerts you have configured for the SharePoint site.

Now when an appropriate change is made to this area you will receive an email advising you of the change as shown above. These notification emails are not sent instantaneously, they are sent by a regular job that runs on the SharePoint server every few minutes so they may take a few moments to appear in your inbox.

As noted previous, it is generally best practice to avoid using many emails alerts with SharePoint as the volume of notifications can become overwhelming. You can return to the Alert Me button at any location and select the Manage My Alerts option.

You will then see all the alerts you have configured across yoru SharePoint site. You can select and delete any you wish easily or by simply clicking on the name of the alert you can modify its configuration.

Not only can you create an alert on an app inside a SharePoint Team site but you can also create an alert on an single item, in this case a file in a Document Library.

In this case you select the individual file in the Document Library and then File tab in the top left of the window to reveal the Ribbon Menu as shown above.

In the middle of the ribbon you will again find an Alert Me button you can select. Once selected you will follow through the same process as outlined previously about setting an alert, only in this case the alert will be on a single item in SharePoint.This single item could be an appointment in a calendar, a single line in a list etc..

In summary, alerts are set on a per user basis and provide a way to let you know, typically via email, when information in a SharePoint location has changed. You can customise these alerts to provide information about varying levels of change, for example, all changes versus just deletions. You can also customise how often these email alerts are sent, immediately versus a daily summary. The notification you receive in you inbox will provide you information about what has changes as well as links to the locations in SharePoint.

Best practice is always to minimise the amount of alerts utilised on a site and their frequency to avoid being overwhelmed with emails. They however, provide an excellent method of being notified when specific SharePoint information changes.

In a recent post I showed you how you could access InfoPath with Office 2013. Even though Microsoft has deprecated InfoPath 2013 it is still supported for quite a while and is a quick and easy way to start customising the look and feel of SharePoint, especially forms.

When you enter information into a standard SharePoint list you get the standard ‘look and feel’ as you see above.

You can modify this ‘look and feel’ using InfoPath. To do this select the List tab at the top of the page.

Then in the Customize list section to the right, select the Customize in InfoPath button.

You should now see InfoPath launch on the desktop (you’ll obviously need it installed on the local desktop prior).

In the middle of the page you will see a form like the one you saw when in SharePoint but in a different layout, font, style, etc.

’’

Don’t make to changes to anything but simply select the Quick Publish button on the quick launch toolbar in the top left. It is the third button from the left as shown above.

You can also select File | Quick Publish if the quick start button is unavailable.

After a few moments you should receive a message that the form was successfully published as shown above.

If you now return to SharePoint and edit or create a new item you will see that that the form displayed has changed to match that from InfoPath as shown above. InfoPath has in effect has created new display, edit and create forms for this list in SharePoint.

The idea now will be to start customising these forms further using InfoPath and then ‘publishing’ them back to the SharePoint site. However, that will be the subject of upcoming posts.

Now what happens if you want to revert back to the original SharePoint forms and remove the InfoPath ones? To do this, select the Sites tab and then the List Settings button from the ribbon.

Then select Form settings at the bottom of the first column on the left which has the heading General Settings.

Select the option to Use the default SharePoint form (and optionally to Delete the InfoPath form from the server).

Now when you return to work with the list you should see the default SharePoint form displayed as shown above.

One of the benefits that SharePoint provides is the ability to ‘tag’ information using metadata. This can greatly reduce the structure you use, especially when it comes to documents. Thus, instead of creating a deep and complex folder structure you use metadata to tag the files into the same categories as you would typically use for folders. Doing so make navigation and searching much easier.

The easiest way to achieve this to simply add a column to the location in a SharePoint site as the above video of mine demonstrates.

The draw back to this is that column is only available in that SharePoint item, it can’t be used in other lists and libraries.

The next option is to create a Site Column, which is exactly the same as an individual list column EXCEPT it can be used anywhere throughout the whole SharePoint site. I’ll cover that in another blog because I want to focus on a solution that is even more available and powerful than Site Columns.

The Term Store provides you the ability to have nested metadata fields across every SharePoint Site you are using. As you can see from the above screen shot, the Term Store is not just a one dimensional list like an added column is, it is hierarchical.

You get to the Term Store but logging into the Office 365 web portal as an administrator and then navigating to the SharePoint admin center. Then, from the menu on the left, you should see a option term store. When you select that, you should see the screen shown above.

Like many things in Office 365 no user has the ability to edit the Term Store, so the first thing you need to do is add your user details to the Term Store Administrators box in the lower right of the screen and save the changes.

If you don’t do that then you won’t be able to edit or add to the Term Store. You know you are able to do this when you hover over an entry and a small down arrow appears to the right. Selecting that arrow will then reveal a menu like that shown above.

The example that I’ll user here is creating a standard taxonomy (i.e. metadata structure) to cover locations (i.e. countries, states, cities, etc).

At the very top level of your Term Store, select the down arrow and from the menu that appears select New Group.

That will create a folder at the bottom of your. In this case give it the name, Locations.

Select the arrow to the right of this and then New Term Set from the menu that is displayed as shown above.

In this case I will call the New Term Store Country.

Keep repeating this process to build out the taxonomy (i.e. tagging structure you desire).

Now go into a item in SharePoint, in this case a Document Library. Add a column and when asked for the Column type select Managed Metadata at the bottom of the list of options, as shown above.

 

Scroll down the page and locate the Term Set Settings area. You should now see the hierarchy you saw in the SharePoint admin center.

You can now expand the structure and locate the term to select the place to start the selections for that field from. Here I have selected Australia so I get all the states below this only.

Now if you edit the properties of an item in that list you will see the new field and a tag icon to the right indicating that it is using managed metadata.

This is where it gets cool. If I type n.s.w. in it gets rejected. Although n.s.w. is ‘correct’ as value for the state it isn’t in the format we defined in our taxonomy, so it is unacceptable. This can ensure that the data that is entered into SharePoint is consistent.

If I however start typing the name of a state I am automatically prompted with the correct value. I just need to click on the suggested entry to complete.

Alternatively, if I select the two tags to the right of the selection field I am given a view of my hierarchy from the initial location I selected previously when creating the column.

Again, all I need to is select the option I want from the list.

Now you’ll see the file has been tagged appropriately for with a location as shown above. I can sort and filter as I normally would on this field inside the SharePoint list.

If I now for example change the term from NSW to N.S.W.

I see the term has also changed for that document.

Hopefully this article gives you some idea of the power of the SharePoint Term Store and managed metadata. There is so much more you can do with the Term Store than I have been able to show here, so I encourage you to go and do some exploring and see how the Term Store can be used to create flatter and more organised structures in your SharePoint Online environment.

A while back I wrote a post about migrating from Companyweb (SharePoint on SBS) to Office 365. You can review that post at:

Migrating from Companyweb to Office 365 SharePoint

which concluded that using third party tools to do the migration to SharePoint Online is a much easier process that any other option. The drawback with most third party tools is that they are quite expensive, especially for smaller businesses (generally talking thousands).

I have always been on the hunt for a suitably priced SMB SharePoint migration tool and recently was contacted by Ajit from Lepide who kindly provided me with a copy of the LepideMigrator  for documents software.

You basically set up your source locations.

Then your SharePoint destinations, which can include SharePoint Online.

You can then migrate or copy from source to destination. What you might also notice here is that there is a Migration Analyser option.

SharePoint does have some limitations around certain file names, file lengths, etc. This can prove frustrating if you are trying to a bulk move of files and one of these conditions causes your traditional file copy via a mapped drive to bomb.

The built in migration analyser will test your source for all these known condition and alter you if problems exist. That way you can identify and take action on problem files BEFORE you migrate.

If you need to do SharePoint to SharePoint migrations, say from previous versions of SharePoint to SharePoint Online it will do this as well. It can also read and display things like the permissions of your destination as well as match securities during SharePoint to SharePoint migrations which is really handy.

Now for the best part. The cost of this tool is only USD $349 for a one year subscription of a single seat license. You can add additional seats for USD $175 and each subscription includes free support and maintenance. That is outstanding value for what the tool does, especially when compared to other offerings.

I think the LepideMigrator for documents software is an excellent choice for small and more cost conscious businesses looking to move data into SharePoint online, whether from a file system or from something like Companyweb. They also have a reseller program that provides further benefits.

With the LepideMigrator  for documents software I successfully migrated files from a local hard disk to a SharePoint Online Document Library, a complete site from a SharePoint 2010 hosted environment to SharePoint Online and finally across different SharePoint Online tenants. That probably covers the majority of what most smaller business need when they move their files to Office 365.

Lepide also have a number of other products that, based on what I have seen with the SharePoint tool, I also suggest you go and check out.

Once again, thanks to Ajit from Lepide for reaching out and letting me test a full version of their software so I could report to you.

So, if you have a need to migrate information to SharePoint Online I really suggest you check out the LepideMigrator  for documents. It is the most cost effective tool I have currently found, especially for smaller, and more budget constrained, businesses.