Complex Object In flow designer Update set

[ojaswini1]

Hi All,

What is exactly sys_complex_object with sys_id in update set , when we create a flow.

Is this neccessary in update set. What happens if we move the update set with target name flow and not the complex object. Will the flow and its action move when we move the update set with flow designer flow customer update and not the complex objects because I see so many complex object records in my update set. 

Kindly help.

@Ankur Bawiskar  @Pradeep Sharma @Chuck Tomasi 

Thanks in Advance!

[Sukraj Raikhraj]

Why is having the complex object in an updateset an issue? I would not make any changes as the complex object is needed , it will contained the updates...

[William David]

This thread needs to be revisited.

Complex Objects, as Customer Updates (records on the "sys_update_xml" table), can be created in Application Scopes for published IntegrationHub Spokes, even when a developer does not intend to customize objects (Actions, Subflows, etc.) in those IntegrationHub Spokes. These Customer Updates then get placed in the "Default" Update Set for that Application Scope (Update Sets are records on the "sys_update_set" table). However, this creates ambiguity for developers - are the Customer Updates inside the IntegrationHub Spoke's Application Scope (and associated with the "Default" Update Set for that Application Scope) necessary for the proper functioning of the objects contained in the Customer Updates that were created in the other Application Scopes targeted for customization?

An Example

I create two custom Update Sets, one in each of two Application Scopes.

Custom Update Set 1 [Application Scope 1]

Custom Update Set 2 [Application Scope 2]

Next I develop custom Flows, Subflows, et cetera, using Flow Designer, inside the two Application Scopes (1 & 2), with the Custom Update Sets (1 & 2) variously being used as the "Current" Update Set (recording the Customer Updates into the current Custom Update Set, whichever that happens to be at the moment). However, if while developing an object in Application Scope 1 or 2, I choose to invoke a defined object from an IntegrationHub Spoke, which is part of Application Scope 3, there are Complex Objects created, as Customer Updates, inside of Application Scope 3. Those Complex Object Customer Updates in Application Scope 3 are placed in the "Default" Update Set for that Application Scope. This occurs because there was no Custom Update Set created for Application Scope 3 (because I don't wish to modify any objects in Application Scope 3).

Do I need to promote, to my production Service Now instance, the Complex Object Customer Updates that were created in the "Default" Update Set of Application Scope 3, at the same time I promote my Custom Update Sets (1 & 2), to my production Service Now instance? Will abandoning these Complex Object Customer Updates, in the "Default" Update Set of Application Scope 3, cause customizations in Custom Update Sets 1 & 2, to be broken?

I am looking for a comprehensive explanation of the correct "Customer Update" and "Update Set" management procedures, when development activity spans multiple Application Scopes, like I have described above.

[Ankur Bawiskar]

@ojaswini 

If something gets captured in an update set OOB then it is required to be kept while transferring it to next instance

sys_complex_object -> table which holds the information

more details here

NEW YORK: FLOW DESIGNER COMPLEX OBJECTS

Complex data

Regards
Ankur