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

Hi,

We have undertaken a project which aims to replace paper forms. There are 6 Account Types in total and each account type has about 15-20 paper forms. So, there are 100+ paper forms in use. We would have to design Appian forms for each of these paper forms. How does the idea of creating a separate CDT for each of these forms sound? This would result in we declaring 100+ variables (1 variable for each CDT) in our top-level process model.
What kind of problems should we expect? Anyone has a better solution to suggest?...

OriginalPostID-111888

OriginalPostID-111888

  Discussion posts and replies are publicly visible

Parents
  • 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.
Reply
  • 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.
Children
No Data