Problems with databindings in forms with multiple views

  • 7 July 2015
  • 1 reply
  • 1 view

Badge +1

The title may be misleading but that is as close as I can tell what the problem is at the moment.  I am currently working on a process that involves a lot of roles and steps touching one user record in a SharePoint list.  I realized early on that in all the interactions, there was some common information that needed to be provided to all roles for all tasks so I created a view off of the SmartObject Called 'User Header' that included this information.  From then on, for each task or group task, I created a second view that included only the additional fields that were needed (sample form shown below).

 

  12859i64EFCFF7B7D404B4.png

 

The problem I am having is that the header seems to be bound to the smart object and the lower view is not.  During single pass tasks this is not a problem, but if the user opens a task, checks a box and saves it, the list is updated, but when they reopen the task, since the binding is missing none of the check boxes reflect previously completed work!

 

What I have checked:

1) The General settings are pointing to the same SmartObject List path and item as the header view

2) I have created a rule to look up the list item during form initialization to force the bind (no joy there either)

3) I have added non-boolean fields to the form to make sure it wasn't just an issue with the checkbox control (it failed to retrieve or bind with a text box too).

 

I'm stumped.  At this point I feel I may be forced to reengineer a bunch of forms which seems to defeat the one of the purposes of the view (repurposing common data source groups).  Any ideas welcome.


1 reply

Badge +1

I was finally able to figure this one out on my own and it involved a workflow detail I had overlooked.  The process in question had been launch from another workflow as the main process was defined originally for one role, others were launched using 'child' workflows.  

 

What made this odd was the fact that the header info was being retained at all.  I was able to figure out what was going on by eliminating the two view approach and merging them into on for one of the cases.  I saw all the data from the smartobject disappear.  Turned out when the sub-workflow was run link to the underlying list item was lost.

 

The solution was to add a rule to the view that fires after the view is initialized.  Make sure a parameter is defined that passes the item id of the list item is defined in the view (and form so it can be passed in).  In this rule define an action that performs a look up item by id and then provide the parameter defined as the input.

 

Now when the form loads, even after a prior save, it will populate the form correctly.

Reply