Hello Ravi, I have tried to use that action also as I have used it in the on prem version successfully. What I found out is that the way Nintex passes the credentials is very insecure. So in our environment those 'Office 365' type of actions are unusable.
Our SharePoint engineer stated that he is hoping Nintex will switch the method the credentials are passed to oAuth by end of this year. But of course it's in Nintex's court to do so.
regards
Steve
In my experience, SPD 2010 workflow is still the best and most efficient way to do this.
We typically have a "hidden" list called SetPermission, that all users can technically write to. And they we have our On Create Nintex workflow create an item in that list that does nothing but set the permission on the item that was just created. The SetPermission list has a SP2010 workflow that starts onCreate that looks up the itemID in the source list.
I've never gotten value out of the Nintex O365 set permission actions, so i've largely ignored them.
Have you tried adding the action, "Action Set" ? Then go to the settings for it and select, "Nintex Workflow for Office 365
| Run contained actions at elevated app permissions." - then just make sure all the actions you want to run with elevated permissions are within the action set. |
|
I tried that also but one must still provide credentials in the O365 Set Item Permissions action.
I also agree with Brent that SP 2010 was the best for the Set Item Permissions action.
I had endless issues with the O365 actions. I was initially using my own credentials to test the actions, but the workflow failed constantly. I found out a couple of things:
1. Nintex logs into O365 separately for each action (which is why the credentials are needed in the action).
2. Our user accounts are created in on prem AD, and synched to Azure. We have multi factor authentication (MFA) on our accounts (which was probably causing the issue) and we also don't have single sign-on.
3. I used some test accounts that were purely cloud accounts in O365 without MFA, that worked.
4. Instead of each O365 action needing to login each time, I created a SharePoint list with all the config details and set up variables at the beginning of the workflow to grab the Username/passwords, then used the variables in the actions. However, the only one that wouldn't work was the "SharePoint Online URL" (no idea why - I tried with both a hyperlink and a text variable, so have had to hard code it into the O365 actions, just as well it doesn't change).
5. And as suggested by Chad Sommerfield, I have placed all the O365 actions into an action set and set it for elevated privileges (just in case). Be careful of putting other actions into this action set though, because if you use an action in the set that alters an item, the modifier is a System Account, not the person running the workflow.
6. Another issue I've had (not directly related, but may be useful to you). - During testing, I've run the same workflow over and over on the same item, which eventually causes errors (of all sorts). I found that deleting that item and starting with a new item works fine!
Good Luck!
@natgimm ,
@natgimm wrote:4. Instead of each O365 action needing to login each time, I created a SharePoint list with all the config details and set up variables at the beginning of the workflow to grab the Username/passwords, then used the variables in the actions. However, the only one that wouldn't work was the "SharePoint Online URL" (no idea why - I tried with both a hyperlink and a text variable, so have had to hard code it into the O365 actions, just as well it doesn't change).
i am entirely new to nintex so i do not know how to implement your suggested step above. i am also experiencing issues with the workflow after the client enabled MFA.
