### Scenario 4: Process document – use IDP as a solution state store
Scenario 2, and to some extent Scenario 3, require management of the overall document processing state (was it processed by IDP and subsequently the result was downloaded).
In the Scenario 4, IDP keeps information about downstream processing status (result processed status) communicated to the system through the *acknowledge-result-processed* endpoint.
Standard workflow in this scenario has the following steps:
1. Start document processing within IDP using one of the existing upload methods, but ignore assigned process UUID. (fire and forget upload)
2. Upload client is expected to periodically poll get-process-list from the *process-administration-controller* group to fetch a list of documents in an EXPORTED / REJECTED status with result processing not been acknowledged yet.
3. Process results obtained in 2. are then downloaded using get-xml-result endpoint if the processing status is EXPORTED. If the status is REJECTED there is no artifact for download.
4. Acknowledge result processing.

***Note 1***: Irrespective of the process result, if a process reaches one of the final states, *get-document-pdf* endpoint from the *idp-process* group can be used for obtaining input document pdf.
***Note 2***: Endpoint *acknowledge-result-processed* from the group *idp-process* must be called upon finishing steps for any of the scenarios 2-4. This call signalizes to the IDP system formal closure of the process and is
used in IDP internally to appropriately handle such processes.