Hi all, We are running into issues with the Default Filter on Records

...ll ultimately fail when we pass 2100 records.

Stop-gap solution:
We will add pagingInfo to the Default Filter on the Record (limit it to 2000 rows – our DBA’s will not increase the SQL parameter limit), so that we do not cause crashes when 2100+ parameters are passed to the IN clause. We also have historical reports set up, outside of Appian, but the business admins are concerned they won't be able to view their historical requests (outside of the top 2000) from within Appian anymore.

The issue:
By limiting the records returned through the Default Filter, to say, the top 2000, then any requests outside of that range are inaccessible via Appian. Even if we put an older request ID to the record list search or tempo report filters, no results will be returned.

Requirement:
Any record in the data store should be viewable in Appian reports and Dashboards if we provide the correct filters– eg ID, business unit, requestor.

Thanks for reading. Hope I’ve described things...

... clearly and accurately!
Regards,
JR

Note 1: Ideally we do not want to use multiple record types eg. ‘Inflight records’ and ‘Archived’ records.
Note 2: With newer builds we are advising stakeholders of the current limitation in advance so they can plan around it.

Previous reply from Tom Ryan:

If I understand correctly, you are determining the list of records that a user has access to, and then passing that list back in to a query? If that is the case, the best solution is probably to redesign your filter to use a group (as described in the best practice). Alternatively you could add a value which evaluates to true or false based on permissions and filter the record based on that.

The problem with what you have described is performance - consider that the best practices doc you linked says "The exact performance difference will depend on your infrastructure, but it is strongly encouraged to conduct performance tests of your default filter if a user may be a member of more than 100 groups", and you are using the IN operator on a set 20 times larger than that.

Thanks for your reply Tom.

For our requirements, where there *will* be different security groups per request (ie. each request will have a different Requestor + series of Approvers), ultimately we would still eventually reach 2100 groups (1 per request), and for our Business Admin group (who can view all requests) we would be be passing those 2100 group IDs in to the IN query.

Hi Jonathan,
Please find the below link for more details:
forum.appian.com/.../e-122665

Thanks,
Chandhini R

Hi Chandhini,

We are still unsure about how to implement the Default Filter for a scenario as described. Our previous scenario (from that thread) allowed for a simple filter w/ 2 parameters. For this case management scenario, we are not having any luck finding viable workarounds to the Default Filter (since we cannot use OR conditions on it (use conditional filters) ).
=======================
Record security required:
- Requestors and Approvers can view requests that they are involved in.
- Business Admin’s can view ALL requests
=======================

We've been discussing internally, but it seems we will still hit the 2100 limit for the Business Admin use case. FWIW: Our main table holds both the requestor + approver values (per row).

Any example code would be appreciated.
Thanks,
JR

Hi Jonathan,
here is a similar post related to your requirement.
forum.appian.com/.../
Hope this helps you!

Thanks chandhinir =)