Archibus SaaS / Maintenance / Corrective Maintenance / Maintenance Console
Corrective Maintenance / Maintenance Console

Preventive Maintenance / Maintenance Console
Maintenance Mobile App

Returning Work (Supervisor)

After a work request has been issued, new information about the work request may require the work to be re-routed to an entirely different work team. As the supervisor, you have the ability to return a work request to a prior status and / or workflow step, so that supervisors on another work team can appropriately issue the work. You do this by editing the Status drop-down field in the Work Request form. This will launch another form called Return Work Request where you confirm the status change and select a workflow step, if necessary. You add Comments to clarify why you are returning the request, such as to revise the scheduling or estimating.

Note the following:

• Corrective work requests can be sent back to the Requested status only if the SLA contains workflow steps on that status. If there are no workflow steps on the Requested status, then the earliest step to which the request can be returned is the Approved status.
• You can return Preventative Maintenance requests to the Issued or Assigned to Work Order statuses only.

The Maintenance Console indicates returned work requests with a red flag so that you can easily notice them and investigate the problem. The Console also lists the comment that the user entered when returning the request.

Issuing a returned work request to a different craftsperson

If a craftsperson assignment has no hours, then you, as a supervisor, could reassign that work request to a different craftsperson after returning that work request to the Approved (A) or Assigned to Work Order (AA) status. Here is an example of the steps to reassign the work to a different craftsperson:

1. A requestor creates a work request that is Auto-Approved.
2. The supervisor assigns the request to a work order, and then schedules a craftsperson with an estimated time of two hours.
3. The supervisor issues the work request.
4. The supervisor decides that a different craftsperson should work on the problem. The craftsperson has not yet worked on the issue and has not yet entered any Regular Hours.
5. The supervisor returns the request back to the Assigned to Work Order (AA) status. See Procedure; Returning work requests to a prior status.
6. The supervisor edits the Work Request Labor Assignment (WRCF) record by changing the craftsperson assignment (cf_id), and also the Estimated Hours. See Corrective Maintenance / Maintenance Console
7. The supervisor Issues the work request again.

Note: When re-issuing work, if the work request contains Work Request Labor Assignment records that have a status of Returned, the system automatically updates the status of those records to Complete when a supervisor reissues the request.

How the system determines the workflow steps for a status

Once the work request is sent back to a prior status, it will continue from that point as usual, following the workflow of the SLA. This might mean that workflow steps are repeated, and this is acceptable. If you are given the choice of returning to a previous workflow step, the system creates a new record in the Helpdesk Step Log based on the workflow step that is selected.

When you assign a work request to a prior status, the system checks the SLA to determine if there are any workflow steps on that status.

• If workflow steps are present, the system displays the list of steps on that status, along with a choice of “None – All Steps Completed."
• The option “None – All Steps Completed” is not available if you are returning a request back to the Requested status. This is because the system will automatically advance the status of work requests for which all Requested workflow steps are completed.
• If there are no workflow steps for the chosen status, then there are no step selections available.
• When the workflow steps are completed, the supervisor can advance the work to other statuses, such as Approved or Assigned to Work Order.
• If there is a single workflow step on the Requested status, and you have selected this status, the form will default to this step selection.
• If there are no workflow steps on the Requested status, then the earliest step to which the request can be returned is the Approved status.
• You can also select a prior step on the current status. The system will determine which steps have been completed on the current status, and provide all prior steps in the Return Work Request form.
• If a dispatch step exists on the selected status, it will be included in the list of steps that you can select.

You can also choose a Rejected status, which will return the request to the requestor. The requestor could then resubmit the request and restart the workflow. Rejection is available for On-Demand only; Preventive Maintenance requests cannot be Rejected. See Rejecting Work Requests.

Notes:

• Requests that contain actual costs cannot be Cancelled, only Stopped.
• You can send a request back to the Approved (A ) status, even if the SLA is set for Auto Assign to Work Order or Auto-Issue.
  
• You can send a request back to the Assigned to Work Order (AA) status even if the SLA is set for Auto-Issue.
  
• If there is a pending workflow step at the time that the request is moved to a prior status or step, that pending workflow step will be deleted.
  

How the system documents status changes

When a supervisor returns a work request to a prior status or step, the system will add two records to the helpdesk_step_log. One record is for the return action, and the other record is for the result of that return action (the chosen status and step).

For example, suppose user GSMITH creates a request that is auto-approved and auto-assigned to a work order. Supervisor AI then issues the work request. AI then decides to return the request back to the Assigned to Work Order status (AA), so that the labor estimates can be revised. If you choose a workflow step when you return a request, that step will also be added to the step log as a pending step.

Filtering by Returned Status

Supervisors can quickly identify work requests that were returned from a craftsperson by using the “Returned? field in the Maintenance Console. When you set this field to Yes, the system searches for work requests that contain Work Request Labor Assignment (WRCF) records that have a status of Returned.

Procedure: Return a work request to a prior status (Maintenance Console)

To return a workflow step to a prior status:

1. Log on to the Maintenance Console, and expand the Issued and in Process section.
2. Select the work request, and click the Update button.

   You move to the Work Request form.

3. Click the Status list to show the list of statuses.
4. Select a prior status from the list.

   When you select a prior status, the Return Work Request form appears.

   

5. Enter Comments to describe why you are returning the work.
6. If the chosen status contains workflow steps, the pop-up window presents those step, so that you can select the step to which you want to return the request. If the SLA step was assigned to a role, the roles of the step completers is shown in the form.

   

7. Click Update Request.

Procedure: Return a work request to a prior status (Maintenance mobile app)

The ability to choose the status and step to which you are returning a work request depends on the connectivity of the mobile device. If the device has a wi-fi connection, you will be given the ability to perform a live query to get the list of statuses and steps to which you can return the request.

From the Maintenance mobile app, click the check mark to access the menu of actions, and select Return from the list.

• If the device has a connection to the server, the system automatically calls the workflow rule to get the list of statuses and steps. You must then choose the status, and also the step if there are workflow steps on that status.
• If no wi-fi connection exists, a message lets you know that the request will be automatically sent back one status or step. The workflow rule can be called when the request is later synched, and the request will be returned to the last status or step in the list.
• If the query fails, then the system will send the request back to the last status or step prior to the current status or step.

The application accounts for situations where a status change was made to a work request in Web Central after the mobile device was synched. The request can only be returned to a prior status or step if the actual status (Web Central) matches the synched status (Mobile). The workflow rule that executes the Return status returns an error message if the mobile status is out-of-sync.

 

Back to 

• Maintenance Console: Overview
• Working from the Maintenance Console or from the Maintenance Mobile App: Overview