There is a lot more work involved with developing a solution in NAC compared to Nintex Workflow for Office 365 (NW365) as it relates to task management.

Office 365 was or is integrated with the task list that exists on the SharePoint site you are building a solution for - not in the NW365 application. Because of this, everything is synced and updates when the user interacts with the task form you built to some level. If you even put associated fields from a primary list on the task form - the user is updating the data back in the primary list - they are synced together. It’s very convenient. 

In NAC you have to think about what a task form is and offers in NAC. You are simply given someone a task to action and possibly displaying information from an object from your workflow for that person to decide how to action the task.

With that in mind, the question is how do you make the information dynamic enough to go back and forth from an approver, the initiator to make updates to then back to the approver for re-review essentially - at least that is what it sounds like you are attempting to do, correct??

I can share how to do this, but I would need to know more about your process. I would think Nintex would need more level of details to assist you with this one. If you could export and share the workflow key, we could see what you are trying to do and be able to better assist.

Clarifications:

• Are you using a SharePoint start event trigger or a NAC start event form to start your workflow?
• You only want the initiator to make changes to the data, correct - not the approver?
• What information is being shown on the task approver form? SharePoint data or data from a start event form?
• If changes are made, another task is going back to the initiator? 
• What are you trying to update when changes are made?
  • If a start event form - you can’t. It’s historical.
  • If an associated in SharePoint list - you can, you just do an “Update items” action after the task is completed and pass whatever was on the “change” task back to the associated record in SharePoint. 

How in the world do you update the fields in the task form to match what's been updated in the live form?

You would add general controls and set each control with a default value - pass values from the start event variables object to each control. From there, they are editable to the user, and the default values are set with the originally data submitted by the user on the start event form.

Yes, this is more time consuming. But I do not know of a quicker approach. You will have to mirror required fields, optional fields and rules etc. Your better off just making a copy of the start event form using export feature and importing into your task, then customizing it for your task. 

@brandiwoodson,

Thanks for your quick response!

So after reading your post I see that you mention that if I am using a “start event form” that I CANNOT update the task form fields as they are historical… Are they looking to have something in the future that may?

You can update task forms in general when actioning them but once they are submitted you can't...they are historical records and live in task details section of My Nintex.

However I was referring to updating of a start event form. Those are two separate things... not the same thing. You can't edit or change start event form data either...they become historical data under the form submissions swcrion in my nintex page or interface foe users.

@brandiwoodson,

Thanks for your quick response!

So after reading your post I see that you mention that if I am using a “start event form” that I CANNOT update the task form fields as they are historical… Are they looking to have something in the future that may?

 

 

You are using a sharepoint start event trigger based on your snapshot. So start event forms dont apply to you so its a moot point. 

When you say live form are you referring to the nintex form for office 365 that sits on top of the sharepoint list? 

@brandiwoodson ,

Thanks so much for all the info! I think I understand this… You can update the fields yes, on the first go round but for ex., if a form is submitted and a approval task is sent out w/ all the fields mirroring the form fields, but “if changes are requested” then the approval would eventually loop back around and that’s when the task form fields would not be able to reflect the changes made. Right? This is the first approval task form my workflow..

@brandiwoodson,

Please pardon my noob terminology as I’m still learning this but yes.

“When you say live form are you referring to the nintex form for office 365 that sits on top of the sharepoint list?”

The nintex form that displays when the new button is clicked.

Don't apologize at all. I was in your hoes years ago…you have to start somewhere. I don’t mind explaining some basics when it’s needed. :)

SharePoint Online:

The form that is integrated with a SharePoint Online list syncs with editing a list item and the new item option within the list is another product all together offered by Nintex. That is the Nintex Forms for Office 365 application that you add to a sharepoint site collection to use across any of the site lists or libraries - it replaces the OOB SharePoint form that pops up (or edit properties in a library) with a Nintex form you publish to a select list or library. Some people refer to this form as the Nintex list form or SharePoint Nintex form, 365 form, or Nintex 365 form if that helps.

Form designer for these are accessed through the list or library menu ribbon. 

Nintex Automation Cloud

The available forms in NAC are referred to as start event forms or task forms. Those are the only forms available in this platform/application.

Start event forms are accessed through start event on any workflow. Once you configure a workflow this way, it shows up in workflow listing as “form” and you have a form URL available for copying in the menu of that workflow.

Task Forms are accessed through workflow designer as you know already based on your screenshots. 

Hope that helps you so you can better articulate which forms you are referring to for what when you need help the next time. :)

Clarification:

Did you want the user editing the data in the sharepoint list through the 365 form for changes or did you want them to just complete a NAC task form (same as approver) to make the changes instead? 

Note: This matters before I provide you with detailed workflow steps. We build solutions like this all the time - my recommendation is to always stay away from editing list items in a SPO list when possible. We can’t always avoid this, but when we can - we do. If we can’t - we rely on the update item permissions to control item level permissions or use data sources in form designer to avoid things getting edited and data being static that is being approved/rejected or looked at etc.

@brandiwoodson,

Thanks again so much for your quick response!

So here is layout…

1.) User fills out a Nintex O365 form located in the sharepoint list.

2.) Workflow fires off in NAC and a task form is sent to a Mgr to approve. The Mgr has the option to Approve, Request Changes or Reject the form.

3.) If the Mgr requests changes, a notification is sent to the person who initially submitted the form. After changes are made to the form in the list, the submitter then confirms it before clicking the submit button.

4.) That approval task then circles back around to the Mgr once again to review the changes applied but its the second time that the task form fields won’t show the updates made to the form in the list (because only historical data remains in those fields).

Gosh, I hope this makes sense… is there a way I can share the workflow key with you privately to look at my workflow?

I’m putting something together now. You can export key and share it to me in a private message through here if you’d like. We may not need that if what I sent makes sense. :)

Option 1 - Use variables in workflow designer

Step 1) Create an item in SPO list for workflow to trigger. The demo below I want to show the custom fields (in red box) to approver. The other fields the workflow will update based on the action completed by the task owner for review & approval.

Step 2) Pass your values from SPO list into custom text variables (custom fields) before the task action is initiated. You will want one custom variable for each field you need shown on the task. 

Step 3) Pass your custom variables you just set as your values on your task form.

Step 4) On your “changes needed” branch for your task you then set custom your custom variables again to whatever was updated in the SPO list by the initiator. You can do this by updating the custom variables again using the set variables action and pass the object output of your wait for event in list item action. 

Results:

My initial item looks like this:

1st approver task for me looked like this: I clicked changes needed.

System waited for an edit on the specific item and only fires off when my resubmit field is YES. Same concept you have.

Here is my 2nd task as the approver (same task in my branch by stage branch - just with fresh data) since I set my variables on this form after the wait event action but before it goes back to the approval branch in my branch by stage branch. 

Final Workflow Overview: 

Option 2 - You could use “data sources” to query the specific item and render the information of your list item on the task form. I don’t like this option because….the approver has to wait for the form to load all the output values on your task approver form. See if option 1 works for ya. If not, I can provide detail instructions for this option but it’s more extensive and not the best user experience. 

Responding to your previous comment:

4.) That approval task then circles back around to the Mgr once again to review the changes applied but its the second time that the task form fields won’t show the updates made to the form in the list (because only historical data remains in those fields).

So, this I guess is considered historical “start” event data. I actually meant start event form data is historical for the user in My Nintex. Start event forms are saved historically for user under “Form submissions” and users can open their previously submitted forms to print them if they ever needed to or just look at them.

Same concept on a task. The email is convenient; however, all tasks are stored (regardless of the status) in the Tasks section under My Nintex for end users to manage all in one consolidated spot (if they wanted to) which we promote all the time with our internal customers vs fetching down emails they saw days ago and didn’t get to right away!

You’re SharePoint start event object data is stored in the instances section under automate (any start event data actually (start form, salesforce or SharePoint etc.) is stored in instances) and that is what you are choosing to take and pass to your task form - but unfortunately, it’s static data at the time the “new item” trigger occurred if that makes sense - like a snapshot of the item.

It doesn’t constantly sync and render latest version of the list item sadly - I wish! That is why you would use Option 2 (data sources) if you just want it “synced” each time the task form loaded by the assigned task assignee - so to speak. But again, the user experience suffers and it is slow and shotty. I only explain this, so you know it’s achievable if that is something you want to do in the future. 

Ok now I’m done, hope all this makes sense lol​​​​​

@brandiwoodson ,

I will look at this now and I am so grateful for your assistance… truly grateful! I will see if I can make use of this but if I need to send a private message via here, how do I send a private message? Would it be possible to send me something and I can reply with the key? 

Thanks!

Or respond to my message I just sent by visiting your private messages. :)