Skip to main content

Our O365-based travel request workflow contains permissions we can't quite nail down.  Initially built by a vendor, we were not provided technical documentation so we're troubleshooting in-house.  

 

Permissions we need:

  • Anyone can initiate a request for themselves or another traveler
  • Submitted requests should be visible only to request Submitter, Traveler (identified in form field) and, once it enters state machine for approval, anyone identified as an Approver
  • All items are always visible to Site Owners

 

Permissions set by vendor:

  • Before entering State Machine for approval, the workflow contains two O365 update item permissions actions
    • Grant Permissions to Site Owners disinherits parent permissions and removes all existing permissions then grants Full Control back to Owners group (screen shot at bottom of entry)
    • Grant Submitter and Traveler grants Contribute permissions to Submitter and Traveler (screen shot at bottom of entry)

 

 

197313_pastedImage_1.png

 

  • SP list settings:

197324_pastedImage_3.png

 

We understand that Grant Site Owners disinherits permissions affecting Grant Submitter/Traveler ability to assign permissions to this group of users.  Nintex Support says “Since you are breaking inheritance and removing existing permissions you are removing any permissions assigned to the item for the workflow initiator”, which we understand, but haven’t provided direction toward a solution.

 

Here’s what does not work (test users all have Contribute permissions via SP settings):

  • Change Grant Site Owner FROM inherit = no, remove existing = yes TO inherit = yes, remove existing = no AND remove Grant Submitter/Traveler
    • Why it doesn’t work: List items/forms visible/accessible to all users; items submitted by Site Owners visible/accessible to all users

 

  • Remove Grant Site Owner (don’t break permissions at all) AND set Submitter/Traveler inherit = yes, remove existing = no
    • Why it doesn’t work: List items/forms visible/accessible to all users; items submitted by Site Owners visible/accessible to all users

 

  • Remove Grant Site Owner (don’t break permissions at all) AND set Submitter/Traveler inherit = no, remove existing = no
    • Why it doesn’t work: List items/forms visible/accessible to all users; items submitted by Site Owners visible/accessible to all users

        

  • Change SP list permissions for Read access and Create and Edit access FROM ‘all items’ TO ‘items that were created by the user’ then build on that with a workflow permission granting individual user access
    • Why it doesn’t work: while this does limit a Submitter’s view to items they’ve submitted, the addition of a workflow action to extend permissions to other users (Traveler, Approvers) does not function – Traveler/Approver cannot view list items/forms

 

In addition, we’ve tried publishing the workflow as the service account (Site Collection Admin permissions) and placed Grant Site Owner and Grant Submitter/Traveler actions within an App Step, neither of which appeared to have any effect on results.

 

We need to understand which action(s) will 1) prevent everyone from having access to all travel requests while 2) enabling Initiator/Traveler/Approvers to view items that pertain to them 3) allowing Site Owners access to all items while items submitted by Site Owners are not visible to all users.

 

Any feedback/direction would be greatly appreciated!

 

 

Screen shot of Grant Site Owners workflow permission:

197325_pastedImage_4.png

197326_pastedImage_5.png

 

 

Screen shot of Grant Submitter/Traveler workflow permission (and all Grant Permissions actions in State Machine):

197327_pastedImage_6.png

 

197328_pastedImage_7.png

 

Wowowow! This is quite complex to go through only by reading. Naturally the best option would be to log in and to click-test the workflow.

From what I understood is that your vendor did you a workflow but had not tested it deeply and now major use cases are not working properly? And - by "not working properly" I understands that actions setting permissions should set them the way you expect so that access to the items is limited as you need, but for some reason it os not working, right?

When I was working with the action to set O365 permissions I realized, that no matter how I'm declaring the set of groups/ users directly into field "User or group name" - whether as a string or set of variables semicolon delimited - it just doesn't work, the permissions are not set.

However when I declare list of users and group names as a variable, and the variable "inside" has semicolon delimited values and then I put only the variable to the "User or group name" field - it works smoothly.

Maybe this is your case too?

If not - we can make together deeper analysis on the issue.

Best regards,

Tomasz

Hi Tomasz.  It is a lot, I know.  Thank you for taking the time to review our issue and respond.  I understand your suggestion and have put it on the list of recommendations.  Other members of the team have received suggestions as well, we're going to put them all to the test and see what we come up with.

Thanks again for your input!

Anne 

I need a screen shot of the workflow error (if it does error), but in saying that I've dealt with this may times, torn most of my hair out over the past few months, these custom Nintex actions are very temperamental in the Office 365 environment.

Things to try to resolve

  • Put both actions in App Step which give elevated permissions
  • Your actions in the screen shots look fine as far a configuration(though the variable for users aren't required), just switch them around (and switch the remove existing from one action to the other). - This is because the workflow is running as the initiator (requester) and if you run the group remove permissions the initiator no longer has access, even though the actions is supposed to use the specified credentials
  • In the "User or group name" one remove the initiator variable and just use {Current Item: Created By} - Initiator should never be used on when used by design, in this case it should be Created By (as because you as the Admin will be restarting workflows and this will give you permission and now the actual initial Initiator )

Thank you, Tomasz and Warwick, for your responses.  We've found a solution that gives us the level of view privacy we need and corrects the flaw in the original workflow.  We knew that the workflow permission step that disinherited parent permissions was causing us the most grief, with Nintex Support's input we determined that we needed to swap the order of workflow permissions to give the action Grant Submitter and Traveler something to 'attach' to.  

Original workflow:

  • Grant Permissions to Site Owners - disinherited parent permissions and removed existing permissions then granted Full Control back to Site Owners group
  • Grant Submitter and Traveler - granted Contribute permissions to Submitter and Traveler

Current workflow: 

  • Grant Permissions to Site Owners - removed this action 
  • Grant Submitter and Traveler - disinherits parent permissions and removes existing permissions then grants Contribute permissions to Submitter and Traveler

Nintex recommended swapping the two original actions.  We tested without Grant Permissions to Site Owner and found that everything works the way we want it to.  We opted not to add an unnecessary action to an already leggy workflow.  

Again, many thanks to those who replied. As always, your support is greatly appreciated!

Glad to hear you got it sorted! and shared to resolution - hopefully saving others from loosing their hair!

‌ if you solved the problem can you please mark any from the answers as "correct" (yes, this can be your answer either ).

Regards,

Tomasz

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings