Options
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 13 subscribers
  • Views 773 views
  • Users 0 members are here
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Help - Workflow Assignment - Auto permissions?

ssential

Need some help! I thought I would ask the community before contacting support.

I've been expanding our M-Files workflows with incredible results - users are thrilled with the automation to track a document's progress, as well as notifications, assignments etc.

I'm now attempting to create a new Approval workflow, where a Finance Document needs to be approved by the indicated ApproverUser and it will move along in the workflow. 

My Workflow State has an Approver property, it's a precondition that must be filled out before saving. This creates a separate assignment to Approver.UserAccount and sends them an email with the Assignment, and if they approve or reject the assignment, the document's workflow updates accordingly. 

This all works perfectly for my testing as an Admin! If I put my name in as the Approver, I get the emailed assignment, I can approve it. No issues!

But...

When I tested with a non-Admin user, they were not getting the Assignment notification, nor could they see the Assignment in their 'Assigned to Me' View on their homepage. We use a non-document object called 'Team' to which Employees Objects are related members to a Team object, and therefore grants access to a document if restricted to the listed Team(s). The Team is therefore always tagged on a document, but Assignments are not tagged with a Team being unnecessary on this object, since assignments are always related to a document that is related to a team. 

I've been able to determine that for some reason, the Approval Assignment is given default permissions for the tagged team and I don't know where the permissions are being inherited from! 

I've checked:

  • Default permissions for the Assignment Object (no default permissions other than internal users) 
  • Users can see the workflow
  • Users can see the states
  • Users have permissions on the transitions
  • Default permissions for the Approval Class - which is tied to the Assignment Object (no default permissions other than internal users)
  • We don't have anything in our configuration rules
  • There's no where to change related assignment permissions in the workflow

What am I missing? I've tested with trying to even set different default permissions on the Approval Class, but even this still shows the other permissions?

  • 0

    Separate assignments inherit the permissions of the object in the workflow: m-files.force.com/.../Permissions-of-separate-assignments-created-in-workflows

    Since the assignment has a reference to the document in the workflow which in turn has a reference to the team you want to give access to, you should be able to modify the Named Access Control List so that Document.Team.Team members (or whatever those properties are called in your vault) have access.

    So the access control list would look something like this

    Team.Team members <-- This will give access to the document itself
    Document.Team.Team members <-- This will give access to the assignments related to the document

  • 0 in reply to Joonas Linkola

    I think we're on the right track, but I don't seem to be able to link through to our Employee levels through the NACL's, I only have the option for "Created By"

    Also, we are currently limited to 3 levels, someone said this could be changed, but I don't know where to do this. 

    Pray Thank you for your help so far, I hope that I can solve this for year end. 

  • 0 in reply to ssential

    Yes, you need to temporarily allow M-Files Admin to select a metadata relationship deeper than three levels. This default restriction is in place since too deep relationships in ACLs may cause performance issues in some environments when the permissions need to be recalculated, in this case when team members are added or removed and all the objects referencing that team need to have their permissions recalculated. This just as background information.

    Set this registry setting on the computer where you are running M-Files Admin and restart M-Files Admin. You can remove the setting or return it to the default value after modifying the NACL.

    Registry Key: HKEY_CURRENT_USER\Software\Motive\M-Files\<version>\Common
    Value name: PseudoUserHierarchyDepth
    Value type: REG_DWORD (DWORD 32-bit Value)
    Value data: default 3, so set this to 4

  • +1 in reply to ssential

    So here's how I solved it:

    The automatically created Assignment object was inheriting the same permissions as the document. 

    For our Org, we use a leveled NACL structure, that is dynamically linked to the Assignment (Class Approval) and applied the same permissions - Level 3 - Team Full, Others None. 

    However, since the Assignment object did not have the property "Team" - it meant there were no users to see the Assignment object. 

    I first tried making it so the Class, Approval, had a default property of Team - however, it did not seem to inherit the Team value, and therefore the problem remained with no users having access. 

    So I then created a workflow for this Approval Class (Assignment object) - and in the workflow I have 4 states:

    • Automatic Approval Director
    • Approval - Open
    • Approval - Completed
    • Approval - Ready for Deletion

    Then I had my first state, Automatic Approval Director set the permissions to Level 1 permissions - so everyone can see the assignment object, they just might not be able to see the linked object. **The reason for this is I didn't want to adjust our NACL to have Document.Team.Employee.User Account - because what if this nacl was applied in another situation and actually inadvertently granted access to more document via the related object? No go.  So the workflow here does what I need without comprimising the existing permission structure. 

    ~~~

    I then ran into another interesting situation: If the Approval Assignment is related to a document, and for some reason, the document advances in the workflow without the Approval Assignment - thereby it's already been approved and the assignment is no longer needed - then the approval assignment simply clears out the "Assigned To" property. 

    This was quite frustrating, and after several rounds of testing, I found the best way to handle this was to adjust the Approval workflow so the Approval Assignment's state, also changes to Completed when the "Assigned To" = empty   -- Essentially I want users to engage with the Approval Assignment and mark it approved, thereby updating the linked document, but if for some reason they bypass and update the workflow of the document (the workflow only allowing the Approver to do so) then the Approval Assignment still reflects this.

    And since the history is important on the document, and not the assignment object, this audit trail is still captured. :)  





              

© M-Files Corporation 2024 | Privacy Policy