File upload in Appian is a story full of misunderstandings!
Well … what?! This is just about uploading a file!
We need to go back to the beginning of Appian to understand what is going on here.
The Beginning
Appian started as a kind of workflow supported document management system. To upload a file, we had to create a process that uses a start form with a file upload field. When the user uploaded a file, that file stayed in a temporary status until that form is submitted. This submit-action then started the process instance. File content was only accessible in process after submit.
User input tasks as part of a process behave in exactly the same way. The user uploads a file, which stays temporary until the user submits the form and the process flow continues.
The time ante Portals
Then, SAIL came along, but nothing did change. OK, not nothing, but a file uploaded to a form was still not accessible before submit. Besides some obscure and unsupported hacks. The only thing that actually has changed, that the ID assigned to a file did not change between file upload to the form and submit into process.
The time post Portals
Then, Appian introduced portals. Public facing pages that do not support any kind of submit action. Now, how do we upload a file? Well, the first iteration did not support file upload.
But then Appian added the a!submitUploadedFiles() function. And things got worse! And better at the same time!
Let’s start with the good news. We can now upload files in portals!
The bad news? Appian developers now think that they can use the function a!submitUploadedFiles() everywhere to upload files wherever they want!
What does all this mean?
Why is it a bad thing to be able to upload files from any place?
Well, this now becomes a very personal and opinionated statement.
The Appian platform is not a low-code UI toolkit to create CRUD style apps!
It is a platform designed and built to automate the complex collaboration of systems, services, and people in a business process. Any kind of data, including files, is only created or modified as a direct consequence of a user acting in a well-defined business process.
This is why there is no real data locking mechanism in Appian.
This is why there are process models tied to records as record actions.
This is why developers complain about the seemingly weird behaviour of user input tasks.
This is why process execution feels slow.
We do not use the platform to modify data, but to complete concrete tasks assigned by an automated process.
Summary
It took me years to understand this. Since then, I am that Appian fanboy that you know. And yet, are these not just confused thoughts with which I try to gloss over the technical inadequacies of Appian. Yes, that may be true. On the other hand, there are a lot of software platforms that have a very strong opinion about how things should be. In the Appian platform, I see such a strong opinion. And I like it.
You don’t have to like it, though. If that’s the case, then it might be more your problem and not Appian’s.
Dear Appian product team, stand to your vision! It is a great one, and it is what makes Appian stand out of the crowd of other software platforms.
PS: If you want to fully upload and submit a file in any place in Appian, create a record that holds some metadata of your files and add a tiny record action process with the file upload form as the start form. Then you can add this action anywhere (user input tasks, site pages, record views, etc.) using popup style.