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

@csteward Hi, as far as I know I have come to know that performance issues arise when following approaches were chosen:

1. One group per one record - https://forum.appian.com/suite/help/16.1/Record_Level_Security_for_Entity_Backed_Records_Best_Practice.html. This violates the rule '<100 groups per person'. Further you stated that 'I tested 9,000 groups and the user could not even log in'. This is not a good practice definitely and off-course this leads to performance degrade as well.

2. 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. Off-course, as the list of records in which the user has participated increases, the performance goes down.


So finally I would like to ask you following questions and it would be grateful if you can answer the following questions:
1. As we have seen that performance degrade and best practice violation are the disadvantages of above discussed approaches, how did you overcome the disadvantages (in terms of performance and best practice but not in terms of flexibility) by choosing the Service Backed Records?
2. There are few features which we are actually desiring for, such as access record fields (rf!) within the Value, AND/OR among the default filters. I am interested in knowing from your perspective, if these features can resolve performance issues or best practice violations as discussed above.

@csteward Hi, as far as I know I have come to know that performance issues arise when following approaches were chosen:

1. One group per one record - https://forum.appian.com/suite/help/16.1/Record_Level_Security_for_Entity_Backed_Records_Best_Practice.html. This violates the rule '<100 groups per person'. Further you stated that 'I tested 9,000 groups and the user could not even log in'. This is not a good practice definitely and off-course this leads to performance degrade as well.

2. 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. Off-course, as the list of records in which the user has participated increases, the performance goes down.


So finally I would like to ask you following questions and it would be grateful if you can answer the following questions:
1. As we have seen that performance degrade and best practice violation are the disadvantages of above discussed approaches, how did you overcome the disadvantages (in terms of performance and best practice but not in terms of flexibility) by choosing the Service Backed Records?
2. There are few features which we are actually desiring for, such as access record fields (rf!) within the Value, AND/OR among the default filters. I am interested in knowing from your perspective, if these features can resolve performance issues or best practice violations as discussed above.