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

Nintex For Office 365

62 posts

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

Hi Nintexers,


I just wanted to share a simple workaround for the missing support of the "Append Changes to Existing Text" option for Multiline text fields in Nintex Forms for Office 365.


Apparently on 26th September Nintex announced that this feature is planned for development, but I can't wait that long...  Support lists with versioning turned on and where "Append Changes to Existing Text" is set to "Yes." – Customer Feedback… 


For my solution I was using the new responsive forms but it should work also in the classic ones.


What you need

  • Repeating section
  • Multiline text field: Comment/Notes
  • People field: Created by
  • One Rule How to


How to

  1. Move Note and Created by field into the Repeating Section which is connected to a SharePoint Multiline text column
  2. Set the default value of the Created by field to "Current User (Display Name)"
  3. Disable the People field
  4. Create a rule for the Multiline text field: When not(Note_Created_By==Current User (Login ID)) Then Disable 



• Every comment field can be only edited by the user that made the comment otherwise it will be disabled.

• Unlike in SharePoint you can see old comments while editing.



• People can be destructive and delete each others comments.

• You don't get a time stamp like in SharePoint.


This Quarter's Nintex Workflow Hero is IMS Electronics Recycling.  Later today at this month's Workflow Hero's live webinar, we will showcase their Nintex for O365 success story hosted by yours truly.  See how they were able to adapt to change and growing compliance requirements saving their organization over 5k+ sheets of paper AND 1,256 hours PER YEAR!


Be sure to check out their case study right here | IMS Electronics Recycling Nintex Workflow Hero Story


Not able to make today's Webinar?  No worries!  You will be able to access the full Nintex Workflow Hero series.  Just visit the Nintex Workflow Hero's landing page for all webinar's past and present and while you are there, register for upcoming live webinars for Nintex Workflow Cloud and Nintex App Studio.  Probably the only binge watching you will do all week that could turn you into a hero!


How to become your organizations workflow hero?  | Nintex Workflow Hero's Live Webinar Series


I recently had a requirement come up while implementing an On-Boarding Workflow. The requirement from my client was:


"we want to have multiple list item attachments for the new employee process but when the workflow starts I need to have different attachments emailed to different employees".


I started to think about this because there is not an action within Office 365 to get list item attachments, although there is a web service we can call to get them. I wanted to document the steps I needed to take just in case others needed to do something similar.


Step 1) Build Dictionary to set the Request Headers.
Drag and drop Build Dictionary action on to the canvas and Add the following Items: Below is what the action will look like when you are done.

  1. Key: Content-type
    • Type: Text
    • Value: application/json;odata=verbose
  2. Key: Accept
    • Type Text
    • Value: application/json;odata=verbose
  3. Output: RequestHeader of type Dictionary

Step 2) Build URL String
Use the Build String Action to build out your Web Service Call URL and Output to a String Variable (I used varWebServiceURL) . Everything in RED makes this URL Dynamic to pass in the right information.


REST Web Service URL to only return information around the list item Attachments

{Workflow Context:Current site URL}/_api/web/lists/getbytitle('{Workflow Context:List Name}')/items({Current Item:ID})/attachmentFiles


Break Down:

  1. I use the Get Current Site URL to make my workflow Dynamic instead of hard coding the URL to the Site
  2. /_api/web/lists/getbytitle('LIST NAME')
    • get to the list you want to get attachments from
  3. /items(CURRENT ITEM:ID) 
    • we want to make sure we are working with the right list item so we need to tell the web service what ID we want to use
  4. attachmentFiles
    • This is acting more or less like a filter because I only want properties around the attachments returned from my web service call

In the end this is what your action should look like:

Step 3) Use the Call HTTP Web Service Action

  • Address: varWebServiceURL
  • Request Type: HTTP GET
  • Request Header: Use your Request Header Variable in my case it was called (RequestHeader) type Dictionary
  • Request Content: Leave Blank
  • Response Content: Create a new Variable called ResponseContent of type Dictionary
  • Response Header: Create a new Variable called ResponseHeaders of type Dictionary
  • Response Status Code: Create a new Variable called ResponseCode of type Text


Configured Action

Step 4) Next we need to get the Response Content returned from the web service.


We will use the Get an Item From a Dictionary Action to get our Response from the web service. Drag and Drop that action and double click to configure.


Dictionary: ResponseContent (var used from the action above)


Item Name or Path: Because this is getting returned as a JSON object we need to make sure we get to the right part and we want the results path so we need to enter: d/results


Output: I created a new variable called tempDictionary to store my results


Configured Action

Step 5) We need to get a count of the items so we know how many times we need to loop though the results to get the data we need. Use the Count Items in a Dictionary Action and double click to configure.

  • Dictionary Variable: tempDictionary
  • Output: New Variable ResonseCount of type Integer

Configured Action


Step 6) We also need to create a new Variable called LoopCounter of Type Integer and use the Set Variable Action to set it to 0


Step 7) Now we need to loop through our returned contents. Use the Loop n Times Action and configure it with the ResponseCount variable you set a couple steps ago so the action knows how many time to loop.


Configured Action

Step 8) Now that we are looping we can start to get the individual attachments from the response. We will use the Get an Item from Dictionary Action and configure it as follows.

  • Dictionary: ResponseContent
  • Item Name or Path: d/results({Variable:LoopCounter})/FileName (we use the loop counter as our index to get the file name so then I can build the URL later).
  • Output: varTitle (this is a new string variable to store the attachment title we will use later)

Configured Action

Step 9) You will repeat this step as many times as you need to and You might handle this next step differently depending on your desired outcome, but with our new employees they will always have the same documents uploaded. So I created a string variable for each one. For example: varResumeURL, varEmpAgreementURL, so on and so forth. I did this because as of this post you cannot attach list items to an email.

(Disclaimer: I tried to use the External Email and attachment, but the attachment failed.)

Within my workflow I have an few Run IF Actions and I configure them to look to see if the contents of the varTitle Contains (ignoring case) key words in my file names, for example: Resume, Agreement, etc.
Here is an example configuration of one of my RUN IF Actions


If I get a match for what I am looking for I use the Set Workflow Variable Action and build out my URL to the Attachment. Each List item has a unique URL you can use to get to your attachments. I set my varResumeURL to the following URL within the action. The key here in this url is going to the ListName/Attachements/ID/FileName


{Workflow Context:Current site URL}/Lists/NewUserRequest/Attachments/{Current Item:ID}/{Variable:varTitle}

The next step is to build out my Send Email Action. I drag/Drop the Send Email Action on and then in the body of the email I create a section called Attachments and then use the Hyperlink Builder to create a link to the document, so I am not really attaching the document which saves on email bloat, I am just linking to it.
Click Insert Link and Configure as follows:


That's it. This would be a really good utility workflow as well, because you could pass in the List Name as well.

Here is what the full workflow looks like. If you have questions, post them as I am sure more than 1 person has the same question.