Service Applications
- Richard Potter (Unlicensed)
- Leo Guo (Unlicensed)
At a very high level, the lifecycle process for a service application is as follows:
Service dashboard
Users arrive at the service dashboard, where all of their previous service requests are listed, and can be updated, deleted, printed, etc. The ability to update their account settings, as well as view other services available to them is provided by the MTOA portal. A typical service application dashboard may look something like this:
→ To see how to retrieve a list of service requests, click here
The dashboard, at a glance, allows users to quickly check the status of their service requests, or access them for printing or updating. Details that are more specific to the business line can be stored and retrieved for display here by leveraging the service request metadata.
Create/update service request
A service request is actually comprised of 3 different components:
A service request record which holds high-level data such as the status of the request
A metadata document (known as an "artifact" which contains customizable data that is relevant to the service
A JSON document (also an artifact) which contains all of the service request data gathered from the user in each step of the application (click here for an example)
→ To see how to create a service request, click here
Submit service request
The act of submitting a service request is changing the status of the service request from "in progress" to "submitted" - meaning that the request could also be returned back to the user for modifications. In most cases, after submitting a service request, you will also want to digitally sign the submission (which is another type of artifact document), and provide the user with a feedback form allowing them to comment on their experience.
→ To see how to change the status of a service request, click here
→ To see how to digitally sign a service request, click here
→ To see how to record user feedback, click here
Examples