locked
Apply specific template based on Business Service in one workflow RRS feed

  • Question

  • Here's the scenario: We have a "report a problem" request offering on the SMportal that asks the user to select a business service (out of 20) from a query list, and describe the issue. This gets applied to a generic incident template with title: "Operational problem" where the business service and description are mapped to Related items and description field. 

    But what if we want to apply a specific template based on the business service selection WITHOUT making 20 workflows? I don't want to put pressure on SCSM if I can avoid it. So is it possible to do something clever here. 

    My thoughts sofar in pseudo-code:

    If an incident is made from Request Offering "Report a problem" (first narrowing scope)  -> Apply template.[Incident.Get-Related Business Service]

    The template ID's are then renamed to correspond to the business services names.

    Could this approach be possible in any way? Or how would you do it?

    Thanks


    Friday, January 18, 2013 6:03 PM

Answers

  • That's a valid approach and could be accomplished with a custom workflow (Powershell, C#, whichever) that is triggered whenever an incident is created.

    The part you'll have to be careful with is how you link your incident templates and business services together. You'd be creating "pseudo-relationships" that will require administrative overhead to maintain. For instance, whenever you create a new business service used in this situation, you'll have to remember to create an incident template that matches the ID of that new business service. Secondly, there would be little opportunity for template consolidation since the pseudo-relationship is 1-to-1 (one and only one template per business service..but there are less restrictive ways of creating those pseudo-relationships). Furthermore, the custom workflow will have to have a way of identifying which business services are used in this situation. You said you have 20? You'll need a way to identify them (a custom boolean property or something that indicates they have a companion template).

    Those are just some thoughts to consider..but your original thought is a good one. At a fundamental level, you're applying templates based on criteria, but without using multiple workflows.

    • Marked as answer by Morten Meisler Wednesday, January 30, 2013 9:14 AM
    Friday, January 18, 2013 6:34 PM

All replies

  • That's a valid approach and could be accomplished with a custom workflow (Powershell, C#, whichever) that is triggered whenever an incident is created.

    The part you'll have to be careful with is how you link your incident templates and business services together. You'd be creating "pseudo-relationships" that will require administrative overhead to maintain. For instance, whenever you create a new business service used in this situation, you'll have to remember to create an incident template that matches the ID of that new business service. Secondly, there would be little opportunity for template consolidation since the pseudo-relationship is 1-to-1 (one and only one template per business service..but there are less restrictive ways of creating those pseudo-relationships). Furthermore, the custom workflow will have to have a way of identifying which business services are used in this situation. You said you have 20? You'll need a way to identify them (a custom boolean property or something that indicates they have a companion template).

    Those are just some thoughts to consider..but your original thought is a good one. At a fundamental level, you're applying templates based on criteria, but without using multiple workflows.

    • Marked as answer by Morten Meisler Wednesday, January 30, 2013 9:14 AM
    Friday, January 18, 2013 6:34 PM
  • Thanks for the feedback. I think i'll stick with the conventional way of applying a template through a workflow made in console. As the workflow count seems to be the same, and only some business services needs a unique template, while the others can be grouped together.
    Wednesday, January 30, 2013 9:14 AM