"Why Managing Document Versions in SharePoint is So Hard (and What to Do About It)" expanded

Get your free Standard Operating Procedures guide

Creating Standard Operating Procedures for your organisation doesn't have to be complicated. This guide will introduce you to the whole lifecycle from creation to training and distribution.

Get your free eBook

See all of our free eBooks

The post “Why Managing Document Versions in SharePoint is So Hard (and What to Do About It)” expanded appeared first on Collaboris.

Policy Approval Workflow

2) Create the flow

1) Begin by selecting + Create and then select "Automated cloud flow" in Power Automate.

This will create a blank flow canvas for you to create your workflow.

3) Set a trigger

Our flow needs to start when a new file is added to a SharePoint Document Library. Select "When an item is created or modified (properties only)" as the trigger for this flow. 

• In the Site Address field, select the site that contains the document library you will be saving the policies needing approval to.
• Then select the document library name from this site that will contain the policy you want to get approved.

4) Retrieve the approvers details to use in the flow

As we want to direct the approval to the appropriate group of people, we need to link to Entra. Add a new step into the flow and search for Entra. This will narrow down the available steps to those relating to Entra.

Note: You may need to Sign in to Entra

Enter "Entra" in the search box and select the "Microsoft Entra ID" option to only show the Entra Actions

Scroll down the list of possible actions and select "Get group members"

Enter the Group ID for the group.

This step will retrieve all of the group members details, however, we only need to retain and use the email address for later in this flow.

5) Select the email details for the approvers

Now you need to select the group members email details

6) Add an approval step

Next, add "Start and wait for an approval" to this flow. You need to decide how many people need to approval the item, and whether they all need to approve the policy, or if you only need one person to respond. It is possible to select "Everyone must approve" and only add one name to the list. In this example, I am only going to need one person out of my Policy Approvers Group to approve on behalf of the entire group.

I chose, "Everyone must approve" and called the step "Approve policy"

• In the "Assigned to" box we need to dynamically use all of the email addresses we retrieved in the previous step. Note: All of the people listed here need to have access to the SharePoint site/library for the flow to work. 
• Because the email addresses need to be listed one by one and separated by a semi colon (;) to achieve this we need to use a join function. 

join(body('Select'),';')

Note: If only one person is named in the flow, no approvals will be made when they are unavailable.

• Select the same document ID as in the previous steps and add the document's title in the link description. These will be included in the approval request so the approver can see which item they are being asked to approve.

Each user specified in the "Assigned to" field will get an email requesting that they approve or reject the item.

The item will be either approved, or rejected depending on the criteria you selected in an earlier step. 

Reza added the "or modified" bit at the end and explained how this can create a infinite loop. If the file is modified it will re trigger the workflow.

7) Add condition to check the output of the approval

The next step is to react to the decision made at the approval stage.

If the decision is to approve the item, you may like to send an email to it's originator congratulating them. Or if the item is rejected, you may like to send an email explaining why and detailing any necessary changes.

In the condition box, set the Outcome from the approval stage to equal Approve as shown below.

This means that if the approval decision is to approve the item, the flow will continue along the "If Yes" path. If the item is rejected, the flow will follow the "If No" path.

8) Define the "If Yes" path

If the policy is approved, I want to

• send an email confirming this to the originator and also
• move the file to a different location 

In the "Send an email" action, add the email addresses you want the emails to be sent to. Give the email a subject and also write the main text for the email.

You can include dynamic text in the email. Remember to select the fields from the "When a file is created or modified" step to ensure you refer to the item that have been approved.

To move an approved file into a final location, you can identify the current and destination folders in a "Move file" action.

You need to select the "Identifier" field in the "File to Move" field so the flow can identify the correct item to move.

There are drop down options to choose a solution in case a file with the same name already exists in the final location. 

9) Define the "If No" path

If the policy is rejected, I want to send an email explaining why and requesting and necessary changes.

In the "Send an email" action, add the email addresses you want the emails to be sent to. Give the email a suitable subject and also write the main text for the email.

10) Testing the flow

Once your flow is completed, save and then test it to make sure it all works as expected. Click the "Test" icon at the top of the screen and Add a file into the 

You will have the option of either

• manually triggering the flow (by adding or modifying a file into the first location) or
• automatically triggering the flow. This is useful if you want to retest the flow using a file that was previously added or modified.

The flow will then run and you will notice a coloured icon at each stage to show whether it was successful or not.

Getting your policy read by end users

The process so far has focussed on creating a policy and getting it formally approved. Your next challenge is to ensure the right employees receive the policy and agree to its contents. You could create similar workflows in Power Automate. However, this can become complicated if you need to send lots of policies to hundreds of employees. 

DocRead can help you to easily send policies and documents to the right groups of employees. It will also track whether they have read/understood/accepted the information provided. A reporting suite provides access to proof of compliance. The reports can also be used for tracking and monitoring or as evidence should something go wrong.

DocRead is a compliance solution that is compatible with Office 365 and on-premises versions of SharePoint. It allows you to continue storing standard operating procedures and other important information securely in SharePoint. SharePoint search, versioning, approvals and permissions can all continue to be used with DocRead providing functionality to enhance your SharePoint experience.

We have been developing policy compliance solutions for SharePoint for over 12 years.

We understand how Compliance Managers struggle to ensure all employees have acknowledged critical documents like policies or procedures. 

That's why we created DocRead, a tool that allows you to distribute policies, procedures, and important documents to employees and track acknowledgments, ensuring employee compliance and accountability.

All without leaving SharePoint.

Want to see how we can save you time and automate your employee compliance?

Find out more

DocRead has enabled us to see a massive efficiency improvement... we are now saving 2 to 3 weeks per policy on administration alone.

Nick Ferguson

Peregrine Pharmaceuticals

Feedback for the on-premises version of DocRead.

The post Creating a Policy Approval Workflow with Power Automate appeared first on Collaboris.

The post Creating policy review reminders in SharePoint appeared first on Collaboris.

When setting out on the road to develop and sell a product in SharePoint – as we were four years ago – you will more than likely have the idea that writing the code and perfecting your product is the key to success. You will probably have thoughts like “My app is so cool, once people hear about this, it will sell itself”. In this post I want to share a little of our history and hopefully pass on some of learnings, tips and stumbling blocks that we have picked up along the way. Anyway, let’s get started …

I still remember the day we celebrated that last bug fix – what a feeling! We had done our research and spoken to as many people using SharePoint as we could. We knew that every organization would have some use for DocRead for SharePoint. After all, it solves a big problem by allowing an organization to send and track important ‘must-read’ documents. You no longer needed to dish out paper copies of the ‘Code of Conduct Policy’ or the ‘Employee Handbook‘ and then beg employees to read, sign and send it back to you. We could now take care of all that electronically and the best part was that you don’t need to use anything else apart from SharePoint! Once word got out it would sell! In fact, we probably wouldn’t have to do much marketing. A few blog posts here, few discussions there and those orders would come flooding in. We could not have been more wrong!

As a bit of background, myself, Hugo and Paul, (who founded Collaboris) were all highly experienced SharePoint specialists. Before founding Collaboris, we worked in some massive organisations (NHS, Microsoft, Lloyds of London, Tarmac, Pfizer, BT and Lloyds Bank) doing only SharePoint development. Long nights wrestling with SharePoint was our thing. Coding was our thing.

Writing the last line of code is actually the easiest bit

Why? Simple. We were all technicians, this was what we knew, what we were good at and was our comfort zone. Back then, we had never sold a product to ‘the world’ we were generally given a spec, we solved the problem and everyone was happy. We didn’t know what was in store for us.

Looking back, if I think about the tasks that lay ahead of us we would never have started. I see this as a good thing… It reminds me of the film ‘Alive’ where the survivor walks for days to get over a peak only to see miles and miles of Andes mountains still to go. If you told him up front how far he needed to go I bet he’d have given up.

Here are some of the tasks we were faced with at the start of our journey (just pulled from our Office 365 list):

• Develop Software License Agreement with Solicitors
• Research Market and identify SEO strategy
• Decide on a CMS for Collaboris.com
• Website / graphic design and content creation
• Develop screencasts to demonstrate DocRead
• Produce User Guides & FAQ for SharePoint 2007 and 2010
• Automate DocRead Testing
• Social Marketing
• Find a CRM and learn how to use it.
• Customer account managment
• Move to SharePoint On-line to centralise company docs
• Pricing Strategy
• Design Early Adopter / beta Program
• Develop product Roadmap
• Business Cards
• Create and advertise a Reseller Program
• Create a Help Desk management system and respond to queries
• Support Program and Offerings
• Fund all of the above activities!

This is just an extract of our original ‘to do’ list, which represents a small proportion of what we really had to overcome and achieve.

Concentrate on the 4 pillars

If you just see that list above it will scare the living daylights out of you. However, if you group those tasks into 4 key areas, it starts to get more manageable :

• Delivery  (The Build and Test) – getting your product built, fixing it and adding new features, providing tech support
• Marketing (Telling the world) – blogging, product information, social networks, discussion.
• Sales (Selling it) – pricing, resellers, demonstrations, invoicing, ordering and managing the pipeline, post sales and account management.
• Company Administration (Keeping the books) – VAT, company tax, statutory returns, expenses, salaries.

There are plenty of other tasks to worry about like managing the company, hiring staff, and commercials, but the 4 pillars above are the ones that need to be addressed on a daily basis. If you take your foot off the gas on these, it’s going to hurt. Company Administration is slightly different because many of these tasks are driven by the need to meet specific deadlines and avoid financial penalties, so whilst it may not be a full time task, taking your eye off the ball can be a costly mistake.

Once you categorise all of those tasks into the 4 main pillars, all you need to do then is make a person in your company own a pillar. If you don’t have a person, get one who is enthusiastic, with the right skills or the desire to learn. This means someone should be in charge of product delivery, marketing, sales and lastly a fourth person owning company administration.

One man can’t do it alone

I stand to be corrected on this and would love to hear of anyone else who is succeeding, but I strongly believe (especially for SharePoint), that one man cannot survive selling SharePoint software on their own. Even if it’s a tiny web part that says “Hello World” it still needs to be delivered, tested, marketed, sold and supported. Maybe the new SharePoint App Store will provide an easier platform to launch a product, after all *some* of the selling and marketing is done for you.

Luckily, we knew from the start it would be struggle. We had already tested the water with the SharePoint Action Framework. Although this was a community project, it’s still needed large amounts of selling and marketing. We learnt a lot from SAF.

Everyone needs a Helen

Techies love to solve problems, they like darkened rooms and plenty of quiet to concentrate. They generally don’t communicate with non technical people as much as they should, preferring to stick to their own type and keeping to safe technical conversations. I should know – I only have to look in a mirror to see one! It can be difficult to pull yourself away from technical speak to talk to a business user in terms they can understand. Techies also don’t like day to day administration and prefer to concentrate fully on one task at a time. This is hardly ideal given the variety of tasks we identified above!

Every company needs a Helen (sorry, you have to find your own – this one is ours!). Helen’s a management accountant by trade, but is used to non-technical jargon and has used countless IT systems in her previous roles. She got involved when she offered to produce our webcasts as a favour. We needed someone with a good voice and who could deliver a great presentation to a business audience. She did a fantastic job.

Once these were complete, she naturally progressed to becoming our ‘Demo Queen’ and now 2 years on, she manages the entire sales side of Collaboris, looking after 4 account managers and 9 partners.

Marketing is about making friends

The final pillar is marketing. I fell into the marketing side of things as we quickly discovered no marketing means no interest and no sales. So while Hugo and Paul continued to develop DocRead. I stepped back, took one for the team and left my comfort zone to venture forth into the sea of unknown as a marketing person. I still step back in to the technology now and then. For example, I have recently led the focus group to ensure DocRead works on SharePoint 2013. I also write (and read) plenty of blog posts about SharePoint. But now, 80% of what I do has a marketing focus.

The remainder of this post lists the things I have learned and will hopefully give you some ideas to help your business sell SharePoint solutions.

A community of SharePoint Vendors

In my endeavours to tell the world about DocRead for SharePoint, I have managed to meet lots of really cool people also making a living out of SharePoint. We not only share advice, ideas, tips and strategies, but with some I have also forged strong friendships. I have learnt so much from them and also hopefully helped them out along the way. We even have a closed SharePoint Vendors group on LinkedIn where we discuss various matters related to selling software and services in SharePoint. Where we don’t compete, we even cross-market each other products.

You need to offer education about SharePoint at the same time

Whilst talking to potential customers about DocRead we’ve found ourselves offering advice about the use of SharePoint itself. For example, DocRead works really well with SharePoint audiences. It’s surprising to us techies, but more customers than not either don’t use audiences or have never heard of them. If we didn’t help educate then a major time saving method of automatically organising users into groups would be lost. This takes time as you often have to sell the benefits of SharePoint or help with adoption before your solution gets a look in. Be prepared to coach and train.

Social Networks – company pages

We maintain 3 company pages.

• LinkedIn
• Facebook
• Twitter

Any more than 4 and it’s too much work (although HootSuite helps automate posting to most of them). I try and pop updates to each one when I get time. They do provide traffic to the site, but in my opinion company pages are all about giving multiple ways for customers to see who you are, what you do and about being totally transparent.

SharePoint Newsletters and the SharePoint Community Group

For those of you that don’t know we have managed and moderate the SharePoint Community Group on LinkedIn since 2007. It’s now getting towards 25,000 members and to keep the group up to date we attempt to send out a weekly newsletter with all the latest and greatest in SharePoint.

If you have a community, e-mail list, Google Circle, army of twitter followers, consider writing a Newsletter. Generally I would consider our newsletters to have the following pros and cons:

Pros:

• We are able to give something to the community to keep them engaged.
• Gives me the opportunity to see what’s happening in SharePoint. Without it I would be head down in DocRead world.
• We place a DocRead advert, or sometimes a short piece in each one, this gives some exposure to DocRead.
• As we have such a large readership I am able to arrange marketing partnerships with other vendors and organizations. Always a good option to have when I have exhausted the marketing budget!

Cons:

• The only downside is time – they take a day to put together.

Automated demonstration environments – may not work

Last year, I put together an automated test sand-pit hosted by Cloudshare. It took me 3 weeks to complete and included on-line guides along with sample tasks, documents and users. The environment offered interested parties the chance to use DocRead without having to install it in their test environment. But it never really took off which surprised me. This was nothing to do with Cloudshare, it’s was more to do with SharePoint itself. The product is so massive, it’s very easy for users to get off-track and end up on screens they don’t know how to back out of. We quickly found that getting the ‘demo queen’ for an hour on GotoMeeting was a far more effective strategy.

Cloud-based Test environments – you should consider them

DocRead supports all versions of SharePoint (2007, 2010, 2013). Each release needs to be tested against each version of SharePoint, as well as testing upgraded versions of DocRead. That’s a lot of environments when you take into account the Foundation versions of SharePoint. Most of the development gets done in our London office and a lot of the testing gets done by our staff up in Yorkshire. We have found Cloudshare to be inexpensive and a great way of testing. Once we find a bug we can simply send a copy of the environment to the delivery team to demonstrate it. We also strive to automate as much as possible using Selenium.

Say hello to Trello

If you are a person that likes to visually see the state of tasks then Trello will be your best friend. It works on a card and swim lanes idea, is all browser based and allows you to drag a card from “doing” to “done”, or “bug” to “fixed” and so on. It’s so easy and quick to use that it makes managing tasks a dream. We also tried quite a few other methods to get to this approach.

Get a C-R-M

When your marketing starts to pay dividends you will be asked for quote requests, demonstrations, downloads as well as normal queries. All of this contact information needs to be managed centrally. In the early days we maintained this in a spreadsheet, but when you have 5 sales staff and a few partners wanting to update it, it leaves you wanting more! We went with Highrise as it’s cheap and functional. Luckily, we are at now at the stage where we’ve outgrown Highrise and need more sophisticated features such as those offered by likes of  Microsoft CRM and Salesforce.

Make support your priority

(Lise Rasmussen, SharePoint Architect  @ Polarcus)

One of our main goals at Collaboris is to offer fantastic support. I know a lot of companies say this and it’s somewhat of a cliché. As a company founded by people who have been on the receiving side of bad support we want to make ours exceptional. We all take huge pride in what we deliver, we built it, DocRead is our baby. When a company encounters a problem with DocRead (which they do from time to time) it feels like one of your children is misbehaving at school. This leads onto our next point.

Get a support system to manage support requests

To help you manage the incoming support requests you will need a nice way to triage them among your technicians. You will also want to  ‘push out’ support in the form of knowledge base articles and discussions. We use Zendesk to do all this and it does a great job.

We quickly learnt the usefulness of creating knowledge base articles! Any time you put a resolution into an e-mail you are causing the following problems :

1. The resolution is not easy to find – it will hidden away in one of your support staffs e-mail inbox’s and also as part of the ticket. Searching for it becomes a really time drain.
2. Customer’s cannot self-serve. That means they can’t go to a place and try to find a solution to their problem.

We now have a rule at Collaboris. All resolutions get put into knowledge base articles.

Don’t cheapen support

We charge between 20% and 40% per year on support, which may sound a lot, but we counter this with a couple of arguments:

1. DocRead is great value in the first place. We could increase our license cost and probably get it, but we have always followed the strategy that we want to make DocRead affordable to as many organisations as possible.
2. Also, if you want to offer great support, you need to be able to fund it.

Find your SEO mojo early

We learnt this the hard way. Like it or not Google will account for the Lions share of your traffic. We get tons from LinkedIn and “others”, but Google still is the big traffic provider. Before you write a single line of on-line content, know what your SEO phrases are going to be. Everything should be based around these phrases. If you don’t do this, as we didn’t, then you are going to have lots of pages that need to be renamed, rewritten and re-titled.

You also need to know what your competitors do and where they get their link juice from. Without doubt, the number 1 tool is SEOMoz.org. The tool is quite expensive, but the reports, advice and keyword analysis it offers are second to none.

Where we are today

Going back to my example of Alive we have travelled far, and overcome many obstacles along the way but still have more mountains to climb. Spring is approaching and the going is now definitely easier. (Ok! enough of the analogy now!)

We now have a wide variety of customers (some of which are listed here), covering all areas of the globe, in all manner of industries. One statistic we worked out towards the end of last year :- since its launch, DocRead will have sent out over a million reading tasks to people based on 4 continents. That’s a lot of people we are helping to stay compliant!

The feedback we get back on the product and support we offer is exceptional. We have great people working in our ‘four pillars’ and excellent partners who all contribute to our success. The delivery team are relentless and are about to release our latest product called DocSurvey. DocSurvey will integrate tightly with DocRead to allow quizzes and feedback to be attached to your SharePoint documents.

It’s been a tough – sometimes exhausting – very enjoyable four years. All the downsides are forgotten when we hear that DocRead is making a difference!

If you would like to see how DocRead can help save you money and reduce the administrative burden involved in circulating documents to staff and contractors, then why not contact us.

If you liked this post, please help us spread the word and share it using the social buttons at the top of this page.

Thanks, Mark

The post Running a SharePoint software company appeared first on Collaboris.

Just before Christmas I was tasked with the wonderful job of getting DocRead (our Policy Management Software for SharePoint) working on SharePoint 2013. At this point, although things appeared to be working, we encountered a few issues during testing. We also needed to make DocRead look and feel like a SharePoint 2013 application.

Some work had to be done!

Our set-up

Before I get started, it’s worthwhile understanding how we have things set-up at Collaboris. Our development team still use Visual Studio 2010 and TFS 2010. We would love to make the move to Visual Studio 2012 – but there’s no time and no compelling reasons to do so at the moment. DocRead currently runs on multiple versions of SharePoint as follows :

• SharePoint 2010 Foundation
• SharePoint 2010 Server (Standard and Enterprise)
• MOSS 2007

We also use Hyper V development machines.

Please also note – we do not intend to use any of the new ‘App’ functionality in SharePoint 2013. In the first version we are simply porting our 2007 / 2010 solution to work on 2013, which means ‘full fat’ (not sandboxed) Farm solutions.

SharePoint 2010 Farm solutions will run on 2013

If you take a SharePoint 2010 farm solution (as a WSP) and install it into 2013, it stands a really good chance of working. This is possible because Microsoft also deploys the 14 hive and all of the binaries needed to support 2010. When you deploy the solution if the Manifest.xml contains ‘SharePointVersion=”14.0″‘ then this will deploy layouts, features and so on to the older 14.0 hive. If it states ‘SharePointVersion=”15.0″‘ it will deploy to the new hive.

This is pretty useful if you want to just ‘get it working’ on 2013 and then perhaps migrate your application over to SharePoint 2013 at later date. If – like us – you want to fully support SharePoint 2013 and compile against .Net 4.0 you need to keep reading. After all, there’s some tasty features in 2013 you may want to take advantage of

Upgrade Steps

So here we go – the following list outlines everything I had to do in order to get a build up and running. If you need to upgrade a farm solution to 2013 at the same time as supporting 2010 then you will find this useful. Please leave comments on anything else you have found so that we can share each other’s pain.

Support multiple versions in one Visual Studio Solution

There’s a lot of steps to getting this all up and running so I wrote it up in a separate blog post called ‘How to support multiple versions of SharePoint in a single Visual Studio solution‘. I recommend you read that then come back here to carry on.

Change the version of your solution package to ‘15.0’

The first thing you need to do is change your ‘SharePoint Product Version’ to “15.0“. Doing this causes your solution to be treated as a SharePoint 2013 solution and will deploy all of the components to the correct locations.

Who moved the GAC?

One of the biggest changes that will catch out SharePoint developers (who have spent their life in SharePoint 2007 and SharePoint 2010), is that Microsoft decided to move the GAC (Global Assembly Cache). If you are keen debugger and forever dropping in new versions of you assembly into the GAC, you need to know that it’s moved! Dropping it into C:\windows\assembly and then trying to ‘attach to process’ doesn’t work unless you drop it into the new location.

There is now one GAC for each version of Microsoft.Net (from v4.0 and on). The old GAC is still there, but it’s used for older versions of .Net.

For a more in-depth discussion on why there is a new GAC please read this post.

SPUtility.GetGenericSetupPath method is obsolete

This will probably catch you out. If you continue to callSPUtility.GetGenericSetupPath(), this will return a link to the 14 hive (SharePoint 2010), not the the new 15 hive (SharePoint 2013). So if you are programmatically getting handles to files using this approach, they will not longer be found. Instead of this you – use SPUtility.GetVersionedGenericSetupPath(). We support all 3 versions of SharePoint using conditional compilation statements like this :

The _layouts virtual directory now has a sneaky “15” in it

If you have any code that accesses the ‘_layouts’ folder using the virtual directory that gets added to every SharePoint IIS application, then you need to use the correct version. Look at the picture below, you will notice that’s there actually virtual directory inside of layouts called ’15’.

For an example of how this can effect you code – look below. This code is returning a Url to one of our pages that’s deployed to the layouts folder. If we had not made change to include the “15” it would have pointed to the 14 hive – which is good for a 2010 solution running on 2013, but not good for us.

What else has been deprecated in SharePoint 2013?

To see an extensive list of what’s deprecated in SharePoint 2013 – head on over to Technet

If you found this useful – I would be grateful if you could share it using the social buttons (at the top), or maybe even add a link to it.

The post Upgrading a custom application to SharePoint 2013 appeared first on Collaboris.

Information Management Policies in SharePoint in my experience, are not used that heavily, but are an extremely easy way to apply policies to your documents. They are accessible from ‘Library Settings’ and are configurable per content type. For example, this means that all ‘documents’ in the library will have the policy applied.

So what can you do with them ?

Policy Statement

This will be visible in the office client application at the top of the document. When the user clicks on the button they are then shown the statement. For example, you could add a message here to say ‘confidential document please do not share’.Please note, there is no way to get this policy statement to appear on a non-office client application, such as an image, video, PDF etc.

Enable Retention

This instructs SharePoint to do an ‘action’ after a specified period. The main use would be ‘After 7 years of creating this document, send it to the recycle bin, or declare as a record’. This is a great way to govern the documents in your document library. You could also fire a workflow here if you wanted.

Enable Auditing

This offers the same options as the that available at the site collection level. In fact, if auditing is turned on a the site collection level then this will override these settings. One other point to note is around anonymous access, if you have this configured then anonymous users obviously cannot be identified in the audit log.

DocRead

If you want to be able to send out a document to groups of users and have them agree or confirm that they have read and understood it, then be able to track who has and hasn’t read it, then why not try DocRead ? DocRead is an add-on to SharePoint built by Collaboris. Find our more on the DocRead site.

The post Regulatory Compliance – Information Management Policies appeared first on Collaboris.

For many SharePoint is a bit of a black box. A large number of companies use it as an Intranet or document management system, but few really understand exactly what it can do. SharePoint itself isn’t entirely without blame. 

The post How to use SharePoint with your trusted partners appeared first on Collaboris.

The post Eight benefits of using SharePoint as an Extranet appeared first on Collaboris.

How to Add Users to a SharePoint Group

This blog post explains how to add users to a SharePoint group! Treat it as a quick-reference guide. You can find step-by-step instructions for both SharePoint online and on-premises versions of SharePoint below.

SharePoint Online

1. First, log in as an administrator and navigate to the site where the group is to be used.

2. On the site’s home page select the "Cog" then ‘Site permissions’.

3. Next, select "Advanced permission settings".

4. On the SharePoint permissions page, click on the group you want to add someone to.

5. Once the desired group has been chosen, click ‘New’ and then "Add Users" to select the users to be added to the group.

 6. Finally, add the names of the people you want to include in the group, and click "Share". You can type partial names into the box and let the people picker provide more details.

The post How to Add Users to a SharePoint Group appeared first on Collaboris.

The post How to create a SharePoint Survey in under 5 minutes appeared first on Collaboris.