Hi Katherine,
What fields are you updating on the installed item record?
Is the process flow updating these fields at the database directly (via SQL)?  Or is it doing it through an API talking to the installed item module in Alliance?  If it’s being done through an API can you give us an example to look at?
Thanks,
Reid

Hi Reid,

Thank you for the quick response. 

The process flows are updating the installed item via an API call.  We have multiple process flows which are updating custom fields and one that updates the Item Notes field. 

Here is one Process Flow Action example:

<root xmlns:dt="urn:schemas-microsoft-com:datatypes">
    <session email="" alias="">
        <state bc_name="item_installed" use_cache_refresh="False" is_retry_on_optimistic_error="true" max_retry_on_optimistic_error="50">
            <action name="data">
                <main>
                    <row number="1">
                        <item_id in_var="" out_var="">{item_id}</item_id>
                        <cst_phase in_var="" out_var="">{new_item_phase}</cst_phase>
                    </row>
                </main>
            </action>
        </state>
    </session>
</root>
 

Thanks,
Katherine

Can you run a quick test where that API populates the tagno field (add a line right above your cst_phase entry and just put a random value in the tagno field, just make note of the original value so you can set it back to the previous value afterwards), I just want to see if triggering a change to a standard field will get the update pushed out to mobile).
Thanks,
Reid

Hi Reid,
 

Thank you for the suggestion. We ran multiple tests and here is what we discovered:

1. Updated in Back Office - Installed Item on a call

• Standard field changes are visible immediately.
• Custom field changes not visible immediately unless work list is refreshed.
• If a standard field is also updated in back office, all changes will be visible immediately.

2.  Updated in Back Office - Installed Item not on a call

• Standard field changes are visible immediately.
• Custom field updates not visible even after work list is refreshed. Need to reinitialize to see the change.
• If a standard field is also updated in back office, all changes will be visible immediately.

3. Updated by Process flow - Installed Item on a call

• Refresh shows the changes for both standard and custom fields.

4. Updated by Process flow - Installed Item not on a call

• Refresh will not show the changes for standard or custom field without reinitializing.

Hi Reid,

Katherine and I are working to finalize some changes and we are hoping you could provide any additional information regarding our latest testing notes above.

Thanks,

-Nick

Hi Nick,
I don’t know the exact details of the criteria that is used to determine whether a change should be dispatched out or not in these cases, hopefully one of the developers can comment on the logic that is being used here and maybe that will shed some light on it...
Thanks,
Reid

Hi @Reid Gilbert, hope all is well.  Can you please ask one of the developers if they can please comment on this topic?

Thanks,
-Nick

Now adding @IgorKevesh...

Hi @Reid Gilbert and @IgorKevesh 

We are still trying to figure this issue out on why the changes made by a process flow are not being registered in the same manner as when manually updating a standard field on the installed item.

In our testing we found that there is a call to a stored procedure that inserts records into the mobile_messages table which seems to be the key to pushing the changes down to Mobile device.  The process flow does not insert into this table so the change does not seem to push out to Mobile without performing a refresh/reinitialization.  

Is there a way to have the process flow also insert a record into the mobile_messages table?

Thanks,
-Nick

Hi Nick,
I would suggest logging a ticket for it at this time, this will probably require technical assistance from our Services team.
Thanks,
Reid

Installed Item dispatches only occur when items are added, deleted, or a subset of standard fields are changed.  To work around this limitation, we added the following section to the API so that when the item is updated via Process Flow, a forced dispatch occurs:

<root xmlns:dt="urn:schemas-microsoft-com:datatypes">

  <session email="" alias="">

    <state bc_name="item_installed" use_cache_refresh="False" is_retry_on_optimistic_error="true" max_retry_on_optimistic_error="50">

      <action name="data">

        <main>

          <row number="1">

            <item_id in_var="" out_var="">{item_id}</item_id>

            <cst_phase in_var="" out_var="">{new_item_phase}</cst_phase>

            <cc_mobile_item_event>AddItem</cc_mobile_item_event>

          </row>

        </main>

      </action>

    </state>

  </session>

</root>

Thank you Andrew. The solution you proposed worked perfectly for our issue.