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

Nintex For Office 365

60 posts

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.

 

Summary:

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.

Product:

All Office 365 Products

Symptom:

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

Cause:

An update has not automatically applied to your tenancy.

Answer/Solution:

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’


 

Trust

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
Principalgroupid
roledefinitionsid

 

to get these you can you below REST API 

Siturl/_api/web /sitegroups 

SiteURL/_api/web/roledefinitions

 

 

 

 

END,Good luck.

fhunth

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.

 

Realization

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

base64ToString(triggerBody()?['Signature'])

 

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

 

Solution?

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.

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.