There seems to be an issue with the Office 365 Update Item Permissions action within Nintex Workflow for Office 365. Whenever Group is chosen instead of a user, the update fails when the SharePoint Group name is longer than a certain number of characters.
Is there any documentation about the exact limit? Furthermore, would it be possible to refer to groups by id rather than their names?
Solved! Go to Solution.
I have tested the action "Office 365 update item permissions" with a SharePoint group with the name "b" and it ran successfully.
Can you show me the error you receive when you run the workflow with a group? You can find the workflow error inside the workflow status page. The error information is generally found when you click the "blue i" on this page.
Also, can you provide the group name you were using when the workflow failed?
I'm having similar issues with this action. I'm trying to grant permissions to a group named 'Test', but the Workflow Status is set to 'Suspended' and an error message (The request cannot be processed due to internal error) is being returned in the Workflow History List. The information icon is providing the following information:
RequestorId: 2e7ecf15-dc8f-0695-0000-000000000000. Details: ServiceNoResponse
I have been able to execute a similar action for a user successfully.
- What is the best practice to grant various permissions levels to multiple users and groups on the same item? E.g. User 1 and Group 1 should receive read permissions, Group 2 should receive Full Control permissions. Would these all be serial actions of the type 'Office 365 update item permissions'?
- To what extend does using an App Step play a role (I assume these actions are to be executed by an account with sufficient permissions) in this scenario?
I am interested in knowing best practices for item level permissions in SharePoint Online with nintex wokflow using nintex actions in office 365 I have read about App Step Action to set item permission. Is that the right action to use so that the below result is achieved? This is how we handle item level permissions now so that editors can't edit other's items once they submitted their content and the crux of the requirement Item level permission setup using Impersonation Step of SharePoint 2010 workflow in SharePoint desig...
Any input appreciated! d
Best practices for item level permissions in SharePoint online is a base fundamental thing to understand with and without Nintex. I'm not criticizing at all here, just stating the issues are SharePoint related and how you manage them can be easier or harder with Nintex.
SharePoint does permissions in a weird way, but overall they still follow a top-down approach, which means, typically the user should have some form of access to the top most place before getting access to something else underneath. This could be read or view, but generally something.
With that being said, remember the containers where permissions are best handled. Web Apps, Site Collections, Sites and then List/Libraries. When in doubt, I would always encourage users to keep permissions trimmed at those levels and dump content inside though as necessary. Item level permissions is possible, but if possible I would rather have two different libraries with read/edit permissions then a workflow constantly changing permissions inside one library.
Your assumption of the app step is good to use and their isn't a right or wrong, just depends on what you are trying to do and the requirements you have to meet. One other thing I would suggest is to use SharePoint as much as possible. Specifically to your point about restricted editors from not editing content or items that isn't theirs, try this:
List Settings > Advanced Settings > Item Level Permissions
Mind you, I didn't say not to do item level permissions, I said use SharePoint as much as possible. Here SharePoint will manage the list items and restrict people from being able to edit other peoples content if they didn't create it. They can still view it, but not modify it.
You can turn on content approval which restricts drafts from being seen and editable to some degree. You can also add users into groups for approvers or editors and then submitters. That way only a certain group can effectively edit or approve, but anyone can submit.
All in all it depends on the requirements, but SharePoint does a lot out of the box. Also it may be easier to just move a document between two libraries with read or edit permissions than just modifying permissions on one library. That way you don't have to go to each item to control its permissions, or remove a user, you can do that from the group or library level.
Hope that helps.
Not sure how you are selecting the group name. I tried typing it in and it didn't work, however when I used a variable to ensure it selected it from AD within O365, it worked and modified permissions without an issue. I would suggest based on that, using a variable to set the group name before the action and then call the variable in the action.
Let me know if that helps.
Have you managed to find an answer to your above question:
I'm having similar issues with this action.
After some tests, action works fine with a security group which is defined in the current website but doesn't work when the security group is defined in the tenant (same error as Tom van Grimbergen).
Unfortunately, I have no solution for the moment.
Is there any news on that point today from somebody else?