You are viewing limited content. For full access, please sign in.

Discussion

Discussion

[Feature Request] Save to Repository and File Management Enhancements (Forms)

posted on December 7, 2020 Show version history

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: @████████ @████████ @████████ @████████

 

1 0
replied on January 20, 2022

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.

 

Hi team,

I was wondering if anyone could update us on whether we'll see some improvements to the Storage Activity controls for On Premise Laserfiche Forms?

We'd really like to see an option like this:

So that we can choose whether it is at this specific point in the process that we want to save a copy of the attachment(s) along with a copy of the form to the repository.

Again to reiterate, this is a real challenge for multi-stage approval processes where attachments are working documents in a process that can be reviewed, potentially updated, and are not finalised until the very end of a process.

Unfortunately this means we cannot save snapshots of the form submission without also being forced to save every associated attachment for that step in the process, too. 

Just a quality of life complaint really, as shown in the original post. Really hate having to build an maintain literally two forms for each approval stage just so we can have a version of the form where there are no attachments.

CC: @████████ @████████ @████████

 

Kind Regards,

0 0
replied on January 26, 2022

Hi Kris,

     We have already added your feature request in our backlog items before, we will evaluate it when plan our next release.

0 0
replied on December 10, 2020

1)For the save option to choose whether to save attachments or not, in you case you want to not save all the attachments, right? If there are multiple file upload fields on the form, do you want an option to turn off for all file upload fields or turn off one by one. Currently Forms already supports the "No Form" option which will not generate pdf for the form but create a entry without any page.

2)Integrate the repository to show or upload files from the repository has been requested long time ago, we don't have plan to implement it yet as the effort for adding this feature is big.

3) It is doable to enable version tracking when save to repository for the specified folder or the documents saved.

@████████

 

2 0
replied on December 10, 2020

Hi Xiuhong,

Thanks for your response!

Re: 1) Save to Repository Activity improvements:
The first and most important improvement would be providing fine-tuned controls over exactly which attachments are saved. All or nothing doesn't work. So to answer your question, correct, we would like to be able to individually specify which attachments are saved and which are ignored. 

This would greatly improve additive approval processes where approvers must review the previous users submission and associated uploads before they must add/upload their approval documents to the approval chain. Currently you'd have to re-save the previous users documents that were displayed AND the approver's attachments.

Re: 1a) No Form Option

Huh! Well what do you know. I haven't changed this from Save as PDF in so long I didn't realise the "No Form" feature even existed! That's perfect for creating a folder structure. Awesome and thank you! :)

Re: 2) Uploaded File Viewer

If the ability to access/lookup the repository is a lot of work - no problem, maybe sometime in the future. However, the key request for this point was for a way to display documents that were captured in earlier steps of a process. As you know this is already currently possible by using an upload field set to read only. The thought process behind this feature was to simplify the number of attachments shown in a save to repository activity by differentiating an upload field from a document display field (upload set to readonly). If we have the ability to individually select which attachments save (as suggested in (1)) this feature may not be as important. I figured that a dedicated field for displaying documents would be a more intuitive way of displaying documents in a form than re-using upload fields which can confuse activities like save to repository.

In the below example, half of these documents are just there to be displayed so that they can be reviewed by an approver before they are asked to upload their supporting documentation/approvals. However, in this save to activity step we are forced to store a copy of everything - including the read-only upload fields.

If there was a way to differentiate documents for display vs documents to be uploaded (at the form design level), this section would only display file upload fields.

 

Pass my thanks on to whichever team member had the foresight to expect more than 6-7 attachments on any given form haha :D

 

Re: 2a) Attach File from Repository using Workflow (New)

Not mentioned in my first post, but your comment reminded me, do you know if there are any plans to officially implement the ability to attach files to Upload Fields in a business process via workflow? Currently this is only possible using some third party plugins and would be hugely beneficial for being able to automatically attach counter signed documentation from third party service providers like DocuSign instead of making a user perform this action manually within a business process.

 

Re: 3) Individual version control settings for save to repository activity

Sorry, in your response are you saying this is doable already? Or did you mean this is a feature that could be added to the Save to Repository activity in Laserfiche Forms? If it is doable already, can you advise where? I can't see the option for version control in the Save to Repository task. I'm aware you can trigger version tracking by using a root storage folder with tracking turned on for "everything" or by assigning a special template or using workflow, but we're looking for a way to turn version control on for the individual attachment/upload without having to resort to non-native solutions that process administrators may not be able to access or configure themselves. 

 

Thank you for looking into this and taking the time to respond, it is massively appreciated!

2 0
You are not allowed to follow up in this post.

Sign in to reply to this post.