Hi all, we are in middle of planning for complete moving data from apps to

While you can most definitely persist viewer/actor data to the DB via CDT (we do the same as a best practice), you will not be able to reference multiple fields for an entity-backed record's Default Filters. You can create a single filter, per say, if you want the loggedinuser() to only see record items for which they are recorded in a value of a single field. However, if you need logic such as "Show record items where loggedinuser() is either the initiator, an approver or a viewer", this is currently not available for entity-backed records without using the group method (one group per process instance). This best practice is suggested for (I believe) situations where a user will be in no more than 100 groups. We have users where this would require 30,000+ groups, so this does not work for us either (I tested 9,000 groups and the user could not even log in).

Utilizing multiple default filters becomes restrictive as they work under the "AND" operator across all filters, which we cannot configure at this time. Also, the inability to access record fields (rf!) within the Value setting of the filter is a second issue. The latter would allow work arounds such as utilizing a dummy boolean field ("true") as the "Field" setting, operator "=" then the Value could be "=or(loggedinuser()=rf!initiatorField,loggedinuser()=rf!approverField,loggedinuser()=rf!viewerField)". Alternatively, allowing designers to control the primary default filter operator (AND/OR across all filters) would solve these issues.

Another restriction is that you cannot access child CDT information in default filters. We went through tests with recording all viewer information to a child CDT, then accessing one field (storing viewer information) in the default filter via the "INCLUDES" operator, only to find out child CDT data is inaccessible.

One earlier recommendation on forum was to use the unique identifier (ID) field in the default filter "Field" setting, "IN" operator, and in the Value field return a list of all ID values where the loggedinuser has participated at any role, which can be done via query rule on a SQL view that organizes this data into one field. Performance results caused us to steer clear of this idea.

As we have similar security/logic requirements, and too many processes to implement the practice of on group per process instances, we've been forced to utilize service-backed records, which can be fully dynamic with data returned via a!queryEntity(). There is a bit of setup involved, but the tutorial is very helpful: forum.appian.com/.../Service-Backed_Record_Tutorial.html.

Aside from the initial setup, this method has been very beneficial for us. Security is 100% customizable, and the benefit of controlling which fields the Search references is a nice bonus. Currently Search only utilizes 'Title' data, but with service backed records you can reference any field in your CDT for searching that you would like. The logicalExpressions within queryEntity can be a bit cumbersome, but once you have one record configured - copying and manipulating for future records is much easier.

An enhancement to expand Default Filters to be expressionable and dynamic is currently being tracked under AN-60876. I have not heard any information as to the progress of this, but we sure would like to see it in the base product.

While you can most definitely persist viewer/actor data to the DB via CDT (we do the same as a best practice), you will not be able to reference multiple fields for an entity-backed record's Default Filters. You can create a single filter, per say, if you want the loggedinuser() to only see record items for which they are recorded in a value of a single field. However, if you need logic such as "Show record items where loggedinuser() is either the initiator, an approver or a viewer", this is currently not available for entity-backed records without using the group method (one group per process instance). This best practice is suggested for (I believe) situations where a user will be in no more than 100 groups. We have users where this would require 30,000+ groups, so this does not work for us either (I tested 9,000 groups and the user could not even log in).

Utilizing multiple default filters becomes restrictive as they work under the "AND" operator across all filters, which we cannot configure at this time. Also, the inability to access record fields (rf!) within the Value setting of the filter is a second issue. The latter would allow work arounds such as utilizing a dummy boolean field ("true") as the "Field" setting, operator "=" then the Value could be "=or(loggedinuser()=rf!initiatorField,loggedinuser()=rf!approverField,loggedinuser()=rf!viewerField)". Alternatively, allowing designers to control the primary default filter operator (AND/OR across all filters) would solve these issues.

Another restriction is that you cannot access child CDT information in default filters. We went through tests with recording all viewer information to a child CDT, then accessing one field (storing viewer information) in the default filter via the "INCLUDES" operator, only to find out child CDT data is inaccessible.

One earlier recommendation on forum was to use the unique identifier (ID) field in the default filter "Field" setting, "IN" operator, and in the Value field return a list of all ID values where the loggedinuser has participated at any role, which can be done via query rule on a SQL view that organizes this data into one field. Performance results caused us to steer clear of this idea.

As we have similar security/logic requirements, and too many processes to implement the practice of on group per process instances, we've been forced to utilize service-backed records, which can be fully dynamic with data returned via a!queryEntity(). There is a bit of setup involved, but the tutorial is very helpful: forum.appian.com/.../Service-Backed_Record_Tutorial.html.

Aside from the initial setup, this method has been very beneficial for us. Security is 100% customizable, and the benefit of controlling which fields the Search references is a nice bonus. Currently Search only utilizes 'Title' data, but with service backed records you can reference any field in your CDT for searching that you would like. The logicalExpressions within queryEntity can be a bit cumbersome, but once you have one record configured - copying and manipulating for future records is much easier.

An enhancement to expand Default Filters to be expressionable and dynamic is currently being tracked under AN-60876. I have not heard any information as to the progress of this, but we sure would like to see it in the base product.