Exercise 2 - Define the Business Application Access / Support service fulfilment workflow

1. The next part of the implementation is to create the fulfillment for the service. 
   
   
   
   
   
2. After you select the Edit Workflow button the following page will be displayed.
   
   

On this page we can either select an existing Process workflow definition or create a new one. In our example we will create a new Process workflow.

For this use case, the following items need to be determined:

1. 
   
   1. The back-office fulfillment method that will be used to deliver the service. For example, a Work Order or an Incident.
   2. The fields needed to create either the Work Order or Incident. Note, that these are the required fields on the respective Work Order and Incident forms in Remedy IT Service Management or Remedy with Smart IT.
   3. The information needed from the end user so that we can fulfill their request. This translates to the questions we will ask the requester. The information from these questions will be used to complete most or all the required fields on the previously mentioned forms.

In our example we will either create a Work Order or an Incident depending on the user's request.

1. 1. Create a Work Order Before we create a Work Order to fulfil the service request, we will require the requester's manager approval. The approval will be needed in order to authorize the requester to have access to the selected business application. The following information will be gathered from the requester:

   1. • The application that the requester needs access to
      • The justification why the requester needs access to the business application
      • The urgency for access to the business application

   1. Create an Incident We will create an Incident if the user is trying to file an issue with the selected business application (i.e. they already have access to the application or feature). The following information will be gathered from the requester:

   • 
     
     • The application and/or feature that the requester is having an issue with
     • The description of the issue
     • The impact and urgency for the resolution of the issue

3. With the use case fulfillment information above, we can now design the process workflow with the following input process variables:

• Nature of the request – will be used to determine if a Work Order or Incident will be used for service fulfillment
• Application Type – will be used to capture the business application type or any other specific application
• Application Item – will be used to capture the specific application in the case where the application type was not a specific business application OR it will be used to capture a specific feature of an application where the application type was a specific application
• Justification – this variable will be used to either capture the reason why the requester needs access to the specified business application, to create a Work Order, or it will be used to capture the description of the issue, to create an Incident
• Impact – used to capture the Impact value for the Incident (note that this is a required field to create an Incident)
• Urgency – used to capture the Urgency value for the Incident (note that this is a required field to create an Incident)
• Incident Type – used to capture Incident Type value for the Incident (note that this is a required field to create an Incident)

In addition to the input variables above we also need to create the following variables:

• Context - this input process variable is used to bring in the Service Broker context (i.e. includes information about the Request By and Requested For User, the Service, etc.)
• Work Status – this output process variable is used to pass the status of either the Work Order or Incident record back to the Process workflow. This is needed for the Receive Task activity

For more detailed information regarding creating process workflow for service fulfillment please refer to the following doc link: Workflows for service fulfillment.
Our completed Process flow will look as follows:

The following is a list of activities and gateways used in this process:

1. Gateway – The process starts with a gateway to determine the nature of the request. Here we use the Nature of the Request input variable to determine this. The flow will either be to create a Work Order (if the Nature of the Request = 1, which equated to a Work Order for this flow) or to create an Incident (if the Nature of the Request = 0).

2. Approval Process – If the Nature of the Request is to create a Work Order, the next step is to obtain the Requester's Manager approval. For more detailed information regarding creating an Approval Process, refer to the following doc link: Workflow to request approval

3. Gateway –This gateway evaluates the results of the Approval Process. If the request is approved, we proceed to step 4 otherwise the process ends at step 8.

4. Create Work Order – After the request has been approved, the process will create a Work Order to give the requester access to the selected business application. For detailed information regarding creating a Work Order from a process, refer to the following doc link: Remedy connector. More specifically refer to the Work Order section in the "Workflow actions available through the Remedy connector" section in the above link.

5. Work Order Receive Task – This activity is used to suspend the process until we receive status updates from the Work Order.

6. Create Incident – If the Nature of the Request is to create an Incident, then the process will create an Incident in order to resolve the requester's issue regarding a specific business application. For detailed information regarding creating an Incident from a process, refer to the following doc link: Remedy connector. More specifically refer to the Incident section in the "Workflow actions available through the Remedy connector" section in the above link.

7. Incident Receive Task – this activity is used to suspend the process until we receive status updates from the Incident.
8. Process End – This is the end of the process flow.