SharePoint workflow “access denied” error sp.utilities.utility.SendEmail solution

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.

A. Person running workflow doesn’t have permission to see membership of a group being referenced in a workflow’s email action

Note: First make sure the group names in the workflow match the existing group names in your site groups. If someone renamed a group, that could be the only issue here. Update the workflow to reference the new group name and try running it again. Otherwise…

• Check workflow in SharePoint Designer to see which groups are being emailed
• Go to group settings
  • Site settings
  • People and groups
  • Settings –> Group settings
  • Change who can view membership of the group to “everyone”
    
  • OK
• Make sure all emails in your workflow that email groups have the same setting, allowing everyone to view membership of the group. This allows people starting your workflow to send an email to access the list of members and email all the members of the group.
• If that doesn’t work, consider trying B or C below

B. Try using an impersonation step in a SharePoint 2010 workflow to send the email

• This uses YOUR credentials (or whoever authored the workflow) to send the email. Once you leave the organization, this becomes problematic. See C for a better option.

C. Try using app steps (similar to impersonation steps, but better for succession planning) in a SharePoint 2013 workflow to send the email

• Note: Before being able to access App Steps (likely grayed out if you’re unable to click the button), you’ll need to update site settings –> manage site features, scroll to very bottom and activate “Workflows can use app permissions” if it’s not already active. Now open SharePoint Designer and you should be able to use App Steps.
  
• Then you’ll need to give those workflows using App Steps permission to send emails, or you will get an HTTP Forbidden error.
  1. Go to Site settings
  2. Under Users and Permissions, select “Site app permissions”
  3. Next to “workflow” select and copy everything between (but not including) ext| and @ (this is your App Id)
  4. Go to [YourSite]/_layouts/15/appinv.aspx and paste the App Id in the first field and click lookup
  5. Paste the following in Permission Request XML but DO NOT change the URL to your site – leave it exactly as it is here.
     <AppPermissionRequests><AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />
</AppPermissionRequests>
     
     
  6. Click “Create”
  7. Click “Trust It”
     
  8. If you run into problems or need more details steps, see a full write-up on this solution on the Dev Center here.