Queue is the Kapp, Kinetic Application, that serves as a the fulfillment portion of Service Portal. It is the home of approvals and other fulfillment tasks for requested Services.
So if Queue is used for approvals and other fulfillment tasks, how are they differentiated? Approvals have specific approval questions and logic is really the only difference. Approvals can be assigned to an individual or a team, as with any task. However, approval will ask a question about whether the request (or part of the request) is approved, will prompt for a reason (required if rejected), and will stop the workflow from proceeding and notify the user of the denial (in the case of the preconfigured approval).
Tasks and approvals need to be able to review the details of the request that created them. This is available preconfigured in queue.
Queue also allows users to create tasks as needed. This can be new tasks not related to a request or tasks associated to existing approval or fulfillment item.
New tasks not related to requests allow fulfillers to track internal work they do (eg. billing activities) that they may want to track but aren't related to a request. This also gives fulfillers an opportunity to capture work done for walk-ups, which is often work that ends up going un-tracked. Quick and easy new task functionality provides an opportunity to both track work that could otherwise be missed and to keep all work in the same system.
Allowing fulfillers and approvers to create additional tasks associated with their tasks allows for incredible flexibility. For example, perhaps a fulfiller fills a request for a new whiteboard for a teacher, but it is the last one in stock. They can, from their task, create a separate task to order more inventory. This allows them to close their task (and for the request to proceed), but the necessary next steps to still occur.
Another example is the unknown process. Many companies can spend months if not years trying to accurately document all the steps in their most complex processes, like on-boarding. An alternative way to go about this is a general understanding of the process (eg. where the process starts or who does 'most of the work') and ad hoc tasks. Service Portal allows fulfillers to send tasks out as necessary to other teams or even to create other tasks for their own team if desired. This allows Service Portal to be used to document processes on the go. After three to six months, the existing submissions can be reviewed and the consistent ad hoc tasks that were created can be automated, saving that time and effort of creating those moving forward. This process can continue, ever making the processes more efficient and more effective.
Subtasks are a way to create ad-hoc tasks that are directly associated to and visible from your original task. There are two preconfigured subtasks available, but new ones can be built as desired. The provided subtasks are really meant to be models and starting places for more detailed and specific subtasks desired by your company. The preconfigured subtasks are as follows:
- Ad hoc approval: Do you need approval from someone before you complete your task? Perhaps your task requires a purchase; or perhaps you need to assign one of a limited set of licenses to someone. Simply create an ad hoc approval to keep official track of that approval and keep everything in the same system.
- Ad hoc task: Do you need someone else to do something because of your task? Perhaps you are using the last item out of inventory and someone in purchasing will need to get more. Perhaps you can't do your task until someone else completes an additional task, such as an office cannot have a desk until it has been assigned. This keeps all the work in one place.
Updated about 1 year ago