Jump to content

Recommended Posts

Posted

I'm not sure if it's something I'm doing wrong but it looks very much as though the service is an essential field. If I don't include it in the progressive capture then I get some unexpected results. The HUD isn't displayed and it would appear that the BPW stops as well. 

Now, for certain types of Incident we want to set the service and not allow the logger the option to override the assigned service. I can't find anything in automated tasks, am I looking in the wrong place?

Your help is much appreciated.

Doug

Posted

@DougA you won't be able to set the service via BP, first reason is that the BP is tied to the service. There is one exception but with a drawback. You can set a default BP to spawn on specific request type (e.g. incidents, service request, etc.). This can be done via application settings. The drawback is that it will be applied to ALL incidents, however IF you have a service associated to the request that is being logged, the BP on the service will take precedence.

Also, currently, there are no automatic tasks to set a service, for a variety of reasons, for example if you spawn BP1 on a request then in this process you change the service, the new service might have a different BP associated to it, let's say BP2. It would mean BP2 has to spawn and BP1 to be removed from the request which can't be done.

You mentioned "certain types of incident"... can you please detail on this, what is the pattern for these incidents, maybe we can find/think of alternative ways to achieve what you need?

Posted

The simplest scenario I can think of is when logging an Incident which will normally only consume the helpdesk service. There's a few other instances where the data being collected in the PCW could need to be allied to a their own service. If the service is predefined as it is in these cases then we'd prefer the analyst not to be able to selecti a different one. We've a large list of services that we're using for Service Request.

The  app.email.routing.rules.default.service.IN ( The default service to use when logging a new incident ) is already set to the service we want to use.

Hope this makes sense!

Posted

@DougA this setting app.email.routing.rules.default.service.IN is used when requests are logged by system Auto Responder (as far as I am aware), not when requests are logged manually by analysts (or any other means).

 

If you using only one service to log requests for incidents, you could set a default business process for incidents via app.requests.defaultBPMProcess.incident application setting. This way you won't need a service and you will have a BP (HUD) when logging an incident. However things get a bit complicated if you intend to use the SLM (Service Level Management) functionality which is closely tied with services, SLM does not work without a service.

  • 1 month later...
Posted

We'd really like to be able to enforce the service for Incidents, known errors, problems and changes. It's our intention to implement SLM but doesn't that makes it much more important that the correct Service is selected?

There are settings for the Incidents and Service Requests default service on email routing. My thoughts were to add settings for the default service for each request type. If a choice is to be allowed simply include the service form in the pro-cap. Could I make a formal request for such a feature?

Many thanks

Doug

Posted

Giving this even more thought :)

Another solution would be the ability to define the default value/visibility in the form as per custom forms.  

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...