IT Service Request Workflow

Why should we automate IT service requests instead of handling them through email or spreadsheets?

Manual intake through email or spreadsheets makes it hard to track status, urgency and approvals consistently across requests. This workflow creates a record with a reference number and status for every request, so IT staff and requesters can see progress without chasing updates. Automated routing by category and urgency also reduces the manual sorting work typically done by a service desk lead.

What is the value of the manager approval step for Hardware and Software requests?

Routing Hardware and Software requests to manager approval before fulfilment gives departments a checkpoint on spend or resource use for these categories, while other request types move straight to fulfilment without added delay. The approval or rejection outcome is recorded on the request, and rejected requests trigger an automatic notification to the requester. This keeps the decision visible in the record's timeline rather than buried in email threads.

How does urgency-based fulfilment work, and can the due dates be changed?

The workflow routes each approved or direct-to-fulfilment request to a fulfilment task with a due date matching its urgency: 1 day for High, 3 days for Medium, and 5 days for Low. These due dates and routing rules can be adjusted by describing the change in plain English or editing the steps in the workflow editor, and earlier versions of the workflow are kept. This makes it possible to tune response-time expectations without a development project.

What happens if the requester says their issue isn't resolved?

When a requester marks their confirmation as Not Resolved, the workflow routes the request back to the urgency-based fulfilment step so IT can make another attempt, up to three times. Each attempt records Work Done and Resolution Notes on the record, and the requester is asked to confirm again once the work is redone. This rework loop keeps unresolved issues moving instead of leaving them in an unclear state.

Who is involved in processing an IT service request, and what do they do?

The requester submits the initial request form and later responds to a confirmation form asking whether the issue is resolved. A manager is asked to approve or reject Hardware and Software requests, and IT team members complete the fulfilment task, entering Work Done and Resolution Notes. All of these interactions are tracked as tasks and statuses on the request record.

Can the request form or workflow be customised for our department's needs?

Yes. The template is ready to use as published, and a workspace can adjust the workflow by describing the change in plain English or editing steps directly in the workflow editor. This includes changing routing rules, urgency due dates, or the fields captured on the fulfilment or confirmation tasks, with earlier versions retained.

How does the platform notify requesters throughout the process?

Requesters receive an acknowledgement email with their reference number when the request is created, a rejection notice if a manager declines the request, a confirmation email with resolution notes once fulfilment is complete, and a closure email when the request is finally closed. Email is built in, and a workspace can optionally send through its own AWS SES account for these messages.

What information is kept on the request record versus with an individual task?

Because the workflow waits for the fulfilment task and the confirmation form, the Work Done, Resolution Notes, and the requester's Resolved/Not Resolved response with comments are all saved directly on the request record. This means anyone reviewing the record's timeline can see the full history of what was done and how the requester responded, without needing to open individual tasks.

How are statuses used to track a request from submission to closure?

Each request record moves through statuses including New Request, Pending Manager Approval, In Progress, Awaiting Confirmation, and finally Rejected or Closed, depending on the path it takes. These statuses are visible in table views and dashboards, making it straightforward to see how many requests are open, awaiting approval, or awaiting confirmation at any time. For any compliance or record-keeping requirements tied to IT requests, each business should confirm its own obligations.