Hello all,
We have a use case where a group of lawyers are assigned tasks for creating various types of legalization documents. Their responsibility is to review the data associated with the request that has been assigned to them and then write a series of large texts that make up the legalization document. As an example, the legalization document is made up of 4 sections, one that is automatically populated with data from the system and the other 3 sections that are filled out by the large texts the lawyers write.
One way of going about this, which has been in production for a while, is creating Interfaces for the Lawyers' User Tasks with as many ParagraphFields as the sections in the document that need to be filled out. Each ParagraphField can contain from 500 characters to 15000 characters, depending on the Request. All this data is saved to the database as it is retrieved on a subsequent request, for the same client, in order to pre populate these sections for the Lawyer.
This approach has proved to not provide a very stable User Experience as we've had issues with Browser sessions expiring and Users losing all they have written along with closing, by accident, forms where the user is not prompted to save any work (as we are on a Browser) and forms that are quite long and difficult for the user to navigate up or down.
Another approach i'm researching is working Docx Templates where the Lawyers would do all their work, but I would need to have the ability to Process the final Docx in order to extract the texts related to the above mentioned sections in order to provide them on subsequent request for the same client.
I would appreciate any suggestions for this use case or if anyone has come across a similar use case with handling such large texts on User Tasks.
Regards,
Thanos Michos
Discussion posts and replies are publicly visible
--Work Not Being Saving-- I'm not sure if the tasks you have mentioned are associated to an user input task (in process model) or if they're quick tasks or just tasks created via process start form but double check how you save the information and what type of task you're using. I've worked on forms where changes, by the user, are saved on the form locally until the user hits "Submit" and no issues were experienced if they were to navigate away from the task prior to submitting the task. --Browser Session Expiring-- You can add a timer onto the task form itself in the process model that will end the session and trigger saving the user input's information and do whatever clean-up you think would be necessary. This way, when the lawyer reaches the task again, they can start where they left off in case the session times out. --Form Navigation-- I don't have a lot of context or any visuals based on what you have provided to give as sound as a solution as I would prefer, but maybe the display of the sections can be manipulated by adding if() conditions (not sure what would be the condition..) onto the sections or maybe a filter feature on the form itself that would allow for quick navigation to specific section(s) by only showing what meets criteria until the filter is cleared (in which case, everything would show). However, I'm not sure what they could key off for this idea (like section #, name, etc.). --Database Structure-- Again, not a lot of context to run with, but when you write this info the database, you could give each section a row in a database and each row would have 1 or more identity columns (not the auto-increment field) that would denote which task the note belongs to and what section the user input is for (like mentioned previously, a section #, name, etc..). I believe this would be easier to manage but should more sections be needed on the form, the number of rows would increase exponentially across your user base. I also thought about each row having a column for each section but if the sections (if not the # of sections) are not consistent in general for your lawyers tasks and if the # of sections change too often, the database structure would require too much change/maintenance, which is not ideal. The above ideas are just to somewhat help having to pull columns where 1 field is a gigantic blob of text and to help parse the information into something a little more readable in other instances aside the form itself. --Docx Template-- I've never used this so I can't speak too much on this but from the little I did read about it, it should be an efficient enough solution if you can identify which areas will be given input by the user. Also, whatever text the user inputs should be wrapped in ### within the template at the beginning and end when the template is scanned. You can just append that text to pv's/ac's and write to the DB accordingly. You'll also have to consider folder structure, run-time description of templates, their destination, etc. which shouldn't be too difficult of a task, but again, just things to consider. Hope all this helps.