Hi, We have undertaken a project which aims to replace paper forms. T

Design a generic form. then using a!applyComponents with a dynamic data using query rules you can drive the form from data from database

From the architectural point of view, my view is that you need to break down your forms into unique data elements. For e.g. You may have an insurance form. There will be one form for all kind of insurance - although some data elements may be common, such as customer details and policy info, other information may depend on the type of insurance (for e.g health, car etc). So you need to decompose your data model into finite entity sets and build your processes around it. I would recommend starting from entity to process. Doing the other way round may most likely lead you to lots of changes down the lane. Once you get the entity in place, the rest is mapping the entities to a CDT or so.
When it comes to rendering the form, you can literally do a lot here. You can use the CDT to create your form or define the form definition externally and invoke it dynamically - and many more. Check a sample concept I'd uploaded under Library & Utilities (Shared Components) called dynaform-designer. This might give you some idea.

Sathya, The approach we have taken is along the same lines. We have one form all types of accounts and the SAIL code for rendering each type of account is driven by rules(based on account type). However, because there are lots of account types, our main process model will still need to hold 100+ CDT's since reporting is driven from that. Will there be any performance issues due to this approach or is it a proven one?

The # of CDT's should not have any impact on Analytics to the best of my knowledge.

I have a single CDT that stores all form answers (QuestionAnswer), it has an id for the question, and a text field for the answer (no matter what type it is on the form, we're converting to text to store in the database) as well as other metadata. A reference table links the question ids to the question labels. Then I supply an array of this CDT to the SAIL rule for the form, and use rules to append or update the index of each question in the saveInto field, and to get the answer for that question in the value field.

If I have time I'll look into creating a sample application that I can upload to forum, because it's a bit difficult to explain without seeing the example.

Thank you Sathya and Jason!