- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-22-2026 09:19 PM
Need help with following questions: -
- Can we create "Resolved" status in Service Request Management the way we have it for Incident Management.
- If "Resolved" status is possible then can the service request be auto closed after 3 business days.
- If "Resolved" status is possible then can the service request be reopened within 3 business days.
If all of the above options are possible then will they be considered as part of "Customization" or "Configuration"
Thank you in advance.
Regards,
Shivendra Pratap Singh Jadon.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-22-2026 10:04 PM
It is feasible but NOT AT ALL recommended.
Service management concept is different than incident. Here You are not solving any issue that needs 'Resolve" request process. In service management - you are ordering something and and it is ended with fulfillment (what you order that is fulfilled)
Here full process involved in Service request :
Item Form submit-> RITM (approval) -> Fulfillment ( SCTASK).
Once fulfillment process i.e SCTASK is closed complete/closed incomplete/closed skipped -> that way Request is Closed.
So hope you got the point.
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
While I understand the distinction between Incident Management and Service Request Management, I believe there is still a valid business case for providing a mechanism to reopen or return a fulfilled request under specific circumstances.
In the service request lifecycle, the objective is indeed fulfillment rather than issue resolution. Once the SCTASK is completed (Closed Complete, Closed Incomplete, or Closed Skipped), the associated Request is automatically closed, signifying that the requested item or service has been delivered as per the fulfillment process.
However, fulfillment closure does not necessarily guarantee that the request has been delivered completely, accurately, or in accordance with the user's expectations. There may be cases where:
- The requested service or item is only partially fulfilled.
- The delivered outcome does not meet the specifications captured in the request.
- Quality issues are identified after fulfillment.
- The user discovers missing components or incorrect fulfillment only after verifying the delivery.
In such scenarios, the user should have a controlled option to raise a "return", "rework", or "reopen" request against the original service request, similar to how e-commerce platforms allow customers to return or replace delivered items if they are found to be defective, incomplete, or not as ordered.
The intent is not to convert a Service Request into an Incident or Resolution workflow, but rather to introduce a post-fulfillment validation mechanism that protects user experience and service quality. This would also maintain traceability by linking the follow-up activity to the original RITM/SCTASK instead of forcing users to create a completely new request or incident.
Therefore, while automatic closure upon fulfillment is aligned with Service Management principles, a governed "reopen/return for correction" capability could provide additional assurance that fulfillment is not only completed, but also accepted by the requester as satisfactory and complete.
