Compress Appian Documents uploaded by user

Are you looking for something like this? - community.appian.com/.../document-zipper

This will zip it right but will it compress the docs?

i tried it with document zipper , where i see total mb of zip file is same as total mb of files which i compressed

You will need to be more detailed than simply saying "compress", which has different meanings depending on the context.  For typical binary files where you expect to get the exact same files back 1:1 after decompressing them, ZIP is about as compressed as you can get.  For images and related content, on the other hand, lossy compression can be applied which can often decrease file size by an order of magnitude or so without much apparent quality loss - but that would be a *completely different* operation.

HI Mike , Thanks for reply, How we can apply apply lossy compression on image so it can reduce the size , do we have any plugin for it ?

All I know is what can be searched for at the App Market.  Were you unable to find anything when you went there and searched "image compression"?

Personally I've experimented before with a smart service called "compress PDF" which applies lossy compression to PDF files (presumably by compressing stored images), but I haven't used any image compression plug-ins; I assume there probably is one, though.

Thanks Mike , Will Have a look

Thanks Mike , Will Have a look

I am not sure if should use appian for this type of operations.
There is a reason why low code is limited to some type of functionality until someone implemented is specifically for that action. Then its based on "high code" like java and included as smart service into the platform. So with that you can create dozens of additional sets of functionality

Perhaps it should be more a challenge why you got this requirement in the first place for Appian?
Every technology has its limits and we should asses them properly.

Richard Michaelis said:

I am not sure if should use appian for this type of operations.

I dunno - my production system sees thousands of files added as direct uploads from end users, and at the end of the day functions as a repo for said files; many of these end up being uncropped, uncompressed image files (of official documentation we need to keep on-hand) and it's a constant struggle to maintain a balance between these and our disk usage numbers.  If some sort of default procedural image compression had been implemented up-front, that whole headache could have been potentially avoided.  I don't think we should be in a position where we're avoiding the use of necessary funcitonality all in deference to the "low code" buzzword.  And there are plenty of other advanced usages already available / in use which go beyond it already.

But that was my point. The plattform is a wild mix of services a LC functions.
-> the requirements needs to be challenged in advance. Not defined as such an then "deal with it".

Richard Michaelis said:

the requirements needs to be challenged in advance

I agree with you there.  But also, sometimes we need to figure out ways to do things in-process that make sense to the business case (otherwise the folks that pay the bills might start sniffing around other platforms that advertise more functionality / etc).