7 Replies Latest reply on Jul 11, 2018 5:39 PM by srowley1

    Service request workflow, optional paths

    wynnb Apprentice

      Wondering if it is possible to configure a Request workflow to handle optional paths based on the result of a task. For example, in Incident, the last task completed prompts the user for options (resolve or create another task), and if they choose to resolve, it prompts for cause and resolution. That is handled in a business rule; I need to do something similar in a workflow.

       

      In my case I need to build a 'request for change' SR where the first step is for a team to review/evaluate the request and determine one of three next steps: 1. deny/cancel, 2. send to another team for additional analysis, or 3. send to an approval board for prioritization.

       

      I can build workflows for each of those options, but the trick is in how to handle more than two optional outputs. An Approval gives me only two options. I really need a prompt, but we can't use Prompts in workflow...

       

      Could I use a rule for the task that prompts to update a field value, then use an "if" block to direct the next block in the workflow? Not sure if there would be timing issues with that.

        • 1. Re: Service request workflow, optional paths
          srowley1 Rookie

          I recently built a request offering with a workflow that has optional paths. 

           

          I used tasks to pause the workflow and compound quick actions to let the user interact with the service request. 

           

          The quick actions allowed me to prompt the user for information and update the service request. 

           

          Some of the quick actions were configured to find the outstanding task and "completed" or "cancelled" it.  This allowed the work flow to progress.

           

          I put all the quick actions on an action menu to make it easier for the user to work with.

          • 2. Re: Service request workflow, optional paths
            BKallweit Apprentice

            Hi Bryan,

             

            to implement optional path in your workflow and have the workflow continue after one of the options have run, you can use a Join workflow block. Please observe carefully the online help about this; it is a bit tricky.

            See Join Workflow Block

             

             

            Bernd

            • 3. Re: Service request workflow, optional paths
              wynnb Apprentice

              Using this method, were you able to direct the workflow to continue down different paths?

               

              I think I'm basically looking for a way for the support user to choose one of several workflow paths - after the main workflow has started. I know we can call a workflow from within a workflow, and we can split the path, i.e. from an If block, but how can I let the user determine the path?

               

              My understanding is that if we update anything in the request record, the workflow has already started so it can't reevaluate to determine a new answer to an If statement - or can it?

              • 4. Re: Service request workflow, optional paths
                wynnb Apprentice

                Thanks Bernd, but I think that's the opposite of what I'm trying to do. I've used the Join block before, but that's to join different paths into one - I'm looking to split one path into multiple optional paths.

                • 5. Re: Service request workflow, optional paths
                  wynnb Apprentice

                  Well, I may have figured out a solution for this - at least for my specific scenario. Basically, I did the following:

                  - Created Boolean fields in ServiceReq related to the questions I wanted the task assignees to answer.

                  - Created quick actions to set those fields to true or false.

                  - Created Boolean fields in Task.Assignment for the specific workflow steps where I wanted to prompt for answers.

                  - Created business rules that trigger when the specific tasks are marked complete (not sure this is the best way - don't know how to handle it if someone changes the summary of the task...). The rules use the fields I created in Task, and run a PromptAndExecuteAction command to prompt the user for what to do next. The actions are executed in the ServiceReq object.

                   

                  I had two steps in my workflow that needed these prompts. The first one was easy, because it was a simple Yes/No question (PromptAndExecuteAction only works with yes/no questions). The second step was more complicated, because I needed answers to three questions, and one of those had to override the other two. In other words, A and/or B can be true, but if C is true A and B must be false. I managed to make this work by using a Composite Action with three Update actions, putting the C question last, and configuring its 'yes' action to set all three fields (C = true, A and B = false). It appears that the Composite runs these in order, so if a user does answer yes to all three, the end result is only C will be true. Seems messy, but there are limitations to the system.

                   

                  By adding these triggered rules, I can set those fields in the Request object as soon as a task is complete, then use an If block in the RO workflow to check the value of the Boolean field. So far, timing hasn't been an issue, but I could add a wait block if it is. So now I can create a task, when it is completed the user is prompted, and their answer sets a flag that the workflow can use to determine the next path.

                  • 6. Re: Service request workflow, optional paths
                    JenBouillion Apprentice

                    srowley1,

                      I would like to see how you did this, if you wouldn't mind sharing. 

                    • 7. Re: Service request workflow, optional paths
                      srowley1 Rookie

                      JenBouillion wrote:

                       

                      srowley1,

                      I would like to see how you did this, if you wouldn't mind sharing.

                      > I recently built a request offering with a workflow that has optional paths.

                      > I used tasks to pause the workflow and compound quick actions to let the user interact with the service request.

                      > The quick actions allowed me to prompt the user for information and update the service request.

                      > Some of the quick actions were configured to find the outstanding task and "completed" or "cancelled" it.  This allowed the work flow to progress.

                      > I put all the quick actions on an action menu to make it easier for the user to work with.

                       

                      Workflow

                      Vendor Workflow.png

                      Essentially the tasks are being used to pause the workflow.  I've removed a lot of the emailing and update steps to highlight the relevant bits.

                      I have update statements in the workflow to save the state of the request, so it can be used in a dashboard, to allow users to easily work with requests in progress.

                       

                      Quick Actions - User chooses path by selecting a QA to run.

                      (I used the disable feature of the Quick Actions to enable on the appropriate QAs based on the saved state)

                      Vendor Quick Actions.png

                       

                      I chose composite quick actions so it could prompt for info to save on the service request, then complete or cancel the task (to move the workflow forward).

                      User will select 1 or 1a.

                      Vendor QA1.png

                      OR

                       

                      Vendor QA1a.png

                      On the Task#Assignment object I created two QA actions to Complete/Cancel the tasks which are executed by the composite actions.

                      Vendor Task QAs.png

                      A side issue I had to deal with was assigning the task to someone before I could complete it.

                       

                      Seems to be working how I expected in production now.

                       

                      It occurred to me that I could bypass all this and do without the workflow but I would have to place the email and state updates in the composite quick actions. 

                      That makes it harder to understand what's going on so I persisted with the above approach.

                       

                      Hope that makes sense!

                       

                      Regards

                      Steve