Letting non-technical clients design forms and workflows

Question

Some individuals in my organization are under the impression that our clients, who are very non-technical, will be able to design forms / workflows, etc.
The impression is that the developers are to create a set of standard schemas, fragment libraries, and workflows, and then the (non-technical) client can build their own forms, select a predefined Task Manager endpoint, and hit the ground running with their new form, in production. Yes you heard me correctly. In production. That means no DEV, no QA, no passing Go.
In other words, they are putting LiveCycle on the same playing field as Vignette (Content management in production).
I disagree with their approach and am seeking feedback. Thanks! ;-)

Answer 1

If the form is bound to a schema, at least when they move form elements around, most of the time it will still work. If normal binding, moving stuff around will screw up the data merge.
The biggest problem I see with the changes being made directly in production is that I save my forms to the repository in order to test. The preview tab quite often does not represent true functionality. So if they had Workbench pointing right at prod, the form cannot be tested without releasing it.
I don't know what you mean between content repository and Workbench repository. The way my implementation works, if I save in Workbench, I can immediately reload the page to get the changes. They are the same repository. I am using the API call (off the top of my head) renderFormWithUSageRights. I specify a repository URL for the template location. All my forms render through the same servlet parsing the form name out of the request URL. There is an XDP in the repository with the same name as each pdf URL. There is also a corresponding JSP which renders the XML that is merged in at render.
I saw a reference somewhere that the repository URL could contain a version at the end. I have not tried this. If true, it would not be difficult for me to update my code to get the version number out of my properties database table. Then also allow an override version number in the URL for the final form. So http://mycompany.com/myform.pdf renders the 'released' version and http://mycompany.com/myform.pdf?version=2.7 returns that specific version. http://mycompany.com/myform.pdf?version=latest would work like it does now where no version number is specific in the repository URL. This would mean they could save the form, access in production to test, but not affect normal users. Once tested, the database could be updated to reflect the new released version. It would be really slick to have a workflow approval process around it. The workflow would have a link to the new version for each approver to review. After the last person signs, the workflow would update the database to the new version. The next time it is rendered will be the latest version.
Thinking about this, I like that idea even if a developer makes the changes. There are times when customers won't sign off on their own requested changes because they won't make the effort to test it before it goes into production. They would rather let the changes go in then report anything they don't like as a bug. They feel if they don't sign, then they cannot be held accountable. Sometimes the same people or others will get angry if an item is not put into production based on not getting sign off. Now, the deployment would be tied directly to the sign off procedure rather than manually by someone in IT. All approvers would be able to look at the audit trail to see who has not signed off and therefore the direct cause of an item not being released.