Activities on Incidents (IR) not treated the same as Activities on Service Requests (SR)

Jason_MeyerJason_Meyer Customer Adept IT Monkey ✭✭
We are just now learning that Activities are not treated the same on IRs as they are on SRs.   This seems like a bug or programming issue.  We have several IR situations that require multiple Support Groups to resolve.

Is Cireson or Microsoft addressing this?

Are there any workarounds available?

Answers

  • damon_mulligandamon_mulligan Cireson Consultant Advanced IT Monkey ✭✭✭
    I do not see Microsoft resolving this. I have rarely seen anyone place an Activity on an IR, however, one option would be using a Support Group list extension for the Manual Activity. Then to add to the Portal, download item at end of this... https://community.cireson.com/discussion/169/add-support-group-field-to-portal-ma-activity-form#latest


  • Jeff_LangJeff_Lang Customer Advanced IT Monkey ✭✭✭
    We actually have a few incident templates setup this way, as in the manual activity class extended for support groups, then manual activities on those incident templates that require it.

    That way the incident can be assigned to a support group for resolution, but the manual activity is assigned to another support group for notification purposes, this way they don't have to wait for another support group to perform a function and then reassign it, and they can perform functions if needed before completing the manual activity
  • Geoff_RossGeoff_Ross Cireson Consultant Super IT Monkey ✭✭✭✭✭
    @Jason_Meyer
    What particular differences in functionality are you looking to resolve? There is always something that can be done.
    Geoff
  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited May 2018
    Second both @damon_mulligan and @Geoff_Ross here.
    • To Geoff's point - anything is possible
    • To Damon's point - I agree that I don't see Microsoft "resolving" this because there isn't necessarily anything broken

    But to expand further on Damon's point, the higher level ITIL approach to be taken here is that Incidents by their very nature are break/fix. Service Requests are in the realm of "Nothing is broken, I just need something" and thus follow a more sequential workflow style process.

    So when building an Incident template with Activities, I'd like to think it makes a fair amount sense that you can only choose a Manual Activity or Automation (SCO/SMA) although I do sympathize with the need you're trying to solve.

    That said, you either are going to hand out additional work/Manual Activities, notifications (to @Jeff_Lang's point), or invoke automation as a means to resolve the Incident faster. Analysts either apply IR templates with runbooks already on them or at a higher level of System Center planning - when Operations Manager (SCOM) generates Alerts, they automatically create Incidents that feature pre-planned Runbooks to further cut down on Incident resolution time.

  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    Ok, I'll jump in too.  What if a certain category of incident has a resolution process prescribed for it, including troubleshooting and resolution steps?  And what if some steps should occur in parallel rather than sequentially, so that different teams (per @Jeff_Lang's comment, we have added support groups to MA's and have already seen benefits to it) can work concurrently?

    @Adam_Dzyacky is correct here, but even if I do not know the specifics of an incident to the extent that I would have root cause and workaround defined in a Problem, I may still have a process for dealing with it which may span days and involve multiple teams, rather than fitting nicely into a bullet list of a KB article.

    What I am describing is somewhat of an edge case, but I would still like to be able to handle it appropriately.  That is where I agree with @Geoff_Ross and look forward to seeing this tackled.
  • Jason_MeyerJason_Meyer Customer Adept IT Monkey ✭✭
    @Geoff  We have created Request Offerings that generate an IR work item, that have Activities.  Unlike SR work items, the system allows for the Incident work item to be 'resolved' and 'closed' prior to the handling/completing of the Activities.  Once the work items is Closed our Analysts can no longer cleanup the Activities and our Service Manager / Cireson Portal application administrators have to go in and manually clean them up.  We would like the system to treat Activities the same across the board.  IR, SR, CR, etc..
  • Jason_MeyerJason_Meyer Customer Adept IT Monkey ✭✭
    Doesn't it make sense to treat ACTIVITIES the same across work item type?  Having variations makes for a more difficult product to use/train/support.
  • Jerry_VeldhuisJerry_Veldhuis Customer Advanced IT Monkey ✭✭✭

    We have similar issues with this situation. If the IR is resolved with MAs still in-progress, then they remain in the My Work queues. Please up-vote:

    Please up-vote:

    https://community.cireson.com/discussion/4219/ir-change-status-task-add-option-to-block-resolving-ir-with-active-mas

  • Jeff_LangJeff_Lang Customer Advanced IT Monkey ✭✭✭
    @Jason_Meyer  i had posted this in another thread but will add it here as well.

    to prevent incidents being closed before manual activites are completed you could do this in your custom.js
    app.custom.formTasks.add('Incident', null, function (formObj, viewModel) {
    formObj.boundReady( function() {
    var vm = pageForm.viewModel;
    for (i=0; i < vm.Activity.length; ++i) {
    if (vm.Activity[i].Status.Name == "In Progress" || vm.Activity[i].Status.Name == "Pending") {
    $( ".taskmenu li:contains('Change Status')" ).hide();
    }
    }
    });
    });
    obviously this only helps within the portal and not the console though

Sign In or Register to comment.