Skip to main content
Nintex Community Menu Bar
Solved

Office 365 Update Item Permissions - Access Denied

  • June 17, 2022
  • 10 replies
  • 686 views
  • Translate

Forum|alt.badge.img+6

I'm trying to set item permissions so that only the person who filled out the form can read the item. When I run the workflow, I see a message, "Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))". I'm running the action within an Action Set so that it would execute with workflow owner privilege's. Any idea what I'm doing wrong? 

 

23650iB06898305B39DFB5.jpg

Best answer by Garrett

Hi @GoIllini  This is one of those cases that needs deeper investigation on each component from start to end ... much like when you suffer a Internet failure - check with another device, check Wi-Fi adapter, check Wi-Fi connection, check Router, check Provider, etc.

 

The painful but necessary Step-by-Step process of elimination. 

1. So, Create a new Nintex Workflow.

2. Add the Action Set. Place the Office 365 update item permissions and a Log to History inside the Action Set.

3. For the Office 365 update item permissions settings, remove all/most variables

3a. List Name - Remove Var, Set with a hardcoded value

3b. Items to update - Remove Var, Set to ID equals 1 (Show the ID column, make sure it exists)

3c. User or group name - Remove Var, Set with a valid User (Should not be you!!)

3d. All matched items updated - Set Var to store the operation result. (Display this Var in the Log to History)

 

Did this complete successfully when you run it?

No - Issue is possibly with the Connection settings

Yes - Replace back with the Variables. Use a Log to History to display the Var values before the 

Office 365 update item permissions. Use another Log to History to display the operation result.

 

Now, Did this complete successfully when a normal User run it?

 

 

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

10 replies

Garrett
Forum|alt.badge.img+16
  • Scout
  • 904 replies
  • June 17, 2022

Hi @GoIllini 

 

Did you grant Full Control permission to your workflow?

Refer to Action Set documentation - https://help.nintex.com/en-US/office365/Designer/Actions/ActionSet.htm

 

Translate

Forum|alt.badge.img+6
  • Author
  • 26 replies
  • June 17, 2022

I had not seen these steps before, but yes, I have now done this. Ran the workflow again, but no change. Same error. I was able to follow those steps for the 2 "workflow" items below, but not for the "forms" one. It says I don't have access. Not sure if that matters. 

 

 

Translate

Garrett
Forum|alt.badge.img+16
  • Scout
  • 904 replies
  • June 17, 2022

Hi @GoIllini 

 

Are you the SPO Site Administrator?

 

Otherwise, you need to get your SPO Site Administrator to complete the steps

 

Can you go to Site Settings -> Manage site features

 

Scroll to the end. Find "Workflow can use app Permission". What does it say? It should be ACTIVE

 

Translate

Forum|alt.badge.img+6
  • Author
  • 26 replies
  • June 17, 2022

Yes, I have the feature as active. I am also the site admin. 

Translate

Garrett
Forum|alt.badge.img+16
  • Scout
  • 904 replies
  • June 17, 2022

Re-Publish the Workflow. Then run it. 

Translate

Garrett
Forum|alt.badge.img+16
  • Scout
  • 904 replies
  • June 17, 2022

Your Action Set has elevated privileges enabled, right. 

 

The collapsed Action Set should have a golden key icon to show that elevated privileges' are enabled.

 

I'm sure you have done this.

Translate

Forum|alt.badge.img+6
  • Author
  • 26 replies
  • June 17, 2022

Yes, I've got that checked and I do see the golden key.

Translate

Garrett
Forum|alt.badge.img+16
  • Scout
  • 904 replies
  • Answer
  • June 18, 2022

Hi @GoIllini  This is one of those cases that needs deeper investigation on each component from start to end ... much like when you suffer a Internet failure - check with another device, check Wi-Fi adapter, check Wi-Fi connection, check Router, check Provider, etc.

 

The painful but necessary Step-by-Step process of elimination. 

1. So, Create a new Nintex Workflow.

2. Add the Action Set. Place the Office 365 update item permissions and a Log to History inside the Action Set.

3. For the Office 365 update item permissions settings, remove all/most variables

3a. List Name - Remove Var, Set with a hardcoded value

3b. Items to update - Remove Var, Set to ID equals 1 (Show the ID column, make sure it exists)

3c. User or group name - Remove Var, Set with a valid User (Should not be you!!)

3d. All matched items updated - Set Var to store the operation result. (Display this Var in the Log to History)

 

Did this complete successfully when you run it?

No - Issue is possibly with the Connection settings

Yes - Replace back with the Variables. Use a Log to History to display the Var values before the 

Office 365 update item permissions. Use another Log to History to display the operation result.

 

Now, Did this complete successfully when a normal User run it?

 

 

Translate

Forum|alt.badge.img+6
  • Author
  • 26 replies
  • June 21, 2022

Well this is embarrassing. Under the "Filters" section for the field "Update the items when column", I was using the fields from the workflow Item Properties. All I needed to do was simply manually type in the field name "ID". Works fine now. It is laughably obvious now that I notice it. Thank you for your support @Garrett 

 

 

Translate

Garrett
Forum|alt.badge.img+16
  • Scout
  • 904 replies
  • June 21, 2022

Hey @GoIllini 

No worries.. these things just happens. Pretty good exercise in debugging though.

Just laugh off and learn from the experience...

 

 

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