Skip to content
flowlakes FlowLakes documentation home

Work service requests

Request Management 1.3.0 has the same shape as Incident Management: a Home, one Requests list with tabs, a Request Tasks list, and a Configuration section. Requests usually arrive through the portal from a catalog item; this page covers the fulfiller’s side.

Since 1.40.0, the portal’s “Submit a Service Request” form asks what the request is about (an optional category), and every request now reaches a team even without one: an uncategorised request with no matching service routes to the Service Desk instead of sitting unassigned.

Goal

Open Request Management, see what is waiting on approval or on you, and work requests and their tasks.

Prerequisites

  • The Request Management application is installed.
  • One of the roles request_fulfiller, request_manager or request_admin. The Configuration section needs request_admin or request_manager. What each role grants: Roles: who sees what, who configures what.

Steps

1. Open Home

Select Request Management in the application rail. Home shows:

  • Needs attention: Awaiting approval (requests in the Pending Approval state), Awaiting your approval (approvals you can decide), Assigned to you (requests with you as the assignee, the “Assigned to me” tab), and Open team tasks.
  • Quick actions: New request and Open my queue.
  • Analytics: the Request Management Dashboard’s charts, with Open full dashboard.

2. Work the Requests list

Select Requests. The list opens on Open.

TabShows
OpenEvery request that is not closed or cancelled
Awaiting ApprovalRequests in the Pending Approval state
My RequestsRequests you raised that are not closed or cancelled
Assigned to meRequests with you as the assignee that are not closed or cancelled
AllEvery request

“My Requests” and “Assigned to me” answer different questions: My Requests is what you asked for, Assigned to me is what you need to work. The Home card “Assigned to you” opens the Assigned to me tab.

The tab counts match the Home cards. A filter you add narrows the tab you are on.

A request starts on its own: the moment its first task leaves Pending, a New request moves to In Progress and takes that task’s assignee if nobody is assigned yet. Assigning the request directly still starts it too, so a request can begin either way.

Fulfilled and Cancelled are final. A fulfilled or cancelled request cannot be moved to another state or edited. A comment meant for the requester is refused on a closed or cancelled request; write a team note instead (the requester’s own reply through their portal is the one exception, and it is how a request gets reopened). If the work turns out to be incomplete, raise a new request and link it to the first one.

A request’s priority follows the same impact x urgency matrix as incidents; the matrix is shared. Request Management installs it on its own, so a high impact, high urgency request reads Critical with or without Incident Management.

A request can also name the specific configuration item it is about, in the Caller section alongside who it is for. Picking one is optional: not every request concerns a single asset.

A request’s category (set on the portal form or on the record) routes it to the category’s team. Without a category, an offering or an affected service, the request still reaches a team: it falls back to the table’s configured default team, then the tenant’s fallback team, then the seeded Service Desk, so a request is never silently unassigned.

3. Fulfil the tasks

Select Request Tasks. It opens on All. My Tasks shows your tasks that are not done or cancelled; Team Tasks shows the open tasks of every group you are an active member of.

4. Add a task to a request

Open a request. When it already has fulfilment tasks, a checklist card in the thread lists them; select All sub-tasks on that card, or the Related link above the thread, to open the full list in a side panel. The panel lists the request’s fulfilment tasks, whether the catalog item spawned them or a person added them. Type what needs to be done in the add row, pick the team and the task type, and press Enter or Add. The task gets its own number, is linked to the request, and runs the same rules as a spawned task. A task’s header reads “Part of” with the request number, and its Parent request field opens the request too. The field is read-only and is set when the task is created. In the Request Tasks list, filter on Parent request to see one request’s tasks. Adding needs create on Request Tasks and edit on the request. A task reaching Done or Cancelled locks it the same way Fulfilled and Cancelled lock a request.

Once every task under a request is finished, whether each one reached Done or Cancelled, the request fulfils itself automatically. You cannot fulfil a request while one of its tasks is still open; the refusal names how many are open. Cancelling a request cancels its own open tasks at the same time, and leaves an already finished task exactly as it was.

5. Check the configuration

With an admin role, open Configuration. Setup is the Configuration hub for Request Management (see Configure an application). Categories holds the request categories the portal and routing use.

Verification

You know it worked when:

  • The Awaiting Approval tab count equals the Awaiting approval card on Home.
  • A request you approve leaves Awaiting your approval and Awaiting Approval.
  • Team Tasks lists the tasks of your groups only.

Troubleshooting

SymptomCauseFix
The old entries (All Requests, Pending Approval, Open Requests, Dashboard) are still in the sidebarThe tenant has not applied the 1.3.0 updateApply the update from Admin → Build → Browse Apps
A request never reaches Awaiting ApprovalIts catalog item has no approval, so it goes straight to fulfilmentAdd an approval to the catalog item or an Approval Policy on the table. See Approvals
A new request has no SLA due datesNo default SLA exists for its priority, and its offering binds noneOpen Setup and check the Service levels card (see Configure an application)