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

Jason_Meyer

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?

damon_mulligan

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_Lang

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_Ross

@Jason_Meyer
What particular differences in functionality are you looking to resolve? There is always something that can be done.
Geoff

Adam_Dzyacky

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_Hendricks

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_Meyer

@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_Meyer

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_Veldhuis

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_Lang

@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

</code><code>app.custom.formTasks.add('Incident', null, function (formObj, viewModel) {<br>	formObj.boundReady( function() {<br>		var vm = pageForm.viewModel;<br>		for (i=0; i < vm.Activity.length; ++i) {<br>			if (vm.Activity[i].Status.Name == "In Progress" || vm.Activity[i].Status.Name == "Pending") {<br>				$( ".taskmenu li:contains('Change Status')" ).hide();<br>			}<br>		}<br>	});<br><span>});</span>

obviously this only helps within the portal and not the console though