As mentioned in an earlier article, Project for the Web is tightly integrated with Microsoft 365 Group. The same membership that controls access to a SharePoint site and Teams, also controls what users can or can’t do within the Project for the Web application. So in today’s post, I would like to explain this “relationship” a bit further, especially when it comes to assigning tasks within the Project for the Web application. Specifically, I will explain the difference between Members vs. Other people in Project for the Web.

No Group when the Schedule is initially created

When you initially create a project schedule, it is not attached to any Microsoft 365 Group. This allows you to get started with some tasks and even task assignments without connecting the schedule to any existing Microsoft 365 group or creating a new one. You can connect the schedule to a group or create a brand new group by clicking on Group Members in the upper-right-hand corner.

What happens when you assign a task in a schedule not connected to a group

In case you start creating a schedule, and it is not yet connected to a Microsoft Group, and then you decide to assign a given task to any user other than yourself, it will come up with the following message:

“This project has not been shared with a group yet and assignees will not be able to see their assigned tasks until it is shared. Would you like to continue assigning this task or share the project with a group?”

If you choose Add a group option, it will prompt you to other create a new Microsoft 365 Group, or choose an existing one. If you click on Just assign, it will allow you to assign a task to the user without creating a Microsoft 365 Group. However, it will also warn that resources won’t be able to view assigned tasks or manage them until the group is created.

What happens when you assign a task in a schedule to users outside of the group

There is also another scenario that is possible. You might connect the schedule to an existing Microsoft 365 Group (or create a new one), but when you assign tasks, you might assign them to users inside and outside of a group. If you assign to users inside of a group, it is all good. However, when you assign tasks to users not part of the group, you will get the following message:

“The person you are trying to assign is not a member of this group, and will not be able to see their assigned tasks until they are added. Would you like to continue assigning and add them to the group?”

If you choose Assign and add, the user will get the task assignment and become part of a Microsoft 365 Group. In other words, that user will also have access to all the other assets of a Group, like a SharePoint site, Outlook group calendar, a Microsoft Team, Planner, etc.

If you choose Just assign, the user will get the task assignment, but won’t become part of a Microsoft 365 Group.

Members vs. Other people in Project for the Web

If your schedule has task assignments for users inside and outside the Microsoft 365 group, you can easily see the rosters by clicking Group members in the upper-right-hand corner.

The Members tab will list the members of a Microsoft 365 Group.

The Other people tab will show the users who have been assigned a task on a schedule but who are not part of a Microsoft 365 Group.

The post Members vs. Other people in Project for the Web appeared first on SharePoint Maven.

If you own a SharePoint site, I am sure you followed all the best practices regarding the site security setup and permissions. However, you might also want to control the experience of the users who do not have access to the site just yet, but who might need one. Likewise, you might want to view pending access requests at any point in time and either approve or reject them. In addition, if you happened to share the site externally, you might want to track who accepted your invite and who did not. I know I listed a few different scenarios in this article, but they will all be answered by the wonderful feature of Site access requests. Buckle up and enjoy another sermon of wisdom from rabbi Zelfond. By the way, you might want to read this post till the end as I also cover some important and unintended consequences of SharePoint access Site Requests.

Default User Experience

By default, on any given site, when the users who don’t have access to that site, when clicking on its URL, will get this message.

Here they can add a personal message and press the Request Access button, and request access to the site.

You can customize this page and either disable this button or control who the requests go to. Let me explain.

How to disable Site Access Requests

If you do not want users to bother you with these requests, you can disable them altogether.

1. Navigate to the SharePoint Site, click Gear Icon > Site Permissions
2. Under Site Sharing, click Change how members can share
3. Toggle the switch next to Allow access requests to Off and click Save
4. Once disabled, the user will get a nasty message when navigating to the SharePoint site URL: Access Denied. The user does not have permissions to access this resource.

How to specify who the Site Access Requests will be emailed to

Alternatively, you can also specify who the Site access requests will be emailed to. By default, they are sent to the Site Owners. However, you can also designate an alternate email address. It can be an email address of any user, and can even be an external email address as well. And you can also add a custom message to the request access page if necessary.

What happens to the user when you approve or reject requests

When the user requests access to the site, here is what happens:

1. The Site Owners (or whoever you designated to receive these emails) will receive an email like this
2. The Owner can either Accept or Decline the request
3. In case the request is Declined, the owner will need to confirm the intention
4. When navigating the site again, the page will display a message: Sorry, your request has been declined.
5. The user will also receive an email advising that the request has been declined
6. In case the request is Accepted, the user will immediately be granted access to the site and receive a corresponding email

How to access pending and completed sites requests

If you ever want to see all the past and present, and pending SharePoint access Site Requests, this is how you do it.

1. Gear Icon > Site Information
2. Click on View all site settings
3. Under the Users and Permissions section, click on Access requests and invitations
4. From the page that will appear, you will be able to see pending requests, invitations sent to external users (more on this below), as well as the history of site access requests

View Status of invitations sent to external users

What I also really like about this page above is that it allows you to view the status of pending invitations sent out to external users. So if you shared your site externally and wondering if external users accepted the invite or not, this is the page to view this on!

SharePoint access Site Requests and Group-connected Team Sites

It is also very important to note what is actually happening to the site permissions when you accept the user request to access the site, as this might lead to some unintended consequences. Let me explain.

When you Accept a given access request, then navigate to Site Permissions (Gear Icon > Site Permissions), you will see the users automatically added to the SharePoint Site Members Group (those with Edit role)

Of course, you can change their role to Visitor or remove them altogether if necessary. However, this behavior can also lead to confusion and unintended consequences if your SharePoint site is connected to a Microsoft 365 Group (i.e., the site is part of Microsoft Teams).

One would expect that by requesting access to the site, they become a member of the whole Microsoft 365 Group (Teams, Outlook, Planner, etc.). But that is not the case. They are just given access to the site itself only. If you check the group membership, they won’t appear there.

So if you would like to add those users to the group itself and give them access to Teams, etc., you would need to add them as members of the group. By the way, I explained these two different models of security for a group-connected site in this article.

The post How to manage SharePoint access Site requests appeared first on SharePoint Maven.