Appian Community
Site
Search
Sign In/Register
Site
Search
User
DISCUSS
LEARN
SUCCESS
SUPPORT
Documentation
AppMarket
More
Cancel
I'm looking for ...
State
Not Answered
Replies
6 replies
Subscribers
7 subscribers
Views
1841 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
General
Hi, We have undertaken a project which aims to replace paper forms. T
senthilar
over 10 years ago
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
0
Sathya Srinivasan
Appian Employee
over 10 years ago
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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Reply
0
Sathya Srinivasan
Appian Employee
over 10 years ago
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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Children
No Data