Service Requests

Managing user provided information in the context of a "service request".

The business context of the application was a consumer portal, where individuals could apply for certain services from a public authority. For example, "replace my stolen passport", or "renew my driving license" or "register my newborn child" etc.

Such a request for a service (also known as a Service Request) had a certain type (Key), like "Passport.Replace", "DivingLicense.Renew" or "Child.Born". Each service request got a unique Id when it was initially created and with which the consumer could refer to his service request. This ServiceRequestId was represented through the Context=2021-XF47.

All information regarding that service request was filed under that same Context. There were: signed documents, images, old driving license, birth certificates etc. which are represent as documents with different keys and context-types.

key	context	contentType	userState
DivingLicense.Renew	2021-XF47	text/plain	4 (approved)
DivingLicense.Renew.Evidence	2021-XF47	image/jpg	0
DivingLicense.Renew.SignedRequest	2021-XF47	application/pdf	0

Finally the service request itself, the header record, had certain states, like saved, submitted, rejected, approved, and sometimes a state needed some kind of comment ( userState, userInfo) .

Documents offer the perfect solution for that requirement.

Finally, we defined a Lifetime for the Documents depending on their userState, so that here was no more need to care for deletion one such a service request expired, for GDPR reasons, for example.

ClientVersion could be used to check for updates and to synchronize the "paper" documents (images, pdf etc.) with a Document Management System, if there was a newer ClientVersion.