Forwarding routes the issue to another service request category and creates a new service request. Transferring to a task creates a task linked to the original request. Choose forwarding when the issue belongs to another category, and transfer to a task when handling the request requires separate work.
Before you start
Open the Service requests view in the browser and open the request you want to handle. Check its title, description, Spot and existing linked tasks. The browser's Forward and Transfer to task tabs are available with edit permissions when the request is Open, In progress or On hold. These actions are not used for completed, cancelled or forwarded requests.
Forwarding also requires forwarding permissions. Transferring to a task requires permission to create a task for the selected Spot and responsible party. Viewing, commenting or completion permissions alone are not sufficient. See service request visibility and handling permissions.
Forward a request in the browser
- Open the request's Forward tab and select the receiving service request category.
- After selecting the category, check the required additional fields and the fields that do not belong to the receiving category. Fill in any missing required information.
- Select Forward. If the receiving category requires a Spot and the request does not have one, select a Spot in the selection dialog that opens.
- If a request that is in progress is forwarded to a category with no default responsible workers, confirm the notice that the request will become open.
- Find the new request and check its category, Spot, responsible workers, status, additional fields and attachments.
What does forwarding preserve and change?
Forwarding creates a new request linked to the original. The original is retained with the status Forwarded, and a comment identifying the person who forwarded it is added. This does not change the original request's category or delete the request.
Basic information, such as the title, description and contact details, is copied to the new request, along with attachments and comments. Comment authors and original timestamps are preserved. Only additional fields that belong to the receiving category are copied; required information entered during forwarding is added to them. Other additional information remains in the original request.
The new request's responsible workers are determined by the receiving category's default. If default responsible workers are set, the new request is In progress; otherwise, it is Open. The original request's On hold status and its reason are not transferred to the new request.
Tasks, time entries, product lines, travel allowances and other separate work entries linked to the original are not transferred with the copy. Check any unfinished work on the original request separately before forwarding.
The communication link may move to the new request
If an external conversation has no replies yet, its communication link moves to the new request. The link previously received by the recipient then opens the new request's conversation, and the original conversation's link is deactivated.
If the conversation already has replies, it remains with the original request and is not transferred to the copy. If necessary, start a new conversation on the new request's Communication tab. Forwarding itself does not send an email to an external recipient. See comments and external communication.
Forwarding on Android and iOS
The verified mobile use case is a request that is in progress, that you are allowed to view, and whose responsible worker role you belong to. In the service request details, open Service request actions and select the receiving category in Forward Service request. The confirmation button is Forward Service request on Android and APPLY on iOS. If necessary, confirm the notice that the new request will become open.
Mobile forwarding sends only the receiving category selection. It does not provide the browser forwarding options for selecting a missing Spot and filling in the new category's required additional fields. Use the browser if this information is missing, and check the new request's additional fields after mobile forwarding as well.
For Open and On hold requests, Service request actions opens a different view for taking the request into progress. The action being visible, or having permission to edit an On hold request, does not guarantee that forwarding will succeed: mobile permissions contain an inconsistency because the definition of forwarding permissions and the acceptance of forwarding use different role conditions. The server requires you to belong to the specific responsible worker role assigned to the request. If forwarding is blocked, check the responsible workers and, if necessary, use the browser with forwarding permissions.
Transfer a request to a task in the browser
Open the request's Transfer to task tab. Under Details of the task to be created, the Spot comes from the request, the name from its title and the description from its description. The due date defaults to today, so always check it.
- Check or select the Spot and the work's Name and description.
- If necessary, select a Task template or Task form. Check the details after selecting a template.
- Select the task's responsible party and due date. Check resourcing and Estimated working time if necessary.
- Read the effects listed under Changes to this service request. Select the request's responsible workers as well if necessary.
- Confirm with the Transfer to task button.
Task template, working time and draft
Selecting a task template replaces the task's name and description with the template's details and selects the template's task form. You cannot change the form while a template is selected. If the template has planned working time, it fills in and locks the estimated working time fields. If no time is set, you can enter your own estimate. Check the name and description again when changing or removing the template selection.
Estimated working time is the planned duration of the work in hours and minutes. Resourced hours is the sum of the durations of all resourcing rows. It represents allocated person-hours, rather than the task's actual time entries or necessarily the elapsed duration of the work. For example, allocating the same two-hour period to two people produces a total of four resourced hours. Resourcing row durations are calculated from their start and end times in whole minutes; any remaining seconds are discarded.
If the Spot, due date or responsible party is missing, the application suggests creating the task as a draft. A name is still required. Accept the suggestion if planning will continue later, or cancel the confirmation and fill in the details. The draft remains in the planning status and is not completed work. However, creating a draft can also complete the service request immediately, depending on the setting described below. See creating a task or draft.
What does transferring to a task do to the service request?
The effect is determined by the service request category's After transferring to tasks setting. Changes to this service request on the transfer form shows how that category behaves; the setting is not a task-specific choice on this form.
- Mark the service request as complete immediately: the request is completed after the task is created, even if the task is only a draft or the work has not been done. If the request has no responsible workers, select them separately or select Mark the service request as complete without a responsible. The task's responsible party and the request's responsible workers are separate selections.
- Mark the service request complete when all tasks have been marked complete: creating the task does not yet complete the request. The condition applies to all linked tasks, including those created earlier. Unfinished, cancelled and planning tasks prevent completion. Tasks under review count only if the service-wide setting counts them as completed. The automatic check runs when a task becomes completed; moving a task to review alone does not trigger it.
- Do not do anything. The service request will later be marked as completed manually: the task is created and linked to the request, but the request's status, Spot and responsible workers are not changed, and no transfer comment is added.
With the first two options, a missing Spot on the request is filled in using the task's Spot, and a comment about the task's creation is added to the request. An existing Spot is not replaced with the task's Spot. With the Do not do anything setting, the request's missing Spot is not filled in, even if the form displays a general notice about assigning a Spot.
The browser transfer action copies the request's attachments to the task with all three settings. The original attachments remain on the request. This action does not copy comments, additional fields or the request's work and product entries into the corresponding task information.
Automatic completion bypasses the request's signature requirement. However, it does not bypass all other conditions for saving, such as required additional fields. Make sure the request has sufficient information beforehand. Completion also triggers the request's own normal completion processing: ongoing time entries are ended, costs are generated from entries according to the applicable conditions, and eligible stock product lines are processed according to the stock usage rules. Notifications may also be sent according to the settings. These effects apply to the request even if the linked task remains unfinished.
Add a linked task on mobile
On Android and iOS, the add button in the service request's Tasks section opens the standard task creation view. On Android, the button is next to the Add text. The service request link and its Spot, if set, are passed to task creation. Select or check the Spot and fill in the task details.
Adding a task on mobile does not perform the immediate request update, add the transfer comment or copy attachments as the browser's Transfer to task action does. Do not expect the request to be completed immediately or its missing Spot to be filled in this way. Later completion of the linked task may still trigger automatic completion that waits for all tasks.
Check the result
Open the original request's Tasks tab and make sure the work is linked to the correct request. Open the task and check its Spot, responsible party, due date, status and attachments. Also check the request's status and any transfer comment. After forwarding, check both the new request and the original request's Forwarded status.
In the browser, the task is created first and the service request is updated separately afterwards. If the request update fails, the task may still have been saved. Check the request's tasks and the details of the work created before trying again, so that you do not create the same work twice.
If you want to schedule work created from a request in the calendar, see creating a task from a service request in Work management.