Investment requests – Permissions – Part 4/6 - #ARCHIVED#

Posted on by
This content has been archived. It may no longer be relevant.  

On 2018-09-18, I gave a presentation about the business solution “Investment requests” I created with: SharePoint Online (Modern team site), PnP PowerShell, Flow and PowerApps. The 45 minutes were over before I knew it. Several topics were not, or in lesser detail, presented. I therefor decided to start a blog post series specially for this.

The blog post series has the following topics:

  1. Introduction
  2. Executing Flow actions with service account permissions
  3. Email
  4. Permissions
  5. PowerApps
  6. And something more

Introduction

Permissions were an essential part of this solution. It had to be possible to distinguish:

  1. who can read which investment request.
  2. who can create/submit which investment request.
  3. who can read process information (investment requests, statuses and tasks).
  4. who must approve/reject an investment request for which situation.
  5. who can maintain the team SharePoint groups.

Besides this, an investment request file in a team document library has to be locked while the process is in progress.

Who can read & create/submit which investment request

As mentioned in the introduction, investment requests are divided in 5 teams. Every team has its own document library. 2 SharePoint groups are created per team. One for employees who should be able to read the team related investment requests and one for employees who should be able to create/submit team related investment requests.

Permissions are set on the document libraries. All team SharePoint groups (10 in total) are also given read permissions on site level.

Edit permissions is needed to be able to submit an investment request (read: start the “approval request” Flow). Contribute permissions are not sufficient!

The team SharePoint groups have no access to the document library “Requests”, the task list or any of the administration lists/pages.

Who can read process information (investment requests, statuses and tasks)

There is one SharePoint group (“Investment requests Approvers”) which must contain all employees involved in the approval process. This SharePoint group has read permissions on the document library “Requests” and on all tasks. It has also been given read permissions on site level.

Updates to file metadata in the document library “Request” can only be done via a Flow.

Who must approve/reject an investment request for which situation

In the approval request Flows (one for every team/document library), it is determined which role should be included in the approval process. An approval request is in fact a task (item) in the task list.

After a task (list item) is created, permission inheritance is broken and custom permissions are set. Only the employee who must execute the task gets contribute permissions and therefor can execute the task. When a task is executed, the permissions were set to inherit from the list again.

Ten actions are used to set permissions on a task:

  1. SharePoint “Send an HTTP request to SharePoint” action to break the permission inheritance.
  2. SharePoint “Send an HTTP request to SharePoint” action to get the ID of the approver.
  3. Assign a part of the body of action (2) to a variable.
  4. SharePoint “Send an HTTP request to SharePoint” action to get the ID of the SharePoint group “Investment requests Approvers”.
  5. Assign a part of the body of action (4) to a variable.
  6. SharePoint “Send an HTTP request to SharePoint” action to get the ID of the owner group.
  7. Assign a part of the body of action (6) to a variable.
  8. SharePoint “Send an HTTP request to SharePoint” action to set permissions (Contribute) to the approver.
  9. SharePoint “Send an HTTP request to SharePoint” action to set permissions (Read) to the SharePoint group “Investment requests Approvers”.
  10. SharePoint “Send an HTTP request to SharePoint” action to set permissions (Full control) to the owner group.

One action (SharePoint “Send an HTTP request to SharePoint”) is needed to restore permission inheritance.

Below, url’s from the “approval request” Flow are shown. Some names are specific for this solution.

** Url step (1) **
_api/web/lists/getbytitle('Tasks')/getitembyid(@{body('Create_item_-_Task')?['ID']})/breakroleinheritance(copyroleassignments=false,clearsubscopes=false)

** Url step (2) **
_api/web/siteusers/getByEmail('@{body('Get_item_-_Authorization_matrix')?['fafp1amemployee']?['Email']}')

** Url step (4) **
_api/web/sitegroups/getbyname('Investment requests Approvers')?$select=id

** Url step (8) **
_api/web/lists/getbytitle('Tasks')/getitembyid(@{body('Create_item_-_Task')?['ID']})/roleassignments/addroleassignment(principalid=@{variables('taskAssignedToID')},roledefid=1073741827)

** Url step (9) **
_api/web/lists/getbytitle('Tasks')/getitembyid(@{body('Create_item_-_Task')?['ID']})/roleassignments/addroleassignment(principalid=@{variables('groupID')},roledefid=1073741826)

To get the id, an expression like below is used in the action which assigns a variable. It uses the output of a previous action.

@body('Send_an_HTTP_request_to_SharePoint')['d']['Id']

Who can maintain the team SharePoint groups

The financial manager is the formal process owner. This person is set as the owner of the team SharePoint groups so the financial manager could update these group membership.

Application management (IT)

Application management has full control to all SharePoint objects. They have a separate admin account for their admin duties. These accounts were put in the SharePoint owners group and every time custom permissions are set (tasks), this owner group gets full control. Full control permission is needed when having to change the task to someone else (due to leave, sickness, …).

Which employee has which role (Plant Manager, …, CFO) is configured in SharePoint lists (one on the master data site and one in the process site). Only application management is able to update these lists. The process owner is qualified to request changes to the roles.

Application Management is group owner of the SharePoint group “Investment requests Approvers” and the SharePoint owner group.

Other info

An investment request file in a team document library has to be locked while in process. Flow actions were used to break the inheritance and set custom permissions. When a process ends, permission inheritance is enabled again.

There is a special account called the workflow account. The blog post “Executing Flow actions with service account permissions” (Part 2/6) describes this in more depth. Using this workflow account is very much related to permissions.

One PowerApp app has been created. This app is shared with application management and the process owner.

Print 🖨