The possibility of generic (non form/field) workflow attachments

[andrewpatto]

Some of our stakeholders are thinking about an ability to generically store attachments as part of an application flow - though not part of the application form. This would primarily be documents stored by the handlers etc - and not documents stored by the applicants (though possibly it could be totally generic).

For instance, once an application is processed - there might be a paper/scanned legal agreement signed by the parties.. or at the end of the process - there might be a report of the activities produced by the data recipients to close off the sharing.

Hanging these documents/pdfs off the application in REMS seems like a logical spot for storing them (understanding the argument could be made that they should be stored in a document management system). But given other attachments are already part of the application form process - we were wondering if this is a feature we could suggest?

[Macroz]

Hey,

Sounds very reasonable. And there are a few existing possibilities, at least what I can think of now:

• Add a custom attachment "license" to the application. Then the applicant and members must "sign it" by approving the terms. This can be an option for a "digital signature" in some cases. This can happen after the application is already sent for processing.
• Add relevant documents like a signed and scanned paper or digitally signed PDF to the approval action as attachments. These would be shown to the applicant as well.
• Add any extra documents as remark action attachments, which can be private to the handlers only.
• Extend and implement some part of Handler fields in forms #3030 for a more generic model of storing data in an application.
• Use an external store. This is the case for some of the production systems, that there exists a separate CRM system which contains even more data, so REMS decisions are simply synchronized there.

Some of these could cover your case I think, or could be suitably extended. Do you think one of these already works for you or what would be a necessary addition? If there is need to develop something new, then we could create an issue, or update #3030 with the relevant additions.