3 Replies Latest reply on Feb 12, 2018 8:43 AM by Christopher.Bakken

    Assistance with request workflow development

    ggarcia@marchofdimes.org Apprentice

      We have a request that needs to go to analysts in "Team A" for verification and validation. Like a normal request someone on that team will claim the ticket and work on it and possibly add some notes.  Once they have completed their work they need a way to determine whether o move the request to the next step or to just close the ticket.

      If the move to the next step, it needs to move to analysts in "Team B" who will do other things and take the ticket to completion.

       

      We are new to building request offerings and haven't encountered this use case before.  How would you build this in the system's "Plan Request Fulfillment"?

      All of our requests so far are a start block going to an update block to assign to the appropriate team, then a stop block.

      We haven't experimented with the Workflow and Task blocks but assume those will be used somehow here.

       

      Thanks for any feedback and suggestions!
      Geoff

        • 1. Re: Assistance with request workflow development
          Christopher.Bakken SupportEmployee

          You can use Task blocks to halt the request until the task is completed, at which point you can have a different task fire for Team B. If Team B is only linked to the completed line of the task for Team A, they will only get a task created once Team A finishes their work and completes their task.

           

           

          Here is an example.

           

          Tasks are sent to multiple teams, but the WF wont complete until all the tasks have been completed (Through the join block). You could just as easily put another task block after the join.

           

          • 2. Re: Assistance with request workflow development
            ggarcia@marchofdimes.org Apprentice

            Thanks Chris that example is very helpful! Can you explain what the "Invoke Workflow" block does that you have right before the stop? and why you use that type of block as opposed to another task block?

            Thanks and apologies for what I know is a 101 type question.

            Geoff

            • 3. Re: Assistance with request workflow development
              Christopher.Bakken SupportEmployee

              As the name implies, it just fires another workflow. This one is a special case in terms of request offerings and you will see this same thing in many of the OOTB offerings.

               

              It's so the service request can still 'manage' ad-hoc tasks that weren't added as a part of the main fulfillment workflow.

               

               

              This is the workflow that gets launched. All it really does it wait until all tasks have been completed in the offering, at which point it updates to fulfilled.

               

              The wait block has a timer of 10 days, so if it's not able to update to fulfilled after 10 days, it throws an error. Since the previous WF was already using a join block to wait for the automated tasks to complete, this is for any tasks that weren't a part of that WF.

               

               

              So in the case of the above example, it basically has a 'sub-process' that is watching the status of all tasks while the main offering is responsible for the lifecycle of the automated tasks. It has a 10 day timeout if it sees that all tasks aren't completed. This allows you to create tasks that weren't a part of the initial automation and still have them be tracked in some sense. Once all automated tasks are completed, a 10 day timer starts for the completion of any tasks that are still on the service request. If they are all completed or cancelled, it will update the offering to fulfilled. If it times out, it will send the error notification out instead, telling you to check the tasks of that offering. It then stops.

               

              I would recommend you add that last block to the workflows like that if you expect ad-hoc tasks to be added and wish to track against them.

               

              In your case, you'd probably want next task blocks to only fire once the previous task has been completed, so you would daisy chain them a bit differently.