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

Nintex For Office 365

55 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.

Question:

 

  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?

 

Answer

 

  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: http://vadimtabakman.com/nintex-workflow-parsing-nintex-forms-repeating-section-in-office-365.aspx
    2. O365 Create Item Action: https://help.nintex.com/en-US/o365/#o365/O365WorkFlow/WorkflowActions-INT/Office365CreateListItem.htm
  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.     
    1. http://vadimtabakman.com/nintex-workflow-for-office-365-data-from-another-list.aspx  

(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 (https://nintex.uservoice.com/forums/218291-3-nintex-workflow-for-office-365/suggestions/7012107-secure-password-variable).  

 

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.

Summary

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

        WebRequestToGetRequestDigest

      • 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
        BuildMetadataForGroup
    • 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
        BuildDictionaryGroupParameters
    • 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 

 

Advantages

• 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.

 

Disadvantages

• 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) {
        window.clearInterval(pollSP);
        onSPLoad();
    }
}

function onSPLoad() {
    var spGroups = clientContext.get_web().get_currentUser().get_groups();
    clientContext.load(spGroups);
    clientContext.executeQueryAsync(
        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);
                triggerEventNow.trigger("blur");
            }
        }
    } 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.

Question: 

 

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?

 

Answer:

 

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)

 

Thanks

Walter

With Nintex workflows, one of the challenges many developers have with Lazy Approval on Office 365 is capturing the comments provided by Approvers in the email back to the original submitter. A task email is sent to an Approver and that Approver has the option to only reply with the approval/rejection keywords. Any other comments in the email will be disregarded by the system. Also, there is no option to CC the original submitter in the initial task email which means the only way for an Approver to email comments back to the original submitter is by manually copying them in the approval/rejection email. This would not allow the comments to be captured along with the task. While comments cannot easily be captured if the Approver replies by email, they can be captured if the Approver customizes the Nintex task form. Simply put, the comments are captured in a workflow variable and added to the body of the email.

 

To accomplish this, start by creating your form and workflow. For this example, I am using the simple workflow below:

The first step is to create the text variable that will capture the comments from the custom Nintex task form. Click "Variables" from the workflow ribbon and then click "New" to create the text variable. I'm calling mine "TaskComments".

After that has been completed, go into your "Assign a task" action and click on the "Edit Task Form" button in the ribbon.

You will be presented with the standard Nintex form that you can customize. Next, create a panel at the bottom of the form and assign a rule to hide the panel at all times. The rule should have these settings:

Add a "Calculated Value" field to the panel. This field will assign the comment to the "TaskComments" variable we created earlier. Add the Named Control called "Comment" to the Formula and set the Connected to field to the variable "TaskComments". The settings should look like this:

Save everything. Your form should now look something like this:

Now all that is left is to add the variable to our email. Go into your "Send an Email" action on the "Rejected" branch and add the "TaskComments" variable to the body of the email. Of course, you can customize it further to include any of the other fields to make it more helpful to the user. It should look something like this:

Do the same with the Approved email and you're done. Publish the workflow and you're good to go!

This technique can be used to include other customizations that are more targeted to your organization. Hopefully this can help you address the needs for greater feedback collection in your approval workflows.

Question:

 

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.

 

Answer: 

 

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.

 

https://community.nintex.com/thread/11807

https://community.nintex.com/thread/2546

 

 

  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.:

 

http://help.nintex.com

http://community.nintex.com

https://learning.nintex.com

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.

 

Before:

 

 

 

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

#RibbonSaveButton
{
display: none;
}

 

After:

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);
executor.executeAsync({
url: url,
contentType: “application/json;odata=verbose”,
method: “GET”,
headers: requestHeaders,
success: function (data) {
currentObject.userprofile = JSON.parse(data.body);
OnComplete(currentObject);
},
fail: function (error) {
userprofile = null;
OnError(error);
},
});
}
}
var appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”));
NWF.FormFiller.Events.RegisterAfterReady(function () {
execCrossDomainRequest();
});
}

—————————————————————————————————————————————–

  • 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 () {
OnEmployeeChange();
});
OnEmployeeChange();
});
});

function OnEmployeeChange() {
var selectedEmployee = NWF$(‘#’ + EmployeeName).val();
selectedEmployee = selectedEmployee.split(‘;’);
if (selectedEmployee[0] == “”) {
NWF$(“#” + JobTitle).val(”);
NWF$(“#” + Department).val(”);
return;
}
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 !!