SharePoint 2013 Workflow: Changing Permissions with REST Calls

Ben Prins Office 365

SharePoint 2013 workflows do not have a default action to change item or list permissions. With the help of the call http web service action I was able to create multiple REST calls that can interact with the permission. In this blog post describes multiple workflows for specific interactions involving permissions. The solutions where build on SharePoint Online (Office 365) using SharePoint 2013 workflows.

Breaking the inheritance on current item

This workflow will break the inheritance of the item the workflow is running on. It is possible to change the regURL to break the inheritance of different items. If needed set the actions within an App step to make sure the workflow has the required permissions, see the blog post SharePoint 2013 Workflow: App step and App Permissions.

  1. Create a SharePoint 2013 workflow
  2. Create a dictionary variable called JSONRequestHeader
  3. Create a string variable called regURL
  4. Add the action Build Directory, select JSONRequestHeader as the variable
  5. Add Accept and content-type to the directory with the following code: 
    application/json;odata=verbose

  6. Then store the following URL to the variable regURL

    [%Workflow Context:Current Site URL%]_api/lists/getbytitle('[%Worklfow Context:List Name%]')/items([%CurrentItem:ID%])/breakroleinheritance(true)

  7. Add the Call HTTP web service action to the workflow and set the “this” to the regURL
  8. Set RequestHeaders to Variable: JSONRequestHeader
  9. Set RequestType to HTTP Post
  10. The full workflow looks like this

Set permissions on current item

This workflow will set permissions on the item the workflow is running on. It is possible to change the regURL to set permission on different items. If needed set the actions within an App step to make sure the workflow has the required permissions, see the blog post SharePoint 2013 Workflow: App step and App Permissions.

  1. Create a SharePoint 2013 workflow
  2. Create a dictionary variable called JSONRequestHeader
  3. Create a string variable called regURL
  4. Add the action Build dictionary, select JSONRequestHeader as the variable
  5. Add Accept and content-type to the directory with the following code: 
    application/json;odata=verbose

  6. In this example we will grant the default members group contribute permissions.
  7. Add an step in the workflow called: Set Role Members
  8. Then store the following URL to the variable regURL 
    [%Workflow Context:Current Site URL%]_api/lists/getbytitle('[%Worklfow Context:List Name%]')/items([%CurrentItem:ID%])/roleassignments/addroleassignment(principalid='769',roleDefId=1073741826)
  9. The roleDefID sets the type off permissions
  10. The principalId is the ID of the permissions group, this is an unique id. You will need to find the principalId for your SharePoint Group, see the chapter Get SharePoint Groups principalId to learn how to find the principalId.
  11. Add the Call HTTP web service action to the workflow and set the “this” to the regURL
  12. Set RequestHeaders to Variable: JSONRequestHeader
  13. Set RequestType to HTTP Post
  14. The full workflow looks like this

Get SharePoint Groups principalId

  1. Open the SharePoint site where the SharePoint Groups are present
  2. Create the following URL 
    [Current Site URL]/_api/lists/getbytitle('[List Name]')/items([Item ID])/roleassignments/
  3. In the source of the page you can find the principalId’s
  4. The principalId’s are located between the following tag 
    <d:PrincipalId m:type="Edm.Int32">769</d:PrincipalId>

Remove all permissions on current item

This workflow will remove all permissions on the item the workflow is running on. It is possible to change the regURL to remove all permission on different items. If needed set the actions within an App step to make sure the workflow has the required permissions, see the blog post SharePoint 2013 Workflow: App step and App Permissions. With this workflow we will first break the inheritance, then get all permissions/roles on the item and then remove the roles. Only site collection administrator and farm admins will be able to access the item when the workflow has run.

  1. Create a SharePoint 2013 workflow
  2. Create a dictionary variable called JSONRequestHeader
  3. Create a dictionary variable called JSONDeleteHeader
  4. Create a dictionary variable called JSONResponse
  5. Create a dictionary called AllRoles
  6. Create a dictionary called RoleItem
  7. Create a string variable called regURL
  8. Create a integer called principalId
  9. Create a integer called Index
  10. Create a integer called countRoles
  11. Create a number called calc
  12. Add the action Build Dictionary, select JSONRequestHeader as the variable
  13. Add Accept and content-type to the directory with the following code: 
    application/json;odata=verbose

  14. Add the action Build Dictionary, select JSONDeleteHeader as the variable
  15. Add X-HTTP-Method to the directory with the following code: 
    DELETE

  16. The first step is to break the inheritance of the items, see above the chapter breaking the inheritance on current item for the steps.
  17. The second step is to get all SharePoint Groups (Roles) that have permissions on the item.
  18. Store the following URL to the variable regURL 
    [%Workflow Context:Current Site URL%]_api/lists/getbytitle('[%Worklfow Context:List Name%]')/items([%CurrentItem:ID%])/roleassignments
  19. Add the Call HTTP web service to the workflow and set the “this” to the regURL
  20. Set RequestHeaders to Variable: JSONRequestHeader
  21. Set RequestType to HTTP Post
  22. Set ResponseContent to JSONResults
  23. Add the action Get an Item from a Dictionary, select from Variable: JSONResults, with output to Variable:AllRoles and the following code 
    d/results

  24. Then add the action Count Items in a Dictionary, select from Variable:AllRoles with output Variable: countRoles
  25. The third step is to remove all the Roles
  26. Add a loop that runs repeatedly while: Variable:Index is less then Variable:countRoles
  27. Add the action Get an Item from a Dictionary, select from Variable: JSONResults, with output to Variable:roleItems and the following code 
    d/results([%Variable:Index%])
  28. Add the action Get an Item from a Dictionary, select from Variable: roleItem, with output to Variable:principalId and the following code 
    PrincipalId

  29. Then store the following URL to the variable regURL 
    [%Workflow Context:Current Site URL%]_api/lists/getbytitle('[%Worklfow Context:List Name%]')/items([%CurrentItem:ID%])/roleassignments([%Variable:principalId%])
  30. Add the Call HTTP web service to the workflow and set the “this” to the regURL
  31. Set RequestHeaders to Variable: JSONDeletedHeader
  32. Set RequestType to HTTP Post
  33. Add the action Do Calculation select Variable:Index plus 1 and store the outcome in Variable: Calc
  34. Then Set Variable:Index to Variable:Calc
  35. The full workflow looks like this

SharePoint 2013 Workflow: App step and App Permissions

Ben Prins Office 365

By default workflows run under the permissions of the user that starts the workflow, even is the workflow starts on a change or when a new item is created. The initiator does not always have the right permissions to complete all the actions within the workflow. For example when the workflow needs to delete an item, create a new items or use a web service. With SharePoint 2013 workflows it is possible to use the App step action to give the workflow its own permission set.

Solution part 1: Activate the feature

  1. The feature Workflows can use app permissions needs to be active.
  2. Open the site settings and click on Manage site features
  3. Activate the feature: Workflows can use app permissions

Solution part 2: Grant workflow app permissions

  1. Open the site settings and click on Site app permissions
  2. Copy the client section if the App Identifier. This is the identifier between the last “|” and the “@” sign, as shown in the figure.
  3. Navigate to the Grant permissions to an app page.This must be done by browsing to the appinv.aspx page of the site. 
    http://}hostname}/{the Site Collection}/_layouts/15/appinv.aspx
  4. Fill in the App Id and click on Lookup
  5. The fields Title, App Domain and Redirect URL will be filled in automatically.
  6. Paste the following XML into the Permission Request XLM textbox to the grant the workflow App step full control 
    <AppPermissionRequests>
    <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />
</AppPermissionRequests>
  7. Click on Create and on Trust It

Solution part 3: Using the App step

  1. Create a SharePoint 2013 Workflow with SharePoint Designer.
  2. Click on App Step in the ribbon to add the step.
  3. Add actions within the App Step and publish the workflow, for example:

SharePoint 2013 Workflow: Start a workflow using a REST call

Ben Prins Office 365

SharePoint 2013 workflows do not have a default action to start another 2013 workflow. There is an action to start 2010 workflows, but for my solution I required the more advanced actions only available with SharePoint 2013  workflows. With the help of the call http web service action I was able to create a REST call that started the workflow. The solution was build on SharePoint Online (Office 365) using a SharePoint 2013 workflow.

The REST call workflow consist of three major parts;

  1. The HTTP web service URL
  2. The SubscriptionID of the workflow that needs to be started
  3. The itemID of the item on which the workflows needs to be started.

A side note: The workflow that is being started needs to be configured to start manually. I could not find any reference on MSDN about this, but without this option I would get an error message.

Solution

  1. Create a SharePoint 2013 workflow
  2. Create a string variable called CurrentItemID
  3. Create a string variable called WorkflowGUID
  4. Create a string variable called regURL
    workflowvariables
  5. Now we need to find the SubscriptionID of the workflow we want to start. It is possible to use another REST call to find the SubscriptionID. But I prefer the following method.
  6. Navigate to the workflow settings of the list where the workflow is located
  7. Right-click on the workflow and open the properties
  8. Copy the URL and find the SubscriptionID within the URL
    getsubscriptionid
  9. Set the variable WorkflowGUID with the found SubscriptionID
  10. Set the variable CurrentID with the ItemID of the current item or item on which the workflow needs to start.
    setvariables
  11. Then store the following URL to the variable regURL 
    [%workflow Context: Current Site URL%]_api/SP.WorkflowServices.WorkflowInstanceService.Current/StartWorkflowOnListItemBySubscriptionId(subscriptionId='[%Variable: WorkflowGUID%]',itemID='[%Variable: CurrentItemID%]')
  12. Add the Call HTTP web service to the workflow and set the “this” to the regURL
  13. Set the HTTP Method to HTTP POST
    setcallhttpwebservice
  14. The workflow will now look like this
    fullwfstartanotherwf
  15. The app step is used to make sure the workflow has the required permissions. More details about the App Stepp will be explained in another blog post.

 

Office 365 New Group features

Ben Prins Office 365

Microsoft is working hard to update Office 365 by adding new features and improving the overall user experience. One of my favorite changes is that (in most cases) it is no longer required to save changes and updates. A great number of actions no longer require the user to press a save or conformation button. This will prevents a lot of information being lost and speeds up work noticeable. It may seem a small change, but it has a great impact.

Copy document between libraries
With the modern library located on the One Drive it is possible to copy documents to libraries located on Groups. I expect this will be added to all the modern libraries, for now it only works on One Drive and only the copy action. The move action can only be used within modern libraries, not across groups.

select-copy-location

Changing views
Changing existing views can be done fast and with great ease. Change the width of columns, sort order, filters, move columns and save the changes. Both the owner and member of the group are able to change the public views.

change-views

Full options in Groups
Group have been enhanced with the possibility to create new list, libraries and pages. This will create the possibility to create advanced team sites (groups) with full collaboration options.
create-lists

Pages within Groups
With a simple click a new site page can be created and with a user friendly interface the user can change the page. Image, documents, embedded content and even video’s are added through a easy to use menu. It is still possible to create wiki and web part pages through the new item action on the Site Pages library, the layout of these pages are not changed.

page-add-content

Guest users
It is now possible to add external users to the group. For some features the users experience will be different for guest users, but they are able to be a full member of the group.

externalusers

Office 365 Planner

Ben Prins Office 365

Microsoft introduced a new feature in Office 365 to preview, it is called Planner. The planner is closely connected to Office 365 Groups. The planner is used to create new plans, organize and assign tasks, share files, chat about what you’re working on, and get updates on progress. Planner can be used to manage a marketing event, brainstorm new product ideas, track a school project, prepare for a customer visit, or just organize your team more effectively.

Intro Planner

For every new plan a corresponding group will be created. The group is used to store documents, information and grand access. The start page shows all the progress off all your tasks from all plans and groups. This makes it easy to see what you need to do.

all-tasks

The start page provided the navigation links to all your plans and groups. New plans can be created from this location.

navigation

The interface is very modern and simply. Drag and drop task to change the task status or assign users. All changed are saved automatically with pressing a save or confirmation button.

assign-tasks

Every plan contains two pages, a board page and a charts page. The board page is the workings-man’s page. Here you created new tasks, complete tasks and create new buckets.
board-page

The charts page is to follow the overall progress of the plan.

chart-page

SharePoint Timer Job: Workflow Auto Cleanup Job

Ben Prins Office 365

One of our customers uses workflows to review and approve important project documents. The project board members receive workflow tasks to approval for example the mandate and the project initiation documentation (PID). The customer uses a view to see if the approval workflow is running, complete or not used. After weeks of using the workflow the customer stated that all the workflow information of completed workflows is missing. This is a problem because the customer needs to be able to provide an audit trail of the approval process for important project document.

Cause
The cause of the seaming missing workflow information is the SharePoint timer job Workflow Auto Cleanup Job. The job is responsible for deleting related workflow tasks and the workflows status used in views. The job removes tasks that still exist 60 days after the workflow is completed or cancelled. This is done to prevent the task list to become too large and impact performance. The actual workflow information will not be removed and can still be accessed through the workflow history.

Solution
Because the required audit trail information is not lost we did not change anything to the timer job, to make sure no potential performance issues where introduced.
We introduced the following solution to overcome the default cleanup behavior.

  1. We added a step in the workflow that filled in an extra column, the column contains the information if the workflow has run or not.
  2. The column was removed from the edit page to make sure only the workflow changed the value of the column.
  3. We taught the customer how to use the workflow history, to gain easy access to the audit trail.

Disable the timer job (not recommended)
It is possible to disable the timer job. However, this is not recommended. Disabling the timer job creates a potential impact to performance.