Parent/Child Field Sync (Advanced Only)

• Allows a parent ticket to synchronize a ticket field value or a process persisted field value with all split child tickets
• Allows a child ticket to synchronize a ticket field value or a process persisted field value with the parent ticket
• Configure which fields to copy and when the values will be copied.

Parent and Child Tickets

When designing your workflow to handle the the processing of a ticket, it is sometimes desirable to split the processing to include other child tickets (See Parallel Process Pattern).  This may be to allow different groups to handle activities related to the original ticket.  For example, in an Onboarding process, you may create separate parallel (child/split) tickets to handle IT provisioning, HR processing as well as the activities that would occur on the main ticket (e.g. welcoming the new employee to the team).

When this parallel processing pattern is used, there will likely be data (in the form of ticket fields or process persisted fields) that the parent ticket would control and some that would be controlled by child tickets.  In the Onboarding example, the parent ticket will control the employment start date, but the HR and IT child tickets are likely to be interested in when that start date is.  However, if the start date is not known when the HR and IT child tickets are created, or if the start date changes, then the child tickets will be interested in the new start date.

Flowset Advanced models allow you to define if a ticket field based task field or a process persisted field based task field should be synchronized from a parent to its children when the value is committed to the parent ticket (when the activity finishes and you transition onwards).  You can also define that a ticket field base task field or a process persisted field based task field be synchronized from a child ticket to its parent.

The above shows a process definition.  When the Issue Offer activity finishes and transitions to Confirm Start, 2 separate split child tickets are created for Handle HR and Handle IT.  The Confirm Start activity will capture and confirm the new employee start date and when this happens (when we transition on to Prepare to Welcome), the confirmed start date will be copied to the children tickets.

Defining copy to child tickets

The following example shows the copying of the Confirmed Start Date ticket field from a parent ticket to its children tickets.  The task fields involved are of type Ticket Field and refer to the Confirmed Start Date ticket field. 

It is equally possible to define Confirmed Start Date as a process persisted field instead of a ticket field.  In this case, the task field type would be set to Persisted Field rather than Ticket Field.

The choice whether to use ticket fields or process persisted fields is down to the workflow designers preference.  If the ticket field already exists or if you want the value to be stored explicitly on the ticket then using a ticket field would make sense.  If you do not already have a ticket field and do not want to have this information stored explicitly on the ticket, then process persisted fields make sense.

The Confirm Start activity is implemented by the following task model.  

Edit the task fields associated with the task.

The Confirmed Start Date ticket field has been configured to be controlled by the Confirm Start task.  The Copy to child tickets option has been selected.  This means that when the agent has set a Confirmed Start Date and it has been committed to the parent ticket (this occurs when we transition the parent ticket from Confirm Start to Prepare to Welcome), the value of this field is copied to any existing child tickets (in this case Handle HR and Handle IT).  This mechanism allows the parent to control the Confirmed Start Date, but to communicate it to the child tickets once it has been set.

The child ticket will be running a workflow as defined in the in the workflow definition.  If you wish the child ticket to react to the value that has been copied from the parent ticket, then the task model in the child ticket should include a ticket field based task field for the copied field (in this case Confirmed Start Date), but it should be set to be read only.  The child ticket should read the value, but should not update it (otherwise it will clash with what the parent ticket has done).

Consuming new values in the child tickets

Click on the (+) icon in the top right of the split child ticket definition (e.g. Handle HR), this will navigate to the workflow which will run on the child ticket

Here we see a simple process for Handle HR in which there is a single activity (also called Handle HR) which has a task model defining the detail of the activity.  Click the arrow in the top left of the activity to see the task model.

In the child process, we do not want to proceed until the Confirmed Start Date ticket field has been set.

The ticket field (Confirmed Start Date) is included as a ticket field base task field in the task Await start date.  Notice that it is readonly.  This is because the child ticket is not controlling this value but instead reacting to it when the parent ticket changes it.  If this field was not set to be readonly, the child ticket would control its own value for this field and would ignore any update that occurred due to the parent copying the value to the child ticket.  It is also important that you do not specify an initial value for the field.  If an initial value is specified, this will trump any value that may be set when the parent ticket is processed and the new value will not be reflected in this child ticket.

The Await start date task is immediately followed by a Decision in which a condition is defined that is only satisfied when the Confirmed Start Date has a value.

This definition means that the process running on the Handle HR child ticket will not allow any further progress until the Confirmed Start Date has been given a value by the process running on the parent ticket.

Copy to Parent Tickets

The copy to parent ticket option works in a similar way except that it copies a ticket field value or a process persisted field value from a child ticket to the parent ticket.  For example, the Handle HR child ticket may capture information in a ticket field or process persisted field that should be copied to the parent ticket at some point in the child process.

The mechanism for defining this is similar to that described above.  The main difference being that the task field should be editable (not readonly) in the child process definition and readonly with no initial value in the parent definition.  It should not be editable in both parent and child since they will both manage their own copy of the ticket field and shared data will be ignored.