Put OneNote Meetings in your SharePoint Calendar

If your organization uses SharePoint, there’s at least a few Calendar apps devoted to meetings. It’s the best, most versatile way to display and keep track of meetings—both future and past—for a group.

If you’ve ever used OneNote (combined with Outlook) to generate meeting notes, you know how superior it is to anything else for that purpose; the best formatted Word templates just can’t compete.

Wouldn’t it be great to put these two things—SharePoint Calendars, OneNote meeting minutes—together so that you can combine their strengths? You can, and it’s easy!

Add a ‘OneNoteLink’ column to your Calendar

  1. In your Calendar, create a Multiple lines of text column, Rich Text (not Plain Text).

    SharePoint Multiple lines text column name OneNoteLinkI like using the name “OneNoteLink“…it’s descriptive without being restrictive (see “More uses” below).

  2. Set Number of lines for editing to 1 line…that’s all you’ll need.

Use OneNote for your Meeting Notes

  1. In your meeting invite in Outlook, click the OneNote button to generate meeting notes.
  2. Save it in a common shared Notebook, in the appropriate section.
  3. Use that to capture the notes from the meeting.

Connect them together

  1. After your notes are in OneNote (use Send by Email so it automatically goes to the participants), right-click on that page and click Copy link to page.

  2. Back in your SharePoint Calendar, Edit the event item for the meeting.
  3. Paste the link to the meeting notes into your OneNoteLink field. Done!

Now, you’ve got the best Calendar working hand-in-hand with the best app for meeting notes. No more losing minutes in document folders or replicating metadata columns in a separate library…use the Calendar event for that!

More uses

  • Have a Calendar for a conference, or a something similar. Take notes in OneNote, then use a OneNoteLink to connect them.
  • Multiple lines of text columns—even enhanced Rich Text ones—have their limits. Use a OneNoteLink to expand that limit greatly.
  • Don’t use boring, unsearchable attachment files to a List item when you can use a OneNoteLink to jump to a page (or section) to hold all the files, or even their printouts. Search Bar for the win!

Recruiters, Stop Sending Word Forms

Recruiters, get with the times. You are wasting far too much time copying and pasting data from Word document. Give me 10 minutes to get your life back. Let me explain. I search for all of my clients and route them back through the company where I work so I can W2. Long story short, I really don’t like to 1099 because I once had an issue getting paid, and I won’t deal with that again. On LinkedIn, when I flip my status to show that I’m looking for 1099 (that I’ll convert to corp to corp), I get a spike in recruiters where it might have been only 3-5 a week to about 5-10 a day. Many ask for additional information I guess to attach to my file they want to keep on me. Some ask for me to just send it back in an email. Some want me to fill out a “form” in Word. It isn’t really a Word form, just a document with a table.

Here is part of one I was just sent:

It isn’t hard for me to quickly fill it in, and I’m sure he wants to make it as easy as possible for candidates so that he gets a higher rate of responses, so from that aspect, it works. For you as a recruiter, however, I guess you must copy and paste pieces of this into Excel or some kind of CRM to add me to your master rolodex, what makes you valuable. I’ve done some recruiting for my company too. I know that your list of contacts and how you’ve managed those relationships continues to pay you. If you are sending me these kinds of Word documents, I guarantee you are wasting too much time copying and pasting.

Here is how you can get the data fast and easy. Moreover, it makes it really simple for these candidates to reply over their phones too. If you have Office 365, go to https://forms.office.com. You will see something similar to this:

Create New Form

Give it a good name by just clicking on Untitled form and changing it. It is up to you to add a description or not. Maybe you might want to just give the candidate a disclaimer of how you might use the data and won’t sell it to people trying to get them to buy a new warranty for their car.

Click Add question.


You get this and are able to select what kind of data gets saved. I like choices whenever you can use them because you can keep them from fat fingering data, and it helps you group sort and filter later.

You can even select Multiple answers on this in case you want to ask them something like this:

Keep hitting Add question until you have everything in there that you’d like. I added a few more here and ordered them how I wanted.

Now, at the top of the page, see where it said Preview? Click it. You will see how it will look for the people when you send them the link. But wait there is more. Look at the top right of the page. It will show you what it looks like in a mobile view. Click on that. This is how mine looks:

Pretty, right? Hit the back button there and click on Share.


It defaults to only allow people within your organization, but you can check it so that anyone with the link can respond. Then copy the link or start an email. If you want to collaborate with other people on your team to ensure the form looks just how you’d like, you can share it for that reason. Send it out. And the magic is when you get your responses. When you click on Responses tab, you will see the number of response, the average time it takes to complete, and its status. It will also allow you to open it in Excel. From there, you can copy and paste hundreds of responses into SharePoint or your CRM, or forward them to the clients you are head hunting for.

So, before your next big event, you can make one of these forms, open it up on a tablet, and let all of your booth’s visitors fill it out, or you can send it via Indeed, LinkedIn, Twitter, or email. Just let the system work for you. Do what you do best and leave the data collection up to the machines.

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.

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.