How to make a ticket (or deal) dependent on another one

The prospect would like to have the possibility to define a "dependency" between tickets. When a dependency is set between two tickets, the dependent ticket cannot be closed until the main ticket is closed first.

There are two possible variants to this (both will be covered), one in which a ticket can only be dependent from one other ticket and one where a ticket can depend on multiple main tickets.

The solution will here be described in the case of dependent tickets, but the same set-up can be used for deals.

Case 1 - Single dependency

In case each ticket can only depend from another one, we will need the following assets:

A pair of association labels to identify which dependent tickets are associated to which main tickets
Two custom properties
- One that will check if the user is dependent on another ticket
- One that will be used to define if the ticket (or deal) can advance or not
A workflow to set the custom property so that the record can advance

Association label - Dependant/Main

Thanks to same-object association, we can identify the relationship between two tickets. In this case we will be using a pair of labels to also capture which one is the "Dependant" and which one is the "Main". Here below the definition used in this case.

Custom property - Ticket can advance

The custom property (here named "Ticket can advance") is a Single checkbox property that, as the name suggests, is used to define if the ticket can advance to any specific stage in the pipeline.

In order to do that, the property needs to be set as a required property for those stages we don't want the ticket to be moved to without prior validation (which means without the property being set to "Yes"). In the example below, the only stage we want to "lock" is the "Closed" stage.

In order for this to work, the "Ticket can advance" property must be empty. This depends on how required properties currently work.

In order to make this solution more robust, you might want to limit the editing rights to the Ticket can advance property, so that it can't be manually edited by the users.

Custom property - Depends on # tickets

The custom property (here named "Depends on # tickets") is a Calculation/Rollup property that counts how many tickets with the label "Main" are associated to a ticket. Here below the definition.

This property is needed because we want to allow tickets that don't have any dependency to be moved, and for this we need to set the "Ticket can advance" to "Yes" for them (this will be clarified in the next section, when discussing the workflow).

Workflow - Ticket can advance

Now that we all the properties and labels in place, we need to set up a workflow that will automatically change the value of the "Ticket can advance" property, thus allowing the users to move the ticket to other stages.

The workflow (here below) should cover two conditions:

A ticket has no dependencies
A ticket has a dependency, and the main ticket is closed

Bonus Workflow - Ticket cannot advance

In case a ticket is created without being immediately associated to a main one (but should be or will be at a later stage), it will go through the first workflow, setting the "Ticket can advance property" to "Yes". In order to cover this case, we can create a second workflow that would reset the "Ticket can advance" property when an association is established. Here below the workflow.

In order for this to work, the "Ticket can advance" property must cleared and not set to "No". This depends on how required properties in pipelines currently work.

Case 2 - Multiple dependencies

In case each ticket can depend from more than one main, we will need to make a couple of modifications:

Add two more custom properties
- One that will count how many associated tickets have been resolved
- One that will count how many associated tickets are yet to be resolved
Modify the two workflows to take into account the new properties and set the right values for them

Custom property - Number of main Tickets Resolved

The custom property (here named "Number of main Tickets Resolved") is a Number property that, as the name suggests, will count how many of the associated tickets have already been resolved. This is necessary in order to be able to only allow the dependent ticket to be moved once all of the main tickets are resolved.

Custom property - Number of main Tickets to Resolve

The custom property (here named "Number of main Tickets to Resolve") is a Calculation property that does a simple subtraction between the "Depends on # tickets" property and the "Number of main Tickets Resolved" property, as shown below.

Workflow - Ticket cannot advance

This time the workflow that will reset the dependent ticket status is needed because we will also use it to set the initial value (of zero) of the "Number of main Tickets Resolved" property. Here is the complete workflow.

This workflow could be improved to also cover for the case in which a new main ticket is associated after a while.

Workflow - Ticket can advance

The workflow that will set the value of the "Ticket can advance" property will now do three things:

Allow tickets that don't have dependencies to be moved
Increase the "Number of main Tickets Resolved" property every time a main ticket is resolved
Allow the dependent tickets to be moved if all of the main tickets have been solved

Here below the full workflow

Conclusions

If we've followed all the steps, a user won't then be able to immediately move the ticket to the closed stage, but will be prompted with the "dependent properties" window.

As mentioned, in order to make this solution more robust, we can limit the editing rights to all of the properties created, so that the "Ticket can advance" property will only be modifiable through the workflow and the user won't have the choice to change it from the "dependent properties" window.