Permissions on a group connected team site

With Office 365 anything you do which has members will create an Office 365 Group. This applies to (new) SharePoint sites, Teams, Groups, PowerBi workspaces, Planner, Yammer and so on. With every group comes it’s own new SharePoint team site and vice versa. I do like the self service capabilities of these groups. It’s easy for end users to manage members and owners. And if needed, admins can create dynamic groups to give access based on user properties.

For us SharePoint enthusiasts it also comes with some new decisions we have to make. Whilst the membership management of groups is great, we do not always like the default permissions that are given to group members on SharePoint sites. So now we have to choose. Do we stick with the default Microsoft gives us and make sure we don’t break anything with future updates, or do we change the permissions to suit our customer needs. And if we choose for the latter, how do we change the permissions?

Default Permissions

As far as I remember we’ve had three default groups with SharePoint: owners, members and visitors. The owner group is easy, they get full control over the SharePoint site. The same with visitors, they only get read access. The default for members is edit permissions (source), and that’s somewhat opinionated. Do we need to give members permissions to add, edit and delete lists and libraries? Or have them change the metadata of a list?

In old SharePoint you had to have somewhat more advanced knowledge on how to take steps in changing the structure. These settings were not that obvious. Now with the new UI, the SharePoint team made it very easy. And when it’s easy, people start using it.

If you know SharePoint, the solution is easy. Just go to the advanced permission of a SharePoint site, tick the Members groups and change permissions…..
And then you find out, you can’t, as the option is grayed out:

As you can read from this thread on the Techcommunity, the option has been available, but removed: Best Practices for Permissions on an O365 Group SharePoint Site

Possible solutions

From the Techcommunity I found one proposed solution in the comments of a post. That simply states, create a new SharePoint group and move the group members claim from the SharePoint Members group to the newly created group.

Another option I experimented with, is using this PowerShell command:

Should I?

The PowerShell option easy and it works flawlessly at the moment. But then I started thinking, should I even use this option? To start the discussion on this PowerShell option, I started this thread on the Techcommunity.

A lot of people on various threads on the Techcommunity share the same pain with regard to the default edit permissions, but they also seem to share the same opinion that you should not change the default permission the SharePoint team gives you. There seems to be a big fear that you might break stuff that Microsoft might introduce in the future. And by the way, the contribute permission level is on the backlog of the SharePoint team, so it might be solved one day.

On the other hand, you still get the options to manage advanced permission on a SharePoint site. They even added it to the new UI. And we still have the option to break inheritance on lists and libraries. Although it might not be recommended, it’s still an option. And not everybody reads the Techcommunity for guidance.


There are a few things that I can think of when I think of possible consequences:

  • Microsoft disables the PowerShell option. They’ve disable the UI, why shouldn’t they disable the PowerShell option?
  • Microsoft might introduce a better solution and you will end up with two solutions for the same problem. My fix: revert the setting with PowerShell on all sites and start using the default.
  • It has consequences for other products using SharePoint as a service. The main product would be Microsoft Teams. And as far as I know Teams doesn’t need edit permissions. Not for the wiki, OneNote or for storing files.

My view

First of all, make up your own opinion. There’s no official guidance and Microsoft haven’t completely removed all options, although keep it standard seems to be the favored opinion.

When we need to solve real business pain, there are two options. Either use classic SharePoint sites with modern elements and manage the SharePoint groups as we have always done. I don’t like this option, as I favor the Group membership management and I would like to use features like the new Hub sites, site designs and site scripts. These are not available on classic sites (yet).

The other option is to change the permissions on a Group connected Site by adding a new SharePoint group or changing the edit permissions to contribute with PowerShell.

In the end, I chose the latter. In my cases, I was using SharePoint for just SharePoint. No connected teams or any other products. And my customer has a good experience with the new SharePoint UI and hub sites and they can easily manage Group membership.

Now we just hope Microsoft doesn’t remove this option in PowerShell.

Creating an activity through the CRM WebApi

Recentely I had to create a phonecall activity through the WebApi in Dynamics 365 CRM. As most WebApi calls are pretty straight forward, I didn’t think much of this task, although I haven’t done this before. As I knew activities are special in CRM I looked around to see examples and couldn’t find any good ones. Therefore I’m writing this post, to make sure I have an example on hand when I need one.


To create an activity you use the relevant endpoint. These are /api/data/v8.2/phonecalls, /api/data/v8.2/emails, ect. Maybe there’s an option to use the generic endpoint, but I haven’t tested this.

Json message

For a phonecall the Json message could look like this:

The special part in this are the activity parties. More special even, that it’s called phonecall_activity_parties. That array contains two objects with a navigation lookup to the record and a participationtypemask. The number in the participationtypemask stands for From (1) and To (2).

Easy contact form to CRM lead using Microsoft flow

Many companies are looking for an easy solution to process a contact form on their website to a lead in CRM. In this post I’ll provide an easy, self service solution that requires no code.


To build this solution we are assuming the following:

  • You have Dynamics 365 CRM
  • Microsoft Flow is enabled in your tenant
  • You are ok with using Cognitoform or any other form tool or custom code that can post the form data to an url
  • You already use WordPress and Contact Form 7

I’ll be using a generic approach where you parse the json data from a webhook call. The tool above also has a built in connector to Microsoft Flow. That would even be a better option, but not all platforms support Flow. This approach is very easy to implement for a developer building your website.


The first thing we need to create is the basic Microsoft Flow. Go to Microsoft Flow and log in with your Office 365 credentials.Create a new flow and start with a blank canvas.
The first step is adding a trigger. The trigger you are looking for is the Request trigger. Select it and don’t fill out anything just yet. Next, add the Dynamics 365 connector and configure it to create a lead in your CRM instance. For now just use some dummy values. Save your flow and notice that you’ll get a request url in the Request trigger. Copy that so we can use it in the Cognitoform setup.

It’s pretty easy to setup a test account with Cognitoformand and create your first form. It took me less than 5 minutes. After you are done configuring your fields, you want to go to the submission settings on the bottom of the page. Add the Flow url in the “Post Json data to a website”:

Test your form and return to your flow and you’ll likely see one run has failed. That’s ok for now. Click this failed run and look for the request body of the trigger. Copy that:

Edit your flow and click the Request trigger. Click “Use sample payload to generate schema” and paste in the json from the previous step. Now you have defined the schema from the request and you can use those schema values to create the lead. Click the “Create record” step and use the defined values form the previous step to enter the values for your CRM fields.

Now you’re all setup. Fill out a form a see that a lead is created in CRM.


For WordPress and Contact Form 7 users, there’s a great plugin available. It posts the form data to an http endpoint, like flow, with just a few clicks in configuration. At the time of writing, CF7 to Zapier is not very popular yet, but I’ve tested it personally and it works great. Although the name contains Zapier, you can use any http endpoint that accepts application/json as it’s body.

Other options

In this sample I used a service that allowed me to test this integration without creating a subscription. There are many alternatives like Wufoo or Typeform that most likely could deliver a similar integration.