Hi Pava, thanks for that and great to hear!

The best of both worlds , please . If possible, the ability to assign a user's details as the 'sender' for the Direct Share would be great - i.e.:

1. Forms process that runs a workflow - sends the 'Currently Assigned User' as a variable
2. Workflow/Direct Share sends the email/link as 'from the Current Forms Task user'
3. The user can see in the repository which documents etc are shared 'by them', and also a link back to the Forms process would be cool as well (so that in the Form/Process you can see/launch which documents are shared, and to whom)

The above would give really good visibility and allow for 'case management' type processes, where a particular user can manage all correspondence with a client or agent for example.

In some cases however, just a generic process automation user would suffice.

Also - if I can shoe-horn in another request - the ability to Direct Share folders would be great too!

What would you be sharing in the Forms case? Would it be the just documents saved from the process or would you expect to have WF look for other documents in the repository and share them on behalf of the current Forms process step?

Hi Miruna,

In the particular case I have at the moment it would be:

1. A document generated by Workflow (using update MS Word and Forms Input Variables) - which gets created in the repository - AND
2. One or more documents that get uploaded into the forms processes - and which would be saved into the repository.

Both of these elements need to be shared with a 3rd party (not an LF user). Ideally we could generate the doc into a folder; save the uploaded files into the same folder; then Direct Share the folder.

There would be other possible use cases too. In a different scenario we save a generated doc in a completely separate folder structure from the uploaded docs - so being able to use Search Repository and/or Find Entries (plural) and Share them all in one email would be great.

Not sure whether Direct Share can provide one email with links to multiple docs in different folder locations? But that would be brilliant if it could.

Our use is to temporarily share student documents either with staff that do not normally have access or with parents.  The overall goal is to reduce the amount of documents that are being emailed and to remove the emailing of sensitive documents entirely. 

• Staff/Parent Request
  1. Staff member submits a request Form for specific documents relating to a student
  2. The Form is approved by the corresponding departmental personnel
  3. Workflow provides a link to those documents via Direct Share to the staff/parent

In this instance I would see the Direct Share being managed by the WORKFLOW account but I can also see the need to have it mapped to a specific user account for other situations.

Hi Miruna and Pava,

We've just established a real urgency for this during testing a process today; which is to say that the total file size for all attachments in an email sent by Cloud is 10mb. Our client works in engineering and frequently sends email attachments above this 10mb limit (site plans, drawings, photos etc).

For them, a manual Laserfiche Direct Share each time is not really a good workaround, as this is similar to what they were doing previously (manual share via SharePoint/OneDrive).

I will however also send a separate request for a Feature to allow larger file sizes (optional feature / subscription cost for client?).

Hi Duncan,

Until very recently, the email provider Laserfiche Cloud uses had a 10 MB message size limit. They've now announced the size limit can be raised to 40 MB on request, so we're actively in the process of seeing if we can get it raised for Cloud. The feature request task ID for tracking purposes is # 353205.

Hi Samuel - excellent, that's great news! Thanks.

Just FYI - this particular client can occasionally have a single PDF over 50MB file needed to be shared with external parties  (PDFs with embedded high-res imagery and map-layers). So the Direct Share will still be needed perhaps 20% of the time we run their processes.

Also - with the feature request ID - is there a register that we as SPs can see? (status, latest news, ETA etc).

Hi Duncan,

The internal tracking system that request ID comes from isn't externally accessible. The IDs are useful to the extent that they allow you to ask support etc. for updates on specific items without them having to go digging based on internal keyword searches, reaching out to dev teams, etc., and that patch notes sometimes note the feature/bug ID next to new/fixed items.