Home Analyst Portal

Show Parent/Child Service Requests in the Portal

Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭
edited March 2022 in Analyst Portal

We have a very large request offering to request all sorts of hardware and/or permissions.

For that we have a runbook, which creates child Service Requests based on the user's selection. For that I want to add these Child Requests as HasChildWorkItem Relationships to the master request. Based on a community discussion from 2017 I know now, that I have to decalre the master request as isParent = true, so the HasChildWorkItem field is shown. This also works and if I get my Child Requests with the help of a Orchestrator Runbook, it also works.

BUT, in the service request form the service requests ae not shown, I guess this is based on the fact, that even if I type in the ClassId "f59821e2-0364-ed2c-19e3-752efbb1ece9", which is the WorkItem Class, I may only select incidents if I press the Add button. So the field will also only show incidents, if these are shown as Child items. Same goes for the HasParentWorkItem relationship.

I guess this is something which is hard coded inside the Cireson code - So is there any way to fix this? I would like to keep this Parent/Child Relationship, but if these are not shown inside the Parent/Child Requests, the Relationship is useless :(

Best Answer

  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭
    Answer ✓

    Hi @Simon_Zeinhofer

    This could be added with some custom JavaScript that would run on the SR open event if the isParent property is True.

    It could run some SQL that would look for related SR's and show a list or drop down or tabs etc. for each of the SR's, depending on how you wanted to visualise it.

    I don't think this would be difficult to do.

    If I was to make a suggestion, it would be that if there are multiple "Tasks" that need to be done under a single request, it might be better to do these as Activities under the one SR rather than creating child SR's. It might end up with a very large and complex series of activities under the one SR, but at least then it would be all in one location and you could deal with success\failures in an easier way.


    Hope this helps.

    Brett

Answers

  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭
    Answer ✓

    Hi @Simon_Zeinhofer

    This could be added with some custom JavaScript that would run on the SR open event if the isParent property is True.

    It could run some SQL that would look for related SR's and show a list or drop down or tabs etc. for each of the SR's, depending on how you wanted to visualise it.

    I don't think this would be difficult to do.

    If I was to make a suggestion, it would be that if there are multiple "Tasks" that need to be done under a single request, it might be better to do these as Activities under the one SR rather than creating child SR's. It might end up with a very large and complex series of activities under the one SR, but at least then it would be all in one location and you could deal with success\failures in an easier way.


    Hope this helps.

    Brett

  • Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭

    @Brett_Moffett we "solved" it by relating it with another relationship.


    Because of the volume of this certain request, activities would be too much. We had it that way but the request would fail if e.g. SAP permissions wouldn't be granted, but the rest was ok.

Sign In or Register to comment.