Hi team,
We use the Save to Repository feature -a lot- and in recent months it has become quite painstaking to build out digital approval processes for transformation projects that centre around "attachments". The number one inefficiency is the inability to make attachments optional when using the Save to Repository activity.
So for those unfamiliar, when you use the Save to Repository activity in forms, you select your Form and it then checks to see if the form has any upload fields. If the selected form does use file upload fields, the Save to Repository activity detects it, and it forces you to configure and store copies of those attachments alongside a copy of the submission.
If you're wondering what the problem is.. Well, the only way to display previously uploaded documents (evidence) in an approval process is to use the Upload Attachment field set to read-only. That means if you have several approvals, who all need to see the uploaded PDF/evidence, the upload field must be attached to them all. The days of just using a link or shortcut to send people to the repository to review things are well and truly coming to an end.
It isn't the end of the world, and there are some are some pretty janky workarounds to avoid saving your attachments over and over again, but it also doesn't scale - at all... and that's the real problem.
So what are some of the janky solutions?
One example is to create a "no-attachments" copy of the approval form for example "Executive Approval (NA)" and then remove all of the Upload Fields. Then when using the Save to Repository activity, target that form and select "Save Form with Current Process Data". Certainly a solution for simple approval processes, but a diabolical nightmare for complex approval processes.
Another workaround, which feels so dirty from an efficiency perspective, is to enable version tracking recursively at the destination folder level in the repository. This will merge attachments into themselves without creating a visible duplicate in the repository folder view. Disgustingly inefficient, but clean looking to the end user... not perfect though.
This method helps de-clutter the attachments (as they all merge), but it shouldn't be used if your process needs to support returning to previous approvers for correction / escalation etc as each submission will merge-over the previous version instead of showing an incremental audit trail of submissions. (so we hardly ever use this)
There are more workarounds if you start using Workflow, but, that's a non-starter for most process administrators.
So with all that in mind.. I've spent a lot of time thinking about how best to address/improve/enhance this feature set to make it easier to use for end users and the less-fortunate process administrators and repository managers who have to support them.
So here's what I've come up with so far:
1) Enhanced file-storage controls. Could we look at adding settings to configure whether we store just the form, or the form and its attachments, or just independent attachments? Bonus points if we can also create a file-less folder structure (meta template) within the repository using variables from the process. Essential for hybrid-transformation projects.
2) Uploaded file viewer widget. Instead of using the upload field in read only mode to display documents to approvers, could we provide a simple widget in a form that lets you display (by variable) a read-only view of the uploaded file(s)? Bonus points if you can specify a path in the Laserfiche repository and it only displays files based on permissions/user access rights.
3) More file settings. Expanding on the Save to Repository enhancements, would it be possible to add the ability to activate version control for specific files/attachments/folders at point of saving?
Does anyone else have some ideas or suggestions they can think of?
cc: @████████ @████████ @████████ @████████