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

Nintex For Office 365

54 posts

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.


When designing a Nintex form, it's common that there is a part of the form that should only display to certain users. These sections are usually contained in their own panels within the form. It could be IT administrative details, financial information, or actions for HR to complete. In Nintex On Premises, it is easy to hide this panel based on the current user by using a rule and the inline function fn-IsMemberOfGroup. Unfortunately, that function is not available yet in Nintex Forms for Office 365.
This function is available in O365 Forms, it just does not appear in the Runtime Function list. If you manually type it in, it will work. Here is a list of all supported inline functions.


To accomplish this task, I created a hidden text field called "txt_HiddenIsUserAnAdmin" in the form and assigned it the JavaScript variable named jsvar_HiddenIsUserAnAdmin. I then created a rule on the panel that would hide it whenever txt_HiddenIsUserAnAdmin does not equal "Yes". To obtain the groups that the user belongs to without using the inline function, JavaScript must be used. Luckily, the hard work of that development has already been accomplished by Swetha Sankaran in Part 2 of her post on checking if a user belongs to a group. That took me a long way but I had to do a little more to get it to do what I needed.


var pollSP;
NWF.FormFiller.Events.RegisterAfterReady(function () {
    pollSP = setInterval(checkSPLoad, 500);

function checkSPLoad() {
    if (clientContext) {

function onSPLoad() {
    var spGroups = clientContext.get_web().get_currentUser().get_groups();
        Function.createDelegate(this, function () { OnSuccess(spGroups); }),
        Function.createDelegate(this, this.failed)

function OnSuccess(spGroups) {
    try {
        var groupsEnumerator = spGroups.getEnumerator();
        while (groupsEnumerator.moveNext()) {
            var userGroupNames;
            var currentGroup = groupsEnumerator.get_current();
            userGroupNames += currentGroup.get_title() + "\n";
            if (currentGroup.get_title() == "Team Site Owners") {
                NWF$("#" + jsval_HiddenIsUserAnAdmin).val("Yes");
                var triggerEventNow = NWF$("#" + jsval_HiddenIsUserAnAdmin);
    } catch (err) { alert(err); }

function OnFail() {
    alert("Failed to load groups")


You'll notice above that I set a hidden text field, jsval_HiddenIsUserAnAdmin, to "Yes". Then I trigger the event which causes the rule on the panel to execute allowing the panel to be seen. Without the trigger, the field will update but the rule will not execute leaving the panel hidden regardless of who is logged in.


Another thing to note is that this only works for SharePoint groups, not AD. Unfortunately, that is not supported using JavaScript but you could try querying AD group membership visibility as a workaround.



I’m trying to make task due dates dependent on the day the task notice is sent, so that if a completed task approval leads next to an additional task being created for someone else, and that 2nd person has 3 days to complete it, I’m expecting to find a way to make the Due Date = (Task Creation Date) + 3. Is there a way to program that?




In the Approval Branch for the initial task, add an “Add Time to Date” action and set it to 3 days with the date set at ‘Use date when action is executed.’ From there you can configure the task due date in the next Task to use the workflow variable you created in the previous action.


Good Day To all,

I have been testing the water with nintex 365 and one of the things that I was interested in solve is the workflow history log for audit purposes. And then I have one more solution that could be helpfull. 



1. I will create the example by using a simple list called (approval) with the following columns: Title(Single line of text), Approver (Person or Group) Status (Waiting for Approval, Approved, Rejected) this is type "Choice" and InstanceID (Single line of text)


2. The workflow is pretty straight forward (I will be uploading the workflow here )


3. Once I have the list and the workflow working accordingly the next step is add some jquery script to pop up the workflow history log related to a specific item..





The script should be added by using the web part Content Editor:


Find  the script and workflow attached: (remember change the URL related to your history log)






How do you keep lazy approvals functional as we migrate to Microsoft Exchange on Office 365 while maintaining our On-premises servers.   


We plan to manage a hybrid environment and our goal is to configure Microsoft Exchange for Office 365 with our SharePoint On-Prem servers.  If we were to move to Microsoft Exchange in Office 365 today, and decommission our Exchange servers, lazy approvals would fail to work.   


We would like to maintain continuity between Microsoft Exchange on Office 365 and SharePoint On-Premises.  How can we achieve this? And what are the steps we need to take to accomplish this? This is a high priority issue and your assistance on this will be greatly appreciated.




You will need to ensure that incoming email is functional for their SharePoint farm.  In order to do so, you will need to configure a connector within O365 to route the messages appropriately to their on-premises environment.


The articles below should provide some more information on this.


Integrating SharePoint On Premises With BPOS and Exchange Online: Part 2 – Inbound

Configure mail flow using connectors in Office 365

This is open for everyone, and anyone to answer.


  1. I want to search for a specific item, and that should bring all possible matching items as dropdown list that a user can select.


  1. Based on item, the item name, customer name, customer number all should automatically be displayed.


Answer for Questions 1 & 2

For question one / two, you will need to use jQuery to modify the control to incorporate the type-ahead functionality. From there you can use the calculated value controls, using the list lookup runtime function to populate the rest of the data. The links below will provide some context around potential ways to incorporate this functionality.



  1. The same needs to work for the requestor's name. Based on requestor's search selection, it should show their title, phone etc.


Answer to Question 3

The userprofile runtime function can be used (currently only available in on-prem) to populate the data using calculated value controls in a similar method described above with lookups.  If they are on O365, this functionality is on the roadmap, but has not been built at this stage.  


  1. I would like also like to enhance our Leave Request form. Our IT Department calendar, we update frequently, so we can  keep the department up to date on whose working remotely, travelling, on PTO, sick, working shift, attending conferences etc.


Answer to Question 4

How to Create a Leave Request Workflow in 365

Task Escalation Comes to Office 365

Remember those days when you have an automated business process and it sits there waiting for someone to do something or approve a task and they just won't?  Those days are over.  Task Escalation has made it to Nintex Workflow for Office 365.

How to configure, escalate, and auto-complete options in 365


Adding Vacation or Sick Time Hours

Answering it depends on how you are capturing their hours.  If they are creating a new item for each type of time such as vacation time, sick time etc. then you would need to query the list, grab all the items and calculate those.


If they are creating one item and then inputting multiple hours such as one would with a time sheet, then a calculated column or two should handle this. 


The goal is to know the structure of the data.  If linear, meaning contained in one item, you can use a calculated column or workflow running on that item to do the trick. If non-linear, meaning the data is contained in multiple calendar items and different columns, then a list/site workflow would need to run to do this.


Booking a computer in a training room

The training will happen at one of our training centres at 2 of the training rooms. They are Training room 3 and 4 and there are 16 computers per training room.  There are also 2 sessions for each day with the possibility of adding a third session.   They want HR to be able to book the people for these sessions per computer but they should also not be able to delete each other's bookings.   They want to see this in a calendar view and he wanted the solution later the afternoon...(+- 3 hours later)


All of the below are great resources for more information on building Nintex workflows and forms.:

If you have occasion to hide the Save button along the top of a Nintex Form in Office 365, below you will find some simple CSS that you can copy and paste into your Form Settings -> Custom CSS section to do so.






The below CSS will remove the button labels and the Save icon:

display: none;



Retrieve User Profile Details on Nintex Form for Office 365

Unlike the Nintex on-premise version , the User Profile Lookup function isn’t available yet in the Office 365 Nintex forms [Hopefully Nintex will add it in the future versions]. So here is a solution on how you can fetch the user profile properties using a custom JavaScript code.


Please refer my blog-post Retrieve User Profile Details on Nintex Form for Office 365 [Step – By – Step] 

to view the step-by-step process.



Common Code (Add this code inside the Site Assets folder and name it “sp.userprofile.js“)


function SPUserProfile(strAccountName, OnComplete, OnError) {
var currentObject = this;
var userprofile = null;

this.getProperty = function (propertyName) {
if (this.userprofile == null) {
propertyValue = “Userprofile not initialized or error fetching user profile”;
} else {
var propertyValue = NWF$.grep(this.userprofile.d.UserProfileProperties.results, function (k) {
return k.Key == propertyName;
if ((propertyValue == null) || (propertyValue.length == 0)) {
propertyValue = null;
return propertyValue;

this.getDisplayName = function () {
return this.userprofile.d.DisplayName;

this.getDepartment = function () {
var propVal = this.getProperty(“Department”);
if (propVal == null) {
return ”;
} else {
return propVal[0].Value;

this.getMobilePhone = function () {
var propVal = this.getProperty(“MobilePhone”);
if (propVal == null) {
return ”;
} else {
return propVal[0].Value;

this.getTitle = function () {
return this.userprofile.d.Title;

this.getEmail = function () {
return this.userprofile.d.Email;

function execCrossDomainRequest() {

if ((SP == null) || (SP.RequestExecutor == null)) {
setTimeout(execCrossDomainRequest, 500);
} else {
var url = appweburl + “/_api/SP.UserProfiles.PeopleManager/GetPropertiesFor(@v)?@v='” + encodeURIComponent(strAccountName) + “‘”;
var requestHeaders = {
“Accept”: “application/json;odata=verbose”
var executor = new SP.RequestExecutor(appweburl);
url: url,
contentType: “application/json;odata=verbose”,
method: “GET”,
headers: requestHeaders,
success: function (data) {
currentObject.userprofile = JSON.parse(data.body);
fail: function (error) {
userprofile = null;
var appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”));
NWF.FormFiller.Events.RegisterAfterReady(function () {


  • Inside the custom JavaScript paste the below code


var hosturl = decodeURIComponent(getQueryStringParameter(“SPHostUrl”));
NWF$.getScript(hosturl + “/SiteAssets/sp.userprofile.js”).then(function () {
NWF$(document).ready(function () {
NWF$(‘#’ + EmployeeName).change(function () {

function OnEmployeeChange() {
var selectedEmployee = NWF$(‘#’ + EmployeeName).val();
selectedEmployee = selectedEmployee.split(‘;’);
if (selectedEmployee[0] == “”) {
NWF$(“#” + JobTitle).val(”);
NWF$(“#” + Department).val(”);
var userProfile = new SPUserProfile(selectedEmployee[0],
function (data) {
NWF$(“#” + JobTitle).val(data.getTitle());
NWF$(“#” + Department).val(data.getDepartment());

function (error) {
NWF$(“#” + JobTitle).val(”);
NWF$(“#” + Department).val(”);
alert(‘An error occurred while fetching userprofile data’);


Thanks !!

In Nintex 2010, 2013 and 2016 for SharePoint (Standard version even) on-premise of course, there was a possibility to use excel services to query and work with the xlsx and xls files' data. However, insharepoint online there is no such powerful mechanism. Moreover Nintex products for SharePoint Online (neither nwc nor nintex for office 365) don't have any "ootb" actions that would fill that gap. So in the end, there is no straightforward way to achieve it.


The most common workaround is to convert the XLSX file into a plain, csv file and then to work with the data from the file using collections (I will write about it in second post).


Recently I have realized, that there is a set of excel actions in microsoft flow! All of us, who has SharePoint Online, has also a free version of Flow available. 

Just be aware, that in the free version Flow does not triggers itself once an event occurs. It just repeatedly checks whether an action occurs and in case it's "check" does not happen in the moment, when an event occurs, it might never get triggered. 

For the paid version there is no such risk as it works somehow like the Remote Event Receiver.

Anyway, I decided to give it a try.


Flow's boundaries in Excel actions

First things first. I want to let you know what are the boundaries of this solution. Flow is not that flexible in this scope as I thought:

  1. To anyhow work with the Excel files' data, the data must be put in a table. So once you have a data set in the file, you must convert it into table and name it (Rename an Excel table - Office SupportExcel Tutorial: How to Name Excel Tables For Beginners Excel 2016 Tutorial Excel 2013 Tutorial - YouTube):
    1. Select your data set;
    2. From "Tools" choose "Format as a table";
    3. Then go to "Design" tab;
    4. Set your table's name in the left top corner.

  2. If you decide to put a variable in the "File name" configuration field of the action, Flow will not allow you automatically to get table's name and to use its columns later, as variables. The same thing happens if you decide to set "Table name" using a variable, not as a direct string:

  3. If you choose, that data from the Excel will be uploaded to SharePoint List, there you again cannot use variables, to set list dynamically, because in that case you will not be able to bind list columns with Excel table columns:

However, you should still be able to dynamically choose your list using "HTTP Request" action, to get list of its columns, and then another, to insert data.

Step-by-step solution

After you accept all the above boundaries and go into rather "fixed" Flow workflow (still, you can create a Flow per each list/ Excel file, etc...), the working solution is built of the following components:


  1. SharePoint Import Library - this is where the Nintex workflow operates. In my case it takes the uploaded file, then uploads it into onedrive for business specific folder under a specific name (the one set as a source for the Flow). After it uploads the file, it then calls the Flow workflow using the "Web Request" action:

    1. "Authorizing user" - parameter visible in the "One Drive upload file" - it expects a valid email address to which an email with the authorization request will be sent. The email looks like this:

      Once user clicks "Provide OneDrive account credentials and authorize access" and then will let the app to access account info (in the next screen)
      the workflow will move on.

      According to the documentation (source: OneDrive upload file) the workflow will wait up to 7 days for the user's decision.

    2. "Body" - the parameter in the "Web Request" action needs to be a valid json string (Flow is expecting a JSON request body). As there is a known bug, that prevents you from straightforward JSON declaration (the opening and ending brackets are somehow omitted), you need to do it the workaround way: Declare a variable, where opening and ending bracket are some specific tokens --> Regex, replace these tokens with { and } accordingly.
  2. SharePoint List - the one, where the data from the Excel is going to be imported. I added 3 columns - text and date.
  3. OneDrive for Business - there must be a specific folder, that will be used to save a file and then be queried by the Flow.
  4. Microsoft Flow workflow - the one that takes the Excel file, pulls out the data, and then for each row does the insert into the list from point no. 2:


Working example

  • I have created a simple Excel file:


  • I have uploaded it into the "Import Library"

If you don't plan to make an extra approval or other extra logic before the file gets queried and data gets inserted into list, you can simply just upload the file to OneDrive straight away, and then change the Flow to gets triggered once a new file is uploaded.

  • That action triggered my Nintex workflow. I then received an email with the request to authorize access to my OD4B. Once I did that, I noticed the file gets uploaded:
  • Then I opened status page of the Flow, and was observing how the rows are getting queried and then uploaded to SharePoint:

Note, that for a simple file, having three columns and 10 rows, it took almost a minute to complete the query and import. For larger files this action can really run for hours 

  • And voilla! List is filled with data:

Next steps

It all depends on your specific requirements. In fact now you can trigger a workflow on the list where data got imported, so that each row will request an approval for example. 


In a second post I will show you how to import data from the Excel file, when the file is saved as CSV.


Thanks for reading!