If you want to see which groups a user belongs to, or how an individual is granted (or restricted) access to a particular site or resource, use the “Check permissions” button in Site Settings –> Site Permissions (or any advanced permissions page).
Before we start, if you’re just wanting to email all members of the group you can “select all” then choose “E-Mail Users” from the action menu when viewing the group membership within SharePoint. This opens an Outlook window with all the addresses pre-populated.
But, if you still need an excel sheet of membership for another purpose (perhaps to format a sign-in sheet, generate documents with mail merge, share the list with others, etc.) follow these steps:
- With the group open in SharePoint, copy the URL and note the ID number at the end of the URL
- Open a new excel workbook
- From the “Data” tab, select “New Query” –> “From Other Sources” –> “From OData Feed“
- Paste the group URL in the prompt but delete everything after the site address and replace with the following, replacing “6” with your group’s ID from step 1
- Click “Edit” once the group loads so we can choose which columns to keep/delete
- Ctrl+click the column headers you want to keep
- Right-click a header of a column you’re keeping and select “Remove Other Columns”
- Close and Load
- You should now see your group membership and email addresses (and any other fields you kept). Save this somewhere and, if updates are made in the future, just click “Refresh all” to bring in new members and remove old.
This error message tends to reveal itself whenever you’re dealing with item-level permissions. Try the following to resolve this error.
Note: For any change to a workflow, you’ll need to start/restart your workflow to test it. Resuming a workflow will only resume the previous version of the workflow (still broken).
SharePoint Designer is a fantastic workflow builder – but sometimes, if your workflow isn’t built correctly, implementing item-level permissions via workflow could fail and leave your submitted information or documents vulnerable to data spill. A safer, more reliable method is to use out-of-the-box (OOTB) item-level permissions.
This OOTB method is great because it applies to all items, former and future, while workflows would need to be triggered for previous items to be set. This becomes tricky to do retroactively when your lists could already have thousands of items. This OOTB method is also not dependent on other steps or actions that could fail, as it might be in a workflow.
When you’re working with item-level permissions in SharePoint, you will see this message in advanced settings:
“Note: Users with the Cancel Checkout permission can read and edit all items.”
Here’s how to check to see if a group or individual has that cancel checkout permission, or add it if needed:
If you’ve found this post by search, you’ve likely already gone into the workflow settings for a particular list or document library item and have clicked the info icon () next to “Internal status” and found that your workflow is “in progress”, but has an error: “Access Denied. You do not have permission to perform this action or access this resource.” Peering into the bulk of the message, you see a helpful tidbit that includes sp.utilities.utility.SendEmail. This could be from a number of causes, but here are the summaries of three possible solutions. Note that the first solution is still required even if you try B or C below. I’ve only included the second and third solutions as additional possibilities if the first doesn’t solve your problem.
A common question, before we begin, is what level of permissions any individual needs to be able to send an email or start a workflow generally. It doesn’t matter so much if you’re using Impersonation or App Steps, but the quick answer is a minimum of Contribute level permissions is good.
Item-level permissions come in handy for a number of situations. Here are some examples and food for thought:
- Travel plans are submitted to a list, but only those in people columns (supervisor, director, traveler) are allowed to see or find the plan by search.
- Allow “content owners” to edit documents, and everyone else to view only.
- Allow non-admin individuals to set editing permissions for documents or list items by populating a people column
Using a SharePoint Designer 2010 Workflow and an impersonation step, we can:
- Add list item permissions
- Inherit list item parent permissions
- Remove list item permissions
- Replace list item permissions
This tutorial will use the “replace list item permissions” action. Whenever you’re replacing permissions, you must remember to INCLUDE YOURSELF or admin individuals in the replacement permissions or you won’t be able to access the content or help with troubleshooting. Let’s begin!