This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Service Catalog processes requiring multiple participant inputs

So unless I've been missing something for quite a long time, I don't think there's a great way to accomplish what I'm after in a meaningful way.  The system can ALMOST accommodate using various techniques, but nothing is really satisfying.  Anyhow, I'm curious how people are dealing with workflows that really require inputs from multiple people in the real world.

For example: our onboarding process requires input from both HR and the hiring manager.  Currently we force all employee status requests through HR so that we get accurate data (e.g. names, reporting structure, etc), but HR has no idea if the new employee requires a laptop.  This puts HR in a position to ask the hiring manager offline, and because that's a pain they often just punt, which puts IT in a position to hunt people down.  So our workflows are somewhat cluttered with crumby tasks like "determine if they need a flippin computer" when someone chooses the "I dunno" option.

It really feels like the system should be able to handle things like this.  Process Stage 1 variables are completed by X, and Process Stage 2 variables are completed by Y, and then IT can do its thing.  Instead we're locked into a "one person gets one try to fill out these variables correctly and if they don't do it right then IT can just pick up the pieces."

Thoughts or suggestions?

Parents
  • The way that we've *solved* this problem at our company is that the Hiring Approval flow is a separate process. Once the new employee hire is approved, we have a "New Hire Technology Request" form that gets filled out by the hiring manager.

    We have tried making monolithic onboarding forms like this in the past, and ended up with a lot of messed up onboards for a number of reasons:

    • The ticket would be closed out by someone who didn't realize all of the tasks hadn't been completed
    • Between the ticket being opened and getting to later tasks, the needs of the onboarding employee had changed
    • The form becomes hard to fill out because it requires input from too many groups, creating a bunch of back-and-forth emails which reduce the value of the self-documenting process the form provides.

    Since what you're describing seems to be two separate pieces of the hiring and onboarding process, I recommend breaking it up into separate forms. While it's tempting to put everything into one "catch-all" form, it can get confusing and tends to be hard to maintain.

Reply
  • The way that we've *solved* this problem at our company is that the Hiring Approval flow is a separate process. Once the new employee hire is approved, we have a "New Hire Technology Request" form that gets filled out by the hiring manager.

    We have tried making monolithic onboarding forms like this in the past, and ended up with a lot of messed up onboards for a number of reasons:

    • The ticket would be closed out by someone who didn't realize all of the tasks hadn't been completed
    • Between the ticket being opened and getting to later tasks, the needs of the onboarding employee had changed
    • The form becomes hard to fill out because it requires input from too many groups, creating a bunch of back-and-forth emails which reduce the value of the self-documenting process the form provides.

    Since what you're describing seems to be two separate pieces of the hiring and onboarding process, I recommend breaking it up into separate forms. While it's tempting to put everything into one "catch-all" form, it can get confusing and tends to be hard to maintain.

Children
  • Thanks for the input - this is the direction we're moving in.  It doesn't quite solve the problem because there is no linkage between the two requests, and they both need to be delivered in our case at the same time.  I believe this will introduce an incident management challenge but be better nevertheless.

  • It IS possible to automatically generate another record using the Process Integration feature if you don't mind the added complexity.

    At some point in the first form, you can have the process generate a second incident (or catalog item) using a process integration with SWSD. Since it's just taking advantage of SWSD's own API, it's pretty powerful. You also have the benefit of being able to automatically link the two incidents by using the {{context.id}} variable in the payload:

    { "incident": {

    ...

      "incidents": [

        {"id": "{{context.id}}"}

      ],

    ...

    }

    I don't know that the above exactly suits your needs, but it might give you some additional options.

    How to create an incident with SWSD API

    How to use Process Integration in SWSD

  • Yeah, unfortunately that doesn't work because you need to know the variable inputs for the second service request in advance, because once it's created those variables can't be updated.  What we need is a mechanism to capture variable input in multiple stages during a request, or a way to provide an actual functional link between two incidents (not just a reference).

  • You can edit the variables for Changes if that's a workaround. Aside from that I think you'd probably need to build a custom solution using their API at that point. Ping me if you figure something out!

  • Yeah for the most part we like how Changes are implemented, especially being able to restart a process.  Don't want to clutter up our CM process with service requests though.  Trust me, if I do happen to figure something out I'll let the whole world know :)  Been noodling around on this for wayyyy too long.  I do think separate requests is better - it's not good, but it's likely better.