# Service Requests

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.

<table><thead><tr><th width="318">key</th><th>context</th><th width="159">contentType</th><th>userState</th></tr></thead><tbody><tr><td>DivingLicense.Renew</td><td>2021-XF47</td><td>text/plain</td><td>4 (approved)</td></tr><tr><td>DivingLicense.Renew.Evidence</td><td>2021-XF47</td><td>image/jpg</td><td>0</td></tr><tr><td>DivingLicense.Renew.SignedRequest</td><td>2021-XF47</td><td>application/pdf</td><td>0</td></tr></tbody></table>

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`.&#x20;