Best way to have closure categories in two places. One set we need to pass via and APi, and a second set for our own internal reporting.

[Adam Toms]

Morning all,

I know that closure codes can only be written to one place, but we need to captures two set of information. My understanding is that request category, would be during the ticket's open life cycle and the closure code, is at the point of resolution.

I need to record two set of closure codes. One that needs to go back to a third party via API for their reporting. Second batch is required for our own internal reporting, and both want their closure codes separate from each other.

I was thinking of using sub statuses, but that's rather clunky, as it's our own internal reporting and we can include substates in reporting.

 

Does anyone have any other ideas how I can achieve this without impacting the ticket massively and achieving the above?

Many Thanks

Adam

 

[Steve Giller]

Without overthinking this my first reaction would be to:

• Enforce a Category on Resolution
  • This would be the 3rd Party Category
• Copy that into a Custom Field
• Clear the existing Category
• Wait for a New Category before closing the Request
  • This would be your actual Closure Category

The caveat to this is that both Category trees would need to be available to the Analyst resolving/closing the Request, you couldn't filter by external category on resolution and internal category on closure, but you could test in the BPM and reject the Resolution/Closure if the wrong branch is specified.

[Adam Toms]

Thanks @Steve Giller for your help with this.

As our third party only has three closure codes and internally we're using several. We've managed to use the substates for them which pass through nicely using the API, giving them what we need and the teams can easily select those, and then use the closure codes within the resolution node of the ticket for their own internal reporting.

I imagine if both areas had several, that sub states would be a very clunky and your suggestion above we'd need to really give much more thought in and explore in greater detail.