Does the Parent field on sc_task have to be populated?

[grant_higgins]

There is a business rule called "Populate parent field in sc_task table" that sets the value of the "Parent" (parent) field to be the same as the "Request item" (request_item) field if the "Parent" field is empty at the time of update.

We have a use-case where we'd like to use the Parent field to relate Catalog Tasks to another record type, but I don't want to disrupt any processes or functionality that relies on the Parent field being populated with the Catalog Task's parent RITM. I would hope/imagine that any logic or relation between the 2 should go off of the "Request item" field.

Conversely, if a Catalog Task is created independent of a Request Item, then it doesn't have that field populated, and thus the Parent would stay empty, so I don't know if it matters all that much, or if this is just logic that ServiceNow added for the sake of populating the field.

In a nutshell, if I were to deactivate this business rule, would there be any unforeseen consequences that I should be aware of?

[Mike_R]

I would not deactivate. If ServiceNow created this business rule it has to be for a reason (even though it's not really documented).

Catalog Tasks are really designed to be used for tasks related to Catalog Items. You're gonna go down a rabbit hole if you start using these as sub-tasks for other record types and I would strongly advise against this.

What exactly is your requirement or use case. Maybe there is a better alternative we can suggest?

[grant_higgins]

We have a custom Major Incident table that extends Task, and have a use-case that if an issue is related to a catalog task or request item, that we need to be able to attach the catalog task to the Major Incident record as a child to show the number of affected records. We do something similar with Incident already, and just need to expand on what records can be associated to a Major Incident.

[Mike_R]

From a pure best practice standpoint, ritm/catalog tasks should not be used for issues. If someone raises a request for something that's really an incident, an Incident should be created instead. Then obviously you can relate that incident to the major incident. 

I don't want to lecture you but it just seems like this will be a regrettable decision down the line to link sc_tasks to major incidents. Even if it's possible from technical standpoint, it doesn't mean we should.

Just my opinion though. Obviously every customer is free to customize and use ServiceNow however they'd like.

[grant_higgins · Accepted solution]

I discussed the situation more with the stakeholders involved, as I also felt like attaching Catalog Tasks to a Major Incident seemed the wrong approach. The main reason I went with it in the first place, was because I knew that the Parent field existed on Catalog Task, and it seemed like it would have been simple to have it function similarly to how we have it work on Incident. However, I didn't realize that the Parent field got auto-populated by the business rule in question.

After explaining the details to them, and letting them know that the better approach would be to still create an Incident in the event that the Catalog Task's work was unable to be completed was the better approach, they agreed and we'll be moving forward with a different solution.

Thanks!