Child ticket best practices

[Brad Warman]

Hi,

We have a custom application which consists of a single table for one of our business units to log and track their own tickets. This was created as a simple ticket tracking app, but now their requirements have grown and they would like to start utilising a scaled back version of the ITSM request management. As this solution contains highly confidential data, we are still required to keep it on seperate, custom tables, but I was wondering what the communities thoughts are on the best way to incorporate a 'child ticket/task' option, much like the way RITM's and SCTASK's work.

Would we be better off keeping child tickets on the same table, providing a link in each record, much like the incident table works, or would we be better off creating a new table and spawning the child/task tickets on there and linking to the 'parent' on the parent table (more like RITM/SCTASK)?

The main priorities for this would be ease of use for customers and well as best option for reporting purposes.

Cheers,

Brad

[ScottG_SN]

Hey Brad

Would it be possible for you to migrate this to a scoped app for request management? This way you can take advantage of the out-of-the-box relationships and save time in the long run configuring this from scratch as the application scales.

Scott

[Brad Warman]

Hi Scott,

This is already a scoped app, but how would I make it a scoped app for request management? I didn't realise that it was possible to make a scoped app that used OOB tables and relationships etc.

Cheers,

Brad