Is it possible to edit the text of a comment variable after the form in a process has been submitted?
For whom?
For a user who changed their mind to alter their own comments after clicking submit? No. Not without a really convoluted form design where it is never really submitted.
For an admin? Yes. Just change the table in SQL.
I am an admin, but haven't really edited an SQL table before, how do I know which table to access?
You asked if it was possible. It is possible. I strongly caution you against editing your SQL tables unless you know exactly what you're doing. If you REALLY need to do that get some expert help from your VAR.
Fortunately for us we have several top notch SQL programmers and I one edit the table successfully. Thanks for your input.
For end users and platform administrators no.
For your database administrator it is possible - but strongly discouraged and advised against for two reasons.
1) Editing the database can have unexpected consequences if not carried out properly. It is assumed you only need to update one field in one table, but it is not known whether that data may also be in another field in another table somewhere.
2) From an audit point of view, carrying out actions directly against the database can compromise the integrity of the data and audit history.
It would certainly be appreciated if Laserfiche could add the ability for platform administrators to update/edit/manage in-flight data during a business process. That way the changes could be tracked and the initiator informed that their data was updated/modified/edited.
Sorry - to correct myself, it is very possible for a platform administrator to update the information after it has been submitted. Although the process to do so is very convoluted and should only be done while the business process is unpublished.
The way to do it is to:
1) Unpublish the business process.
2) Using the Monitor view, find which step your targeted submission is currently at. You'll need to know this so you can target it in the business process. Note: If the "current step" is quite an advanced form or has special lookups/dependencies it may not be possible without a lot of additional work to submit that form.. so be mindful of this before proceeding.
3) Now that you've identified which step you need to target, open the process modeller and add a new user task to the process which is assigned to you (as the platform administrator - important since unpublished processes cannot be completed otherwise).
4) Now configure which form will be displayed to you when you open the task. You do this by selecting a form in the new user task (such as the original form). You can alternatively build a simple form with just the fields you wish to edit. Depends on how much effort you want to go to in order to fix/update/edit this data.
5) Connect your new task to the current step in the process. Loop the ouput from the new user task back into the original step. This way when you complete your user task it will loop back into the original "current step".
6) Now go back to the Monitor view, select the current step task, assign it to yourself. Complete the task so that it moves to the "New Task (Edit)" that you have set up. You have now been assigned the original form as a task which you can edit/update and resubmit. When you submit this new task, it will loop back to the original step and place the task back onto the original user.
7) Now don't forget to edit your original process, reverting back your changes. Also don't forget to publish the form so that is available to others to use.
Not a lot of platform administrators will want to go to these lengths to get this to work. It also depends on whatever step the process is currently on.
We accomplished the same task by reassigning the user task to myself, saving the form as "draft" then removing the "read only" requirement in the step, altering the text in the comments to fit the new directive, and reassigning it back to the original recipient. Unfortunately when the next person reviewed their task and submitted it the edited text reverted back to the comments on the first form in the process. We solved the issue by having one of our more experienced SQL software engineers edit the table and now the comments are permanent. Thanks for your help.