Skip navigation
All Places > Getting Started > Nintex For Office 365 > Blog
1 2 3 Previous Next

Nintex For Office 365

65 posts

Customer Question 1:

Values – we’re being told by the person building our forms that the only options for number values are US currency or general formatting with commas.  We’re looking to include multiple years in some of our forms (i.e. 2017-2018); however, this is coming up with commas and looks strange when approving.  Would there be an opportunity to load other number formats that can be used?  If we pick the currency option, this always has the $ sign which is not correct for us since we have international operations.


  • Answer: Currency controls if tied to a list will reference the locale of the Site that it is running on, or the settings configured for the list. IE, if the currency is setup Euros on the list, it will be reflected in the form.  If you’re looking to include references that are formatted like the example above (2017-2018) using the string format will be the best route, as it will not try to apply any additional formatting. For the last question, there are additional number formats that are available outside of string or currency including Integer or decimal. All of these formats can be applied to a Single Line of Text control on a form.
  • Customer Question 2:
  • Form attachments – we’ve been told that attachments are always sent in a separate email from the email notification for approval.  A few of our approvers have commented that this becomes confusing when receiving multiple approvals in the same day and having to match the correct attachments to each pending approval form.  Is there a way to attach forms to the email approval or is this an option that can be looked into further for the future?
  • Answer: The only way to currently (11/26/18) send attachments in an email in O365 will be to use the ‘Send an Email’ action. Based on the description above, it sounds like there are two emails going in parallel: 1) the Task notification email (configured in the ‘Assign a Task’ action and 2) an email with attachments (using the ‘Send an Email’ action.


In the current setup, if there is confusion with this configuration, there are some other options.  You can remove the ‘Send an Email’ action and just send the Task Notification. With this configuration, I would recommend using the link to the original list item where those attachments exist. 


For the future state, we do have the functionality currently within Nintex Workflow cloud where an Attachment can be added on a task email. This will likely eventually be brought over to the O365 platform, but there is no timeline on the availability of this functionality.


Interested in free Nintex training? Check out our latest version of the beginner-level Nintex for Office 365 course! This is perfect for newcomers to the Nintex Platform within the O365 environment!


This course will teach you all the basic forms and workflow features that you need to start designing workflows. You will see in-depth tutorials about basic actions and controls, and apply them in a practical real-world project.


Visit to enroll in this course today. Happy learning! 


Do you loving the new Learning Central content? Let us know! Message me on the community (@mackenzie_lyng), connect with me on Twitter, or email me directly! 

There was a blog post made and a major announcement that I haven't seen here in the community yet, so I wanted to post the link to the announcement and allow for any questions here in the community.… 


The Nintex product team has been hard at work building some great functionality that has been requested by users like you.

In this post, I’ll introduce our new ‘Administrator Management’ settings in Nintex for Office 365, how to find them, and some considerations to make before making any changes.

Administrator management is simply designating administrators for your Nintex solution. With Nintex administrator rights, you have access to features that will give you better governance around your Nintex Workflow for SharePoint  instance, so you can:

  1. Gain better control over the shared connections that are available in your workflow design.
  2.  Give key people in your organization the rights to publish Nintex workflows.

The Workflow History List is a particular type of list in SharePoint. In terms of structure and functionalities, it is a normal list in SharePoint, nothing special, but it has the following particularities:

  • It's used only by the workflow engine to log all the activities of the running workflow instances.
  • By default, the logs are only kept for 60 days to avoid problems with the number of items limit in the list and also for performance reasons
  • Every site has, out of the box, a Workflow History List.
  • It's a hidden list, so don't worry if you don't find it in under Site Contents. You can manually navigate to it via https://[YOURSITE]/lists/Workflow&20History
  • Cannot be created manually in O365, you will not find it as a template in your site.


If you've worked with SharePoint workflows or Nintex for a little while, you'll probably have seen or read in some article of this community that, as a best practice, we recommend use more than one Workflow History List in your site. Reasons being are performance and better visibility. The purpose of this post is not to explain these reason, but if you're interested I'd suggest having a look at some of these articles:


Demystifying Workflow History (Part 1)

Demystifying Workflow History (Part 2)

Defensive Workflow Design Part 1 - Workflow History Lists


With all of that in mind, the problem we've got now is that in Office 365 there's no way to create a Workflow History List manually, from the SharePoint user interface. The only options (that I know) to do it are:

  • From SharePoint Designer
  • Using Powershell



And here is another way of creating a new Workflow History List: from a Nintex Workflow.

The Workflow History list is, after all, a SharePoint list so there must be a template list that SharePoint uses. Actually, if you have a look at the List Template Types table provided by Microsoft, you'll see that the Workflow History is listed in there, using the Template ID = 140. And that's all we need.



Now, have a look at my previous post on Using the Office 365 REST API to create lists from you Nintex Workflow and use that workflow design to create your Workflow History list. The only thing you need to do is to modify the Request Body and change the BaseTemplate value to 140. Like this:




And that's it. Run the Workflow and you'll get a new Workflow History List right away. You can use this workflow on demand, on a site or a list workflow, or you can include this workflow as part of a bigger provisioning Workflow that is in compliance with your Governance strategy. Whatever the case is it would be easier than using SharePoint designer or Powershell. 

The Office 365 REST API provides a very useful way to interact with SharePoint data from any system able to create REST API requests. And one of those systems is our beloved Nintex Workflow for Office 365. In this post, we'll see how to use the Office 365 REST API to create SharePoint lists from a Nintex Workflow.

As in every REST API request, the first thing you need to do is to have a look at the reference documentation of that API, to understand the list of requests available and the values you need to provide for those requests. In our case, you can start with the SharePoint REST API documentation in this link.

Now, let's focus on the request we want to create. The following example, taken from the previous link, shows how to create a list:



With that, we know exactly all the information we need to get for our request. Creating a RESTful HTTP request in Nintex Workflow is easy if we know how to get that information, we just need to go through these 5 steps:

  1. Create the Workflow variables
  2. Build the Dictionary Variables
  3. Set the End Point URL
  4. Create the Web Service Call
  5. Parse the Response received

Those steps lead us to the following Workflow Design:

Let's go step by step and see it in more detail for our example:


1. Create the Workflow Variables

We will create Dictionary variables for the Headers and the Body of the request and response. We also need variables for the Endpoint URL of the API resource and the Status Code of the response we'll get from our request. The metadataObject variable is a Dictionary that we need for an object to be included in our Request Body (we'll see it later in this post).



2. Build the Dictionary Variables

  • Request Headers: 

     In our example we need to create headers for Accept and Content-Type to specify JSON as the format we'll be sending the request and the format we want to get the response. The rest of the Headers are not needed for a request coming from the workflow.



  • Request Body: 


    In this Dictionary variable, we just need to provide the key-value pairs that specify the title and description of our new list. What is very handy in here is that these values can be dynamic and we can, as in this example, pick up the values from an initial form. We can also specify the list template to use with the BaseTemplate parameter. In this linkyou can find the list of Template IDs. In my example, I'm going to go for a Document Template and provide the ID = 101



Notice that the first key-value pair, __metadata, is defined as an object in the API Reference Documentation. That's why we need, in a previous step, define another Dictionary variable, which I called metadataObject, and use it in the Request Body Dictionary. Here's how we define the __metadata object:



  • Response Body: 

    For the response body, we don't have to build the Dictionary. This variable will be where we'll be storing the JSON object of the response.


3. Set the End Point URL

My recommendation, when building up REST API requests in a workflow is to create a workflow variable for the URL of the end point we're making the request, especially if the URL will contain dynamic values for the base URL, path and query parameters. And that's the case of our example with the RequestEndPoint variable. So, drag and drop a Set WF variable action to the canvas and use the Workflow Context on the right-hand side to pick up the URL of the Current site. After that, add the rest of the URL manually, as in the picture below:


4. Create the Web Service Call

At this point of our design, we've got all the elements needed to create our RESTful HTTP request. So, drag and drop the Call HTTP Web Service action and use the variables we've set up for the different parameters of the action. Make sure you choose POST as the HTTP method of your request. Your action should look like this:



5. Parse the Response received

I'm not including it in this workflow design, but after our web service call, we could include more actions to parse the values received in our ReponseBody Dictionary variable. That would be useful to check if our call was successful or to retrieve values like the list URL created. But I'll leave it to you to complete it.


So, as you can see, using the Office 365 REST API is not that difficult if you understand well the information you need for your request. I really encourage you to explore it and see what you can do from your Nintex Workflows. Hope it's been useful!

This update is to comment on the document: Manually Update O365 Apps 

But since I couldn't add any comments to the document I wanted to blog the quick second step needed with modern site. You will not see update link like the following in modern site mode

But you will see it like this in modern sites

So in modern sites, you cannot update the app as easily. The best way is to use the link in the bottom left corner of the site page to "Switch to classic mode". Then you can easily click the Update link and follow the steps from the original document.



The O365 App will sometimes require the update to be manually applied for Forms or Workflow. You will notified of this requirement when accessing the designer.


All Office 365 Products


“Please update to the current version of Nintex Forms for Office365” // “Please update to the current version of Nintex Workflow for Office365”


An update has not automatically applied to your tenancy.


Navigate to the affected site.


Select Site Contents.

Select the App you wish to update, there will be a highlighted link “An update for this app is available”


You will be presented with the product page where you can select to update the app via the "Get It" button.


Get It


This will provide you with a permissions window to allow you to trust the App, select ‘Trust It’



This should ensure that the latest version is installed. You can perform the same steps for both the Forms and Workflow Apps.

Yes... it is takes me 10 more days time to resolve this issue.


What is this issue? 

i could not open the Nintex workflow designer in the site ,when i try to open Nintex to edit the Workflow,Page will get crashed.


is it related to Nintex ?

yes.this Problem Related to Nintex,


What is the solution for this issue?

Finally i have found the Issue,it is related to Nintex threshold limit .if you have more then 100 list/Library in the Particular site,you will get this kind of Error,


Note:- this 100 list/Library Issue(AW,Snap),won't create any problem in Nintex performance, it will occur issue only on open the Workflow designer



By default, all sites, lists, and libraries in a site collection inherit permissions settings from the site that is directly above them in the site hierarchy.
This means a site inherits permissions from the root site of the site collection, and a sub site inherits permissions from its parent site. Folders,
lists and documents inherit permissions from the site that contains them, and so on.
To assign unique permissions to a list, library, or survey, you have to first break permissions inheritance, then assign unique permissions.



1)Break Inheritance

2)Delete Existing Permissions(optional, based on your Project Recruitment you can decide this step)

3)Add New Permission 


1) Break Inheritance 





{Workflow Context:Current site URL}_api/web/lists/getByTitle('{Variable:ListName}')/breakroleinheritance(copyRoleAssignments=true, clearSubscopes=true)




2)Delete Exiting Permissions 


To delete Permission {Workflow Context:Current site URL}_api/web/lists/getbytitle('LISTNAME')/roleassignments({Variable:PrinscipleGroupID}) you can use this Rest api, To delete group you have to get the Principle Group id first 

To get Principle group id you can use following REST api

Siturl/_api/web /sitegroups 





{Workflow Context:Current site URL}_api/web/lists/getbytitle('LISTNAME')/roleassignments({Variable:PrinscipleGroupID})



3) Add Permission


There are two parameters values we need to ADD PERMISSION


to get these you can you below REST API 

Siturl/_api/web /sitegroups 






END,Good luck.


Form Variables coming soon.

Posted by fhunth Champion Mar 17, 2018

Based on a Euan Gamble Tweet.

As mentioned at Xchange, Form Variables are coming to Nintex Forms for Office 365 very soon!


Set column data with hidden calculations!


The post is motivated by the case Rhia Wieclawek wrote about on her Twitter. Her case is possibly more complex, but the general question was: how can I use the signature from the Nintex Mobile inside a document being generated by  the nintex document generation action? Unfortunately this is not yet feasible only using Nintex products. This is because Nintex Workflow for Office 365 is not handling correctly the binary data (it loses null bits) so what I proposed was to use  microsoft flow.


The process


  1. User sings a form in Nintex Mobile.
  2. The signature along with the form is saved in a SharePoint list.
  3. Then the Nintex workflow on item's creation is triggered.
  4. It builds a JSON, that is a request body, then calls Microsoft Flow, passing:
    1. form's title and
    2. base64 encoded signature from a multi-line text field.
  5. Flow receives the call, starts and uploads signature to the images library, converting it from base64 to binary.
  6. In resposne Flow sends the URL to the created file.
  7. Nintex receives the response and attempts to generate a document, having an image defined, that is the signature, having a variable set as a path (that is returned by Flow).
  8. Finally it generates a PDF with the signature inside.



Microsoft Flow

Its purpose is simple - get base64 encoded string and convert it into binary, then upload to a specified document's library. It is being invoked by a "Web Request" message, that should contain a valid JSON string, containing title of a form (it is using it to set file's name) and base64 encoded string.

  "Title": "Form's title or other text variable",
  "Signature": "The base64 encoded signature image"

After that it immediately calls SharePoint (using "Create File" action) and uploads the file, using the expression "Base64ToBinary":



After that it send back in "Response" action the uploaded file path:


Nintex Workflow

Is being triggered once a new item is created - user sends the signed form. Workflow purpose is to build a JSON that is a request body, and that is in a correct format - the one that Microsoft Flow workflow is expecting.


Then it calls the Flow, using the "Web Request" action:

And stores the "Response Content" in a text variable.


Then it builds an absolute path to the uploaded signature image, by joining workflow context's current site URL with the text received after Web Request call - the site relative path of the uploaded file.


Next it generates the document.using the Document Generation action.


The results

The working proof of concept:



You can find attached exported Nintex Workflow and Flow files.

Recently I was working on a project, where a workflow was running through a list of reviewers and was assigning them tasks, but because there it was possible to have multiple tasks assigned to multiple users at the same time, it just wasn't possible to simply use the "Wait for task completion" configuration option.


I decided not to use it and instead to use a "pause" action, so that after tasks are assigned workflow just loops and checks if all or any from the created are completed.


And everything seemed ok, from the architecture point of view, however I realized, that my workflow is actually not... pausing! I tried recreating the pause action, moving it to a different location in the workflow - nothing seemed to help.


Finally I started to analyze how the workflow works, trying to understand why it doesn't pause, as in other workflows this action works fine, so that it cannot be related to any Nintex or SharePoint issues. What I realized a little surprised me.


Workflow configuration

Workflow Manager (that is the platform which runs and handles the workflows in Office 365) has couple of configuration options that are used to keep executions under control (source). In Office 365 however we are not allowed to change them (source), as we can in on-premise SharePoint. These are: Throttle, Batch size, Timeout, Workflow Timer Interval, Workflow Timer Instances. In fact in this case the most important is the "Batch size".


Batch size

This is the number of SPWorkItems that the workflow Timer Job will attempt to complete in one run. The default value is 100. By "one run" means that the workflow will attempt to execute all actions that were put into that batch once started. The Batch should be executed in no longer than 5 minutes (the default value for the Timeout configuration), however actions can be added to several batches. 


To be sure, that actions in a single batch are completed, in Nintex on-premise versions we had the "Commit pending changes" action, that forces the workflow to wait for all actions from a batch to be completed, before moving on. However we have nothing similar in Office 365.


Why is workflow not pausing?

In my opinion, per my findings, the reason why the workflow is not pausing is caused by a fact, that it simply misses the time, when it should un-pause. Imagine you have very many actions, running in several loops. After all loops you want your workflow to pause before next runs. But it doesn't. This is because workflow is executing all actions from batches referring to a time when they started. You can see it in a workflow history - time passed between workflow start and current time shows ex. 6 minutes, meanwhile you still see, that your logs to history are all dated using the time when workflow started:


In my example - workflow started at 14:44 and all actions were "executed" at that time. But the "real" time was passing by. Unfortunately, the "pause" action is handled by a service, which checks the current time. And this is what I think - when action to pause occurs, it also occurs at a time when the batch was registered. In my case also at 14:44. It says the workflow to pause for 5 minutes. However when it occurs the real time was 14:52, so 3 minutes after it should un-pause. Seeing that, workflow timer job just ignores that action and moves on. And because it ignores it, it just keeps executing actions using the same time. And in my case - it pushes itself into an infinite loop (not really infinite, because once it reaches 5k items on workflow history list, it gets suspended ).



Remember, there is no "Commit pending changes" action in Nintex for Office 365. The only solution I found is just to insert short (1 or 2 minute long) pause actions inside the execution. In my case - after each loop I simply added a 2 minutes pause. This pause allowed my workflow to synchronize with current time. And thanks to that, once that really important pause action was executed, the workflow really stopped. Finally  

You can access to the workflow Service Health on this page >>> "/_layouts/15/WorkflowServiceHealth.aspx" , and you will see the current status including the workflow queue length.


Then you will see a table with the columns:

  • Workflow name
  • Started
  • Suspended
  • Canceled
  • Terminated
  • Completed
  • Total


, showing the number of those status




Also you can click on the information button 


and will see Details of this specific workflow, showing the Most recent update and also a link to Terminate all instances of the workflow.



  1. I would like to have a repeating section in my leave request form that contains 4 fields.  When I put the fields into the repeating section, the fields lose their link to the list columns in SharePoint.  Could you direct me to a video or send me some documentation on setting up repeating sections?  Also, is it possible to have each repeating section create a new entry into the SharePoint List?
  2. I’m going to be build 3 separate forms (leave request, compensatory leave earned, and overtime earned) that are attached to 3 separate lists in SharePoint.  Can one workflow be configured to process items from all 3 lists?




  1. For question 1, they can extract the information from the repeating section using a workflow then use that workflow to push the information in to a separate list.  I’ve included links below for the process to extract the data and a help files reference for the O365 create item action.
    1. Extract Data from Repeating Section:
    2. O365 Create Item Action:
  2. For question 2, there are a number of ways to do this.  You can build a site workflow and use a Set Variable action or the O365 Query List action.  The blog post below will provide some additional context.     

(Community manager's note: If you'd like to learn about the value of Workflow Constants, please see Tomasz's post in the Nintex Product BlogDid You Know: Workflow Constants )


There are a lot of challenges when migrating Nintex from on premise to Office 365, even using Sharegate to help you. The most important one in case of Workflow Constants is… there is no such feature available in Nintex Workflow for Office 365 at all. And that basically means migrating them requires many manual operations.


When attempting to do a migration with Sharegate, application will show you all the issues it finds in the process, also telling you, that you do have Workflow Constants used by your workflow that are not supported in migration. Workflow will be migrated, however won’t be published, as it contains references to variables not defined in target environment.


To overcome it, the best way is to create (depending on the scope of your variables) in a current Web or Site, a dedicated “WorkflowConstants” SharePoint custom list. Obviously the Farm scope is unavailable, but for that purpose you can create a list in the main site collection. The list in my case was built of the following columns (they don’t have to be Site Columns – it doesn’t matter for this case):

  1. Title (the default column in a custom list)
  2. StringVal (the regular Single line of text column)
  3. NumberVal (the regular Number column)
  4. DateVal (the regular Date column)


It should have the “Read” permissions set for all users.


How to map types?

Depending on the type of your Workflow Constant, copy paste its value in the column having the right type.


Regarding the “Credentials” type – unfortunately there is no counterpart functionality yet available in Nintex for Office 365, however work has recently started (  


Regarding the “Secure string” – this should be copied into a “StringVal” column.


How to map permissions?

If the Constant was available to ”Everyone” then no changes are required.

In case it was only available for specific users, then what you should do is to open that specific list item’s permissions, break its inheritance and then set these permissions to be equal to the source one.

Unfortunately this will not work as it did in on premise – user will be able to publish a workflow using variable, however it will be empty.

How to map sensitivity?

Again, the most straightforward way is to change the specific item’s permissions.

Remember, to use the “Action Set” action with the “Elevate permissions” checkbox checked to execute actions requiring access to those Constants.

How to use them in a workflow?

The most straightforward way is to first create a Workflow Variable for each Constant you need to use, then just assign a specific value using the list lookup and item’s title as the filter, ex:

Do it for each Constant you have to use.


Workflow gets suspended?

Due to the fact, that when referencing to the Constants (by the List lookup), during publication Nintex does not check whether the user who designs the workflow, has access permissions, all potential issues with the access arises when the workflow is executed and the lookup is resolved. If the constant is crucial for a specific action to work, the workflow can possibly get suspended, because of an error.

Unfortunately there is currently no better way to handle the Constants, so be sure to put crucial actions inside “Action Sets” (with elevated permissions) and to test your workflow with regular users, to be sure it gets executed without problems.


Moving into Office 365 from on-premise is getting more and more popular and is also advertised as the most recommended approach by the Microsoft (there are numerous benefits on the one hand and so many doubts and questions on the other). Having your stable Nintex processes already created in SharePoint on-premise demands a lot of preparation before moving them to Office 365. One of the key features, that is often used in SharePoint, but not available in SharePoint Online, are the Workflow Constants. I hope this post will help you in their migration.

For more information regarding preparing your Nintex to be ready for Office 365 please read my other post: Nintex Workflow Migration from on premise to Office 365.

Please, feel free to share your thoughts and approach for working with Workflow Constants after moving from on premise to Office 365.


Nintex Workflow has actions “Web Request” and “Call HTTP Web Service” which can be used to make calls to the REST API of SharePoint Online/2013 to automate creation of SharePoint groups in a site collection.

Add the following steps to the workflow

  1. Create a Text variable GroupName and Use “Set Workflow Variable” to assign it to a value.GroupNameVariable
  2. Get request digest from targeted site collection. Please note that workflow app permissions need to amended to give site collection full control access.        App Step to get request digest
    • Add “App Step” action
    • Add “Web Request” action. Fill in the following fields
      • URL: <siteURL> /_api/ContextInfo
      • Method : POST
      • Content type : application/x-www-form-urlencoded
      • Header Name (Key) : Accept     Header value: application/json;odata=verbose


      • Body : Choose “Content” option  and enter “{}” in text field
      • UserName: Credentials who has access to targeted site
      • Password: password of above UserName
      • Store response content in : Create a variable “digest token”WebRequestToGetRequestDigest_2
    • Add “Query XML” action. Fill in the following fields
      • XML source: Choose “Content” and pick variable “digest token”
      • XPath query: /d:GetContextWebInformation/d:FormDigestValue
      • Return result as :Text
      • Query result in : create a text variable strDigestInfoQueryXMLRequestDigest
    • Add “Log to History” action. Print the strDigestInfo to make sure valid request digest are used  QueryXMLRequestDigest
  3. Create SharePoint Group using REST API /_api/web/sitegroups  AppStepToCreateSpGroup
    • Add “App Step” action. Optionally add “Log to History List” action to log status of workflow.
    • Add “Build Dictionary” action to build “Request Headers”.
      •  Add the following key value pair as Text- content-type:  application/json; odata=verbose
        – X-RequestDigest : {Variable:strDigestInfo}
      • Save Output into RequestHeadersRequestHeaders
    • Add “Build Dictionary” action to build “Metadata”
      •  Add the following key/value pair- key: type    Type:Text  Value: SP.Group
    • Add “Build Dictionary” action to build “Parameters”
      •  Add the following key/value pair- Key: __metadata   Type:Dictionary   Value: Workflow Variable GroupMetadata
        – Key: Description  Type: Text  Value: Group created automatically from Nintex workflow
        – Key: Title  Type:Text  Value:{Variable:GroupName}
      • Assign Output to a dictionary variable GroupParameters
    • Add “HTTP Web Service”action to create group
      • Fill in Address : <SiteURL>/_api/web/sitegroups
      • Set Request Type to “HTTP Post”
      • Set Request Headers to dictionary variable RequestHeaders
      • Set Request Content to dictionary variable GroupParameters
      • Set Response Headers to new dictionary variable GroupResponseHeaders
      • Set Response Content to new dictionary variable GroupResponseContent
      • Set Response Status Code to new text variable GroupResponseStatusCodeWebRequestToCreateGroup
    • Log to History list the responseLogResponseOfGroupCreated
  4. Retrieve SharePoint Group using REST API  /_api/web/sitegroups/getbyname AppStepToGetGroupCreated
    • Add “Add Step” action
    • Optionally add “Log History List” action to log workflow status.
    • Add a “Web Request” actionWebRequestToGetGroupCreated
      • Set URL to <SiteURL>/_api/web/sitegroups/getbyname(‘{Variable:GroupName}’)?$select=Id
      • Choose  Get for Method
      • Click Add Header
      • Set Header Key to “Accept”
      • Set Header Value to “application/json;odata=verbose”
      • Set UserName to user who has access to site collection
      • Set Password to password of specified user
      • Set Store response content in a Text variable GroupRequestIDXMLAdd
    • Add “Log History List” action to log response GroupRequestIDXMLAdd from web request. The response is in JSON format. Nintex does not have a JSON parser action to retrieve value of property. Use “Regular Expression” action as described in the next step is used to retrieve Id value
    • Add “Regular Expression” actionRegularExpressionToGetID
      • Set String to {Variable:GroupRequestIDXML}
      • Set String Operation to Extract
      • Set pattern to (?<=”Id”:).*?(?=})
      • Save Output to text variable strGroupIDCol
    • Add “Get Item from Collection” action.GetGroupIDFromCollection
      • Set Target Collection to variable strGroupIDCol
      • Set Index to 0
      • Set Output to SPGroupId
    •  Add “Log History List” action to log strGroupIDCol
  5. Add Contribute Role to new Group
    • Add App Step action  AppStepToAddContributeRoleToGroup
    • Add “Call HTTP Web Service” Action WebRequestToAddContributeRole
      • Set URL to <siteURL>/_api/web/roleassignments/addroleassignment(principalid={Variable:SPGroupId},roleDefId=1073741827)
      • Set Request Type to “HTTP Post”
      • Set Request Headers to dictionary “RequestHeaders”
      • Set Response Headers to new dictionary variable RoleAssignResponseHeaders
      • Set Response Content to new dictionary variable RoleAssignmResponseContent
      • Set Response Status Code to new text variable RoleAssignmResponseStatusCode
    • Add “Log to History List” action to log response of web request

Save and Publish the workflow. If the workflow runs succesfully