Updating CDT within an existing application

You have to perform a check for outdated dependents (otherwise called Impact Analysis), depending on which version of Appian you are using.

Go to,
Records > Appian Software > [Your Version] > Product Documentation

For 7.9,
forum.appian.com/.../Custom_Data_Types.html
forum.appian.com/.../Trace_Relationships_for_Impact_Analysis.html


Keep in mind that you have to understand the impact of doing this. Few considerations are,
1. ri! variables used in SAIL rules called from new instance (or sub process instance created by parent process after you deploy this change) of process model will use the NEW cdt definition whereas rules called from existing running instance will still follow the old definition.
2. Touch points should be updated carefully. Try to create a duplicate of your rule and make new instances refer to that.
For example if you have added a new column say column5 in ur cdt say myCdt1,
a. Form1 inside process1 is calling rule1
b. When you update your cdt, ac! of form1 will refer to type myCdt1^1 which doesnt have the additional column cloumn5
c. Now if u directly add a component in your rule1 and map to ri!myCdt1.column5, old instances will break
d. To avoid this, create a new copy of rule say rule2 and update your Form1 to call rule2
e. Now old instances of process model (referring old cdt version) will still refer to rule1 and new instances will start referring rule2.
3. Your cdt should not be passed by reference anywhere in the process model.

It also depends on the update you are making to the cdt and how you are using the fields in SAIL form.
For the same example above, you can avoid creating new copy of rule, by checking if a field exists in cdt before mapping it to a SAIl component.

You have to perform a check for outdated dependents (otherwise called Impact Analysis), depending on which version of Appian you are using.

Go to,
Records > Appian Software > [Your Version] > Product Documentation

For 7.9,
forum.appian.com/.../Custom_Data_Types.html
forum.appian.com/.../Trace_Relationships_for_Impact_Analysis.html


Keep in mind that you have to understand the impact of doing this. Few considerations are,
1. ri! variables used in SAIL rules called from new instance (or sub process instance created by parent process after you deploy this change) of process model will use the NEW cdt definition whereas rules called from existing running instance will still follow the old definition.
2. Touch points should be updated carefully. Try to create a duplicate of your rule and make new instances refer to that.
For example if you have added a new column say column5 in ur cdt say myCdt1,
a. Form1 inside process1 is calling rule1
b. When you update your cdt, ac! of form1 will refer to type myCdt1^1 which doesnt have the additional column cloumn5
c. Now if u directly add a component in your rule1 and map to ri!myCdt1.column5, old instances will break
d. To avoid this, create a new copy of rule say rule2 and update your Form1 to call rule2
e. Now old instances of process model (referring old cdt version) will still refer to rule1 and new instances will start referring rule2.
3. Your cdt should not be passed by reference anywhere in the process model.

It also depends on the update you are making to the cdt and how you are using the fields in SAIL form.
For the same example above, you can avoid creating new copy of rule, by checking if a field exists in cdt before mapping it to a SAIl component.