Service Request Flow
Each service request goes through the following phases when a requester raises it.
Object Selection
In the Selection Phase, requesters can select multiple or a single data object from the list and click the "Request Access" button in the top right corner if raising a request from the Access Cart.
If raising a service request from the Service Desk, requesters can select one or more objects from the list and click the "Continue" button.
Submit Service Request
Please enter the mandatory fields before submitting your request. Fill in optional fields if needed. The request remains in a draft state until it is submitted or discarded. Draft service requests are found in "My Requests" on the Service Desk page.
Grouping Logic
Service requests are created as grouped tickets to reduce repetitive data entry. For example, when raising an access request for multiple objects, users only need to fill out the request details once. A single group ticket is created, and child tickets (approval tickets) are automatically generated based on the workflow.
Grouping is based on the connection type defined in the service desk template. In most cases, a group ticket will have only one child ticket, as many templates—such as content change or new asset creation—require object-specific details and therefore do not support grouping.
By default, only access request templates support group tickets with multiple child tickets.
Service Requests Review
After submitting a request, requesters can check the summary of each ticket. Click on the request and see the summary of each ticket.
Access Requests vs Non-Access Requests
The ticket display logic has been refined during the review phase to enhance the user experience and reduce confusion when managing service requests.
Access Requests: Both group tickets and their associated child tickets are displayed. This ensures complete visibility, as access requests often involve multiple child tickets under a single group ticket.
Non-Access Requests: Only child tickets are displayed, as these include a single child per group ticket, thereby avoiding confusion.
Request ID
The ID generated for Sub tickets is called Request ID, and it is auto-generated based on the approval workflow of an object in a connection. Only Request IDs are created based on the workflow for service requests other than access requests.
Workflow
The requester can view the approval workflow in the request summary. Clicking on the number of approvers shows a list of their names in the workflow.
After entering all the details for each request, the requester can click the "Done" button to go to the next page, where they can review all tickets and their summaries.
Once they have checked the details, they can click the "Finish" button, which will take the requesters to the "My Requests" tab on the Service Desk page.
Service Requests Approval
When requesters click on the Service Request ID in the Waiting for My Approval > Service Desk, they are redirected to the request summary page. Here, the tickets that need approval or rejection can be seen. Approvers decide whether to approve or reject the request during the approval phase by providing optional comments.
Refer Back
If the current approver finds that the previous approvers did not review specific request details or if changes are needed, they can send the request back with a comment.
Refer Back to Requester
Approvers can now send requests back to requesters for additional information, enabling a more collaborative process by allowing requesters to update and resubmit incomplete or incorrect requests.
Supersede
The System Admin supersedes service requests for other users unless approval is required for an external integration. The supersede function is enabled or disabled through System Settings.
Forward To
A new ‘Forward To’ option is now available when raising a service request, offering greater flexibility in the approval workflow. The ‘Forward To’ feature enables the current approver to either:
Forward the request directly to a later-stage approver, bypassing intermediate approvers.
Fulfill the request immediately without routing it further through the predefined approval levels.
Nudge
The Nudge feature is a reminder system for approvers to send notifications based on the settings configured in System Settings (nudging.cool.off.period). By default, Nudge is set to a particular time period in System Settings.
The requestor and OE_Admin users can click the Nudge button to send notifications to the approvers via email and In-App alerts. After approval, the Nudge button will be disabled at that level. It will be reactivated for the next stage of the service request, ensuring timely reminders and efficient management through all approval stages until the request is fully processed.
How does Nudge Work?
Go to Administration > System Settings > Service Desk tab.
Find the Key name ‘nudging.cool.off.period’.
Enter the number of hours in the Value column.
Now go to Service Desk > My Requests. Select the ticket that is under ‘Awaiting Approval’ status. Click the Request ID/Summary.
Now, the Nudge button is enabled, as shown below. Note: Users can view the duration for which the ticket has been pending approval here.
Once the requestor or users with the OE_ADMIN role click on Nudge, a success message pops up, and the approver or team is reminded via email and In-App alerts to approve the request. Note: If the approver has not yet approved the request, the Nudge will be enabled as configured in the System Settings for ‘nudge cool off period.’
Reminder E-mail looks like this:
By clicking on the service request, the approver can then approve the request.
After approval is completed, the Nudge button reactivates for the next stage of the service request until the request is fully processed.
Approval History
The Approval Flow displays the list of Approvers for the particular service request. The predefined order within the workflow determines the sequence of approvers.
Requesters and approvers can view the approval workflow in the approval history by clicking the icon next to the Approval Flow.
Requester or Approvers can see the comments provided by approvers at each level.
Edit Service Requests
Requesters and approvers edit the service request during the approval phase. Depending on the template's configuration, some fields can be edited. Editable fields have a gray background when the user hovers over the request.
Clone a Request
Those who can view the service request can choose to clone it, creating a new ticket with the same information from the Creation phase. Requesters can clone a ticket at any level(Group level or Sub-request level). They can then make changes as needed and submit a new request. Cloning requests are possible even after a request is marked as closed. They can see the Clone ID from which the service request has been cloned.
Withdraw a Request
The requester can withdraw a request by providing a reason for withdrawal before it is approved/rejected by the first approver. Requesters can withdraw a ticket at the group level or sub-request level.
Service Request Fulfillment
Once the Service Request is approved or rejected by all the approvers in the workflow, the fulfillment of the request begins. Fulfillment occurs at various levels, depending on,
Automatic Fulfillment: In cases of automatic fulfillment, the status of fulfillment changes based on job logs. The approver can also manually adjust the fulfillment status.
Template level: If a request is set for automatic fulfillment at the template level, fulfillment happens automatically after all approvals, and the current status is shown in the Fulfillment phase.
Approval level: The process begins when the relevant approver grants approval for requests with automatic fulfillment at the approval level. The fulfillment status is visible only during the Fulfillment phase. If the fulfillment job succeeds, we will implement the requested changes.
Manual fulfillment: The approver(s) manually change the fulfillment status for requests with manual fulfillment.
Approves Manually: The approver(s) manually carry out the requested changes for requests set for manual fulfillment.
There are different fulfillment statuses as follows:
Resolved
Fulfillment failed
Fulfillment In Progress
Fulfillment successful
Partially fulfilled.
Once fulfillment is successful, the requester can officially close the ticket.
Fulfillment Instructions
Admins can define fulfillment instructions for service requests at the service desk template level. By default, instructions indicate whether the request will be fulfilled automatically or requires manual action by approvers. If no fulfillment instruction is necessary, the field can be left blank in the template, and no instruction will appear in the service request.
Fulfillment Remarks
Fulfillment Remarks are optional comments or notes added by the requester or user who completes or fulfills a service request. They help maintain transparency and support auditing. The latest comment or remark is captured in the “Latest Comment/Remark in the Service Desk Table view.
Service Request Rejection
Whenever the ticket is rejected, requesters can see the comments provided by the approvers and raise a new request if necessary, or they can reopen the ticket.
Reopen Service Requests
The requester can reopen a ticket if it is rejected by the approver or if fulfillment fails. Reopening can be done at either the parent or child ticket level by clicking the Reopen option. Once reopened, the fields become editable, allowing the requester to make necessary changes and resubmit the request.
Copyright © 2025, OvalEdge LLC, Peachtree Corners, GA, USA.
Last updated
Was this helpful?