Overview of service requests in the Cloud API
Service request APIs and vendor portals
In previous releases of ClaimCenter, service requests were primarily managed by two systems: ClaimCenter and a vendor portal. The vendor portal is an application used by a vendor to manage information about service requests from ClaimCenter. In this paradigm:
ClaimCenter is responsible for actions such as:
- Creating the service request
- Submitting the service request to the vendor
- Paying the vendor.
The vendor is responsible for actions such as:
- Accepting the service request
- Quoting the service request
- Submitting invoices for the service request
Cloud API provides a wider range of options for processing service requests. The service request APIs can be used by a vendor portal. But they can also be used by:
- An alternate front-end application for adjusters who specialize in service requests
- A service that submits or pays for vendor invoices in bulk
- A vendor management system that manages service requests for multiple vendors
Thus, the service request functionality exposed by Cloud API is not limited to only the functionality that would be used by vendor portals. Rather, it exposes the service request functionality needed to manage the entire service request process.
Lifecycle management
Cloud API provides a number of endpoints to manage the lifecycle of a service request. This includes both endpoints for actions taken by the insurer (such as submitting a service request) and endpoints for actions taken by the vendor (such as accepting a service request).
As of this release, there are endpoints to advance a service request to most stages in the lifecycle. However, there are currently no endpoints to move a service request to the "Vendor Waiting" status.
Required service request data model
ClaimCenter includes two service requests data models: the "legacy model" and the Core Service Request data model. Each instance of ClaimCenter can use only one of these models. In the base configuration, the Core Service Request data model is enabled by default. In general, Guidewire recommends insurers use the Core Service Request data model.
Service request numbers
In addition to a public ID, every service request is assigned a
"service request number". By default, this number is included in the response payload for most
service request actions (in the serviceRequestNumber field). Unlike public
IDs, service request numbers are shown in the user interface. During testing, you can use the
service request number to match a service request as seen in a system API response with the
corresponding service request in the user interface.
Support for each service request kind
If an insurer wants to go into production with this release and requires the ability to create quotes or pay invoices through an integration point, then the insurer must write their own integration points. For more information on service request functionality that may be available in future release, check with your Guidewire account manager or your project manager.
Quote Only and Quote and Service service requests
The following table lists the stages that a Quote Only or Quote and Service service request can advance to through the system APIs. It identifies which system API action advances the service request to the next stage, and the value of the service's Next Action column in the ClaimCenter Services list.
| System API endpoint | Moves Progress to... | Services list's Next Action is... |
|---|---|---|
POST /service-requests |
Draft | "Submit request" |
POST /{serviceRequestId}/submit |
Requested | "Agree to provide quote" |
POST /{serviceRequestId}/accept |
In Progress | "Add quote" |
As of this release, there are no endpoints to create quotes or pay invoices. However, users can create quotes, pay invoices, and take other actions that advance the service request to completion, through the user interface.
Service Only service requests
The following table lists the stages that a Service Only service request can advance to through the system APIs. It identifies which system API action advances the service request to the next stage, and the value of the service's Next Action column in the ClaimCenter Services list.
| System API endpoint | Moves Progress to... | Services list's Next Action is... |
|---|---|---|
POST /service-requests |
Draft | "Submit request" |
POST /{serviceRequestId}/submit |
Requested | "Agree to perform service" |
POST /{serviceRequestId}/accept |
In Progress | "Finish the work" |
POST /{serviceRequestId}/complete-work |
Work Complete | "Add invoice" |
POST /{serviceRequestId}/invoices |
Work Complete | "Pay invoice" |
As of this release, there are no endpoints to pay invoices. However, invoices can be paid through the user interface.
Unmanaged service requests
The following table lists the stages that an Unmanaged service request can advance to through the system APIs. It identifies which system API action advances the service request to the next stage, and the value of the service's Next Action column in the ClaimCenter Services list.
| System API endpoint | Moves Progress to... | Services list's Next Action is... |
|---|---|---|
POST /service-requests |
Work Complete | "Add invoice" |
POST /{serviceRequestId}/invoices |
Work Complete | "Pay invoice" |
As of this release, there are no endpoints to pay invoices. Unmanaged service requests are expected to make use of straight-through invoice processing to automatically approve and pay invoices. However, if required, invoices can be paid through the user interface.
Composite request limitations with service requests
For service requests that are Quote Only, Quote and Service, or Service Only, you can create and submit a service request in a single composite request. But you cannot advance these types of service requests to any other stage in its life cycle (such as in progress, declined, or canceled at vendor or insurer request) in the same composite request.