Skip to main content
Nintex Community Menu Bar

O365 Workflow Suspended Access denied. You do not have permission to perform this action or access this resource

  • March 27, 2018
  • 31 replies
  • 123 views
  • Translate

Forum|alt.badge.img+3

I have a workflow in O365 that is set to run on a modified condition but I get an accessed denied error on the start of the workflow. I have full control to the list, task list and workflow history. Running the workflow manually works fine. Any ideas would be gratefully received. Error Message below.

 

Workflow Status

Activity in progress

 

Retrying last request. Next attempt scheduled in less than one minute. Details of last request: HTTP Forbidden to https://myjm.sharepoint.com/teams/CleanAirGlobalCommercial/_api/web/lists(guid'198e2e98-abe0-451b-b607-e2ae7daa6fc7')/Items(47)?%24select=ID%2CID Correlation Id: cc385cd9-a64d-6333-9737-a215cfda8c96 Instance Id: dd58b2cd-a67b-4294-b7bb-ffbed3c74839

 

Access denied. You do not have permission to perform this action or access this resource.

 

Cheers

Ian

Did this topic help you find an answer to your question?

31 replies

Forum|alt.badge.img+3
  • Author
  • 12 replies
  • March 27, 2018

I have fixed this issue

Translate

Forum|alt.badge.img+11
  • Rookie
  • 461 replies
  • March 29, 2018

hi

What was your solution, could you please provide?

Translate

Forum|alt.badge.img+2

Facing the same issue. I have a workflow to set the permission for the item, I have this action under an Action Set with Elevate permissions checked. But getting "Access Denied" error even if when try to run the workflow manually with admin account. Please note this same workflow was working fine few months ago.

‌ #elevate_permission

#

Translate

Forum|alt.badge.img+2

Figured out the issue. I was using a SharePoint group for the email and that was causing the access denied issue (don't know why). It started working when I entered the name/s, email addresses in place of the SharePoint Group.

Translate

Forum|alt.badge.img+3

I have exactly the same issue. Simple workflow, one action (send an email to a user/group specified in the current item).

If I run it as a site owner and specify a SharePoint Group as the recipient, it runs fine.

If I run it as a site member and specify a SharePoint Group as the recipient, I get the access denied error and the workflow eventually suspends, preventing other workflows from running.

The same behaviour is observed even if the workflow is run in an elevated action set.

Anyone got any ideas?

Translate

Forum|alt.badge.img+3

Noticed that it had stopped working for owners as well... Tried to move the email action OUTSIDE of the action set, and the email sends correctly.

So... Owners, can send emails to SharePoint groups if not using elevated permissions.

Members can't send emails to SharePoint groups at all.

To support!

Translate

Forum|alt.badge.img+2

Right. Experienced the same.

1. Can not send email to SharePoint Group (not even as Site Owner) in the Elevated Permission Action Set.

2. Sending email to SharePoint Group from outside the Elevated Permission Action Set works fine for Site Owner, but does not work for members.

Translate

Forum|alt.badge.img+9
  • Nintex Employee
  • 162 replies
  • April 18, 2018

Hey Guys,

Try this - https://help.nintex.com/en-US/o365/#o365/O365WorkFlow/Troubleshooting/LazyApproval7.htm%3FTocPath%3DTroubleshoot%7CLazyA… You may need to set the membership visibility of the group to "Everyone".

If you're using 'External Email' or LazyApproval, because we need to access the members of the group we need to be able to see the members, I don't believe the internal SP mail should have this issue as it uses a different mechanism for this (which is not possible when sending externally, with attachments etc.)

Let me know if this helps

Thanks,

Translate

Forum|alt.badge.img+3

Thanks Callum, that helped!

I was using Internal Email, but changing the settings of the SharePoint group to allow membership visibility to everyone allowed the workflow to run. The admin user in/out of the app step was a red herring - since the admin user was a member of the group, it could see the group members, but only when it was run outside of the app step. Put the admin user inside and it runs as the app, which can't see the group members.

Thanks again!

Translate

Forum|alt.badge.img+2

Well, I am getting the below error in one of my site and couldn't figure out what I am doing wrong.

I have used this action before in several site successfully.

Getting below error while initiated by SCA/Site Owners:

"An exception occurred while processing parameter [InputNtxConnectionId]"

Workflow suspended

Getting Access Denied when initiated by users.

office 365 uppdate permissions‌

Translate

Forum|alt.badge.img+2

Hi,

Did you manage to solve this issue (the InputNtxConnectionId issue)? I am running into the same error. If you managed to resolve it can you please share how you did it?

Thanks in advance.

With regards,

Remco

Translate

Forum|alt.badge.img+2

Hi Remco Gerrets‌,

Not yet. Nintex support mentioned that they came across this issue sometimes if the environment was migrated either from On-Prem or another O365 site using a 3rd party migration tool, which is not my case.

If that is the case for you, they mentioned then it is possible to resolve the issue by backing up the current list (or site) to a template via SharePoint's built in service and then creating a new list (or site) from the template.

Thanks.

Translate

Forum|alt.badge.img+9
  • Nintex Employee
  • 162 replies
  • June 7, 2018

Hi Remco, Debo,

This has been caused on some sites by a change in SPO in the way that a particular ID is generated for a site, the product team at Nintex is currently working on a fix for this. For updates on timing etc. I'd recommend you contact Nintex Support for more details.

Thanks

Callum

Translate

Forum|alt.badge.img+2

Thanks Callum Bundy‌. This is a very useful information. I am currently in touch with Nintex support. 

Translate

  • 2 replies
  • June 7, 2018

Thx Debo, for the quick response. Hopefully this is resolved as soon as possible.

Translate

I am facing this same issue -  (the InputNtxConnectionId issue when attempting to use the Office 365 Create Site action suspends workflow). Are there any updates on timing for a resolution on this issue, or any suggested work-arounds? Thanks in advance.

Translate

Forum|alt.badge.img+2

Hi Darren Deason‌,

As per my issue, Nintex support confirmed that the issue is related to an existing issue Nintex Dev Team is actively working on. They are investigating the root cause of the error and they are going to be applying hotfix soon to resolve this.

Initially, I thought the issue is only on the site collection I created on the week of June 4, 2018. Today I created few more new site collections for testing and I found out it is happening on all those new site collections. So, looks like it is the issue for all the site collections being creating now. My old site collections are working fine.

I'll keep posting my findings and the responses from the Nintex support.

Thanks,

#InputNtxConnectionId

 nintex workflow for 365‌ office 365 workflow actions‌ office 365 update permissions‌

Translate

Forum|alt.badge.img+2

"An exception occurred while processing parameter [InputNtxConnectionId]"

Workflow suspended

 

Hello guys,

Got an update from Nintex support. The root cause for this issue is related to back-end changes Microsoft made. Nintex dev team will be applying hotfix sometime this week, fingers crossed.

Translate

  • Nintex Employee
  • 10 replies
  • June 13, 2018

Hello guys,

Please be informed this issue should be resolved by now . Those troubled workflows should be working fine when you re-run them.

Cheers.

Translate

  • 2 replies
  • June 13, 2018

Hi,

I can confirm that this seems to have been resolved on our tenant since yesterday.  Thanks for all your input and support.

Regards,

Remco

Translate

I can confirm that the O365 Create Site action against a very recently provisioned Site Collection is working now for my customer tenant as well. Thanks Nintex product team and the attentive Nintex user community - great work!

Translate

Forum|alt.badge.img+2

Hi Guys, I am still facing the issue in some of my site collections. Anyone else facing it still?

I am in touch with Nintex support for further troubleshooting.

Thanks.

Translate

  • Nintex Employee
  • 10 replies
  • June 13, 2018

Hey Debo,

Are you still facing this exact exception "An exception occurred while processing parameter [InputNtxConnectionId]" after re-running these troubled workflows? 

Have you built this workflow at that site by dragging and dropping those actions or has it been imported from an exported workflow?

Can you please open that published workflow in that site, click on the Office 365 update item permissions to open the action configuration dialog and ensure the *Connection configuration field is pre-selected to what you had configured before publishing?

Another last thing i want you to do is to create new workflow, drag any office 365 action with connection field, configure it and publish it. Then run it and let's see how it goes.

Thanks

Translate

Forum|alt.badge.img+2

Hi Abdulkhaleq Meyad‌,

Yes, I am still experiencing the issue. All my workflows are created by dragging and dropping the actions, none of my workflows have been migrated/imported from any other site. I created a new workflow today, that too is having the same issue.

As you mentioned, I confirmed that my connection configuration field is pre-selected. I double checked the connection credentials, re-published the workflow, but same issue.

Thanks.

Translate

  • Nintex Employee
  • 10 replies
  • June 14, 2018

hi Debo Chakraborty‌,

I would recommend to reach Nintex Support and provide the tenant & site details so we look into the execution logs to get clearer picture. So far this issue has been confirmed as resolved by others used to face it.

thanks 

Translate

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie Settings