Workflow

When a Change Request is created it is assigned a Workflow that governs the life-cycle of the Change Request. The SLA allocated to the RFC determines the Workflow options made available for the Change Request. Before saving the RFC, the User can adjust the system assigned Workflow, if more than one Workflow option is available.

 

After the Workflow is assigned to the Change Request, all stages of the assigned Workflow can be viewed by selecting workflow-view.png. The Workflow map displays the entry points (blue boxes), transitional States (orange boxes) and exit points (red boxes).

 

The User moves the Request through the Workflow Lifecycle by adjusting the options displayed in the  Next Action field.

 

Moving through the Workflow

To move a Change Request through the stages of the Workflow, in the Summary tab of the Change Request Information screen:

  1. Click Edit
    The Next Action field with a drop down list of Status options is displayed below the Status field.

  2. Click on the Next Action field
    The Status options are displayed. This list is based on the configuration of the assigned Workflow.

    status_update_rfc.png

  3. Select a State

  4. Click Save.
    The selected Status is assigned to the Change Request with the updated logic applied (i.e., The SLA Timers may now be active or inactive based on the newly assigned State configuration or an alternative Work or Manager Group may have been assigned to the Request. See: Status.)

 

Approval State

Approval States in Change Request Workflows provide the facility to approve or reject Request activity to Manager Groups that have been assigned to the Approval State. When a Request moves into an Approval State, the Edit button is only visible to Manager Users within the Manager Group that is assigned to that stage of the Workflow. Users who are not Managers within the Team, can send Managers a reminder to action the Request, by selecting  sent_icon.gif.

rfc_send_reminder.png

 

Managers who are assigned a Request for approval can approve.png (approve) or  reject.png (reject) the Request, which automatically moves the Request to the next pre-configured stage of the Workflow. Requests assigned a Customer or Line Manager Approval State can be processed via the Customer Portal or email.

rfc_workflow_approval.png

 

Assigning a State with an Underpinning Contract

Each state of a Workflow can be customized for either internal support contract management that is monitored by an OLA, or out-sourced to an external support provider, which is monitored by an Underpinning Contract.

 

When a Request moves into a State that is governed by an Underpinning Contract, for internal contract control the Request can be assigned to the Service Level Manager, if configured in the Workflow. This allows the Manager to maintain control of the RFC, and to easily follow up with the external service provider, if required. The assigned SLM will be able to adjust the current Status, add Notes and udpate the Contract Monitor information in the Impact tab.

sr_outsourced.png

Alternatively, the Workflow State can be configured for the Technician assigned at the time the Request is moved to the Underpinning Contract State to maintain Request editing privileges and manage adherence to the assigned service agreement. If the Workflow is configured for the responsibility of the Request to be maintained by the Technician when the Request is in an external contract state the Technician will be able to adjust the current Status, add Notes and, if the Technician is assigned the Internal Process of Service Level Management amend the Contract Monitor information in the Impact tab.

 

OLA Status Due

Within the Summary screen, the Status Due field is visible when a Workflow status is monitored by an OLA. The time, date and percentage remaining information displayed is calculated using the OLA's Target Resolution time.

rfc_statusdue.png

 

Team Assignment during the Workflow Lifecycle

To ensure that all Change Requests are managed throughout the Workflow, the Team assigned to the RFC when it is first logged within the system is set as the default Team. If a Request moves to a State that has an OLA assigned with a Team, the RFC is re-assigned to that OLA's Team. When the RFC moves out of the OLA State to a State where no OLA or Team is assigned, the RFC is re-assigned to the default Team.

 

Pending - No Contract Status

When the Contracts or Invoices functionality is enabled and a request is created, the system will verify the service entitlement status of the Customer and if a valid contract is not in place, the new RFC is assigned a Status of Pending-No Contract and locked until a valid contract is associated with the RFC.

 

In a Request Group where the Customer and Organizational Unit does not have a Contract, if an Item applied to an RFC has a Contract and another does not, a relevant Status will be applied to each request. The User will be able to edit the RFC with a valid Contract, but the RFC without a Contract will be locked down to a Pending - No Contract Status, until a valid Contract is applied to the RFC.

pending_contract.png

 

The Customer is automatically sent the NoContractCreateRequestSummary email when the Request is saved with the Status. A reminder email can be sent by the Technician from within the Summary tab by clicking sent_icon.gif, when the RFC maintains this Workflow Status assignment. See: Contracts