Über Suche (siehe Suchfeld) und Filter (siehe Filter) können die Inhalte von Tabellen, Listen oder Baumstrukturen reduziert werden, so dass Nutzende schnell den gewünschten Eintrag finden.

Die Summe aller gesetzten Filter und Suchbegriffe definiert die Ergebnismenge und der Text “[Anzahl] Einträge” wird nach jeder Änderung entsprechend aktualisiert. 
Das Suchfeld und die einzelnen Filter-Pillen sind programmatisch mit einer “Und”-Logik verknüpft. Das heißt, es werden Ergebnisse angezeigt, die sowohl den eingegeben Suchbegriff enthalten, als auch zu den via Filter definierten Kriterien passen. 

Beispiel: Suchfeld enthält den Namen “Müller”. Es ist ein Filter “Dienstgrad” aktiv, mit dem Wert “Mittlerer Dienst”. Es werden dann nur Personen angezeigt, in deren Name der Begriff “Müller” auftaucht und die zusätzlich im Mittleren Dienst tätig sind.

Die Inhalte einzelner Filter-Container sind mit einer inklusiven Oder-Logik verknüpft. Beispiele:

• Wurden im Mehrfachauswahl-Filter “Fachbereich” die Werte “Zivil” und “Straf” angewählt, so werden Verfahren gefunden, die einem von beiden Fachbereichen zugeordnet sind.
• Wurden im Mehrfachauswahl-Filter “Rolle” die Werte “A” und “B” angewählt, so werden Personen gefunden, welche Rolle A, Rolle B oder beide Rollen haben.

Wenn die Daten durch die Verwendung von Suchfeld und/oder Filter-Pillen reduziert wurden, muss der Ansichtswechsel die aktuellen Such- und Filterwerte übernehmen.

Über das Suchfeld kann nach mehreren Attributen gesucht werden. 

Standardfall ist: Es werden die Inhalte der ersten Tabellenspalte (in der Regel Objektbezeichnung) durchsucht. Ob darüber hinaus noch weitere Attribute des Moduls durchsucht werden, ist in den Userstories zu definieren. 

Im Regelfall sollte die Anzahl an zu durchsuchenden Attributen möglichst gering gehalten werden und zu dem passen, was als häufigste Anwendungsfälle zu erwarten sind. Von einer Suche nach “Allen Attributen” ist aus Nutzer- sowie Performance-Sicht abzuraten. Beispiele:

• Im Modul Gerichtsverwaltung in der Übersicht aller Stellen werden die Attribute Stellenbezeichnung, Stellen-Nummer und Stellentyp durchsucht.
• Im Modul Personenverwaltung in der Übersicht aller Justizbediensteten werden alle Namensattribute (Nachname, Vorname, Titel, Vorherige Nachnamen, Alias-Namen etc.) durchsucht.

(Diese Beispiele sind vom entsprechenden Modul zu bestätigen > falls abweichend gilt das, was in Userstories definiert ist.)

Jede Filter-Pille ist, im Gegensatz zum Suchfeld, immer mit genau einem Attribut verknüpft. 

Beispiel: Filter “Nachname” durchsucht nur das Attribut “Nachname”.

Welche Filterpillen beim Öffnen der Seite vorhanden sind und welche über den Plus-Button hinzufügbar sind, ist vom Modul in Userstories zu definieren.

Fachlicher Wunsch: Es soll auch möglich sein, Filter-Pillen hinzuzufügen, die über die in der Tabelle angezeigten Spalten hinausgehen.

Zur Darstellung der Suchergebnisse im jeweiligen Element siehe Tabelle, Liste oder Baumstruktur.

Im Idealfall sollten Datenübersichten (Tabellen/Listen/Baumstrukturen/Kalenderansichten) immer die Gesamtmenge der vorhandenen Objekte eines Typs beinhalten, ggf. auf mehrere Seiten verteilt bei paginierten Tabellen oder Listen.

Bei sehr hohen Objektzahlen kann die Darstellung der gesamten Ergebnismenge im Frontend jedoch zu erheblichen Performance-Problemen führen. Dies ist vor allem dann zu erwarten, wenn komplexe Such- und Filteranfragen gestellt werden.

Beispiele für Datenübersichten in GeFa mit erwartungsgemäß sehr hohen Trefferzahlen:

• Justizbedienstete (beinhaltet die Justizbediensteten aller Behörden eines ganzen Bundeslandes)
• Poolpersonen (ebenfalls bundeslandübergreifender Katalog häufig an Verfahren beteiligter Personen)
• Termine (je nach dem, wie lange in die Vergangenheit oder in die Zukunft Termine vorgehalten werden, hohe Anzahl möglich)

Um die Systemperformance zu optimieren bzw. Überlastungen im Vorhinein vorzubeugen, wurde ein Limit von 200 Einträgen festgelegt, welche maximal im Frontend von Tabellen und Listen angezeigt werden.

Die Begrenzung hat zur Folge:

• Bei einem Limit von 200 Einträgen werden in paginierten Tabellen und Listen maximal 20 Seiten mit Einträgen angezeigt, die der Nutzer manuell durchblättern kann. (Falls die Anzahl von Einträgen pro Seite, aktuell 10, irgendwann in den Nutzereinstellungen erhöht werden kann, so verringert sich die Seitenzahl entsprechend).
• Welche Einträge auf den ersten 20 Seiten angezeigt werden, wird durch die Sortierung bestimmt (entweder die fachlich vorgegebene Initialsortierung oder eine vom Nutzer geänderte Sortierung). Bei alphabetischer Sortierung könnte es also sein, dass in einer Tabelle nur Personen mit Nachnamen, die mit A und B starten, angezeigt werden.
• Um weitere Einträge sehen zu können, müssen Nutzer durch Suchen oder Filtern die Ergebnismenge einschränken. Ebenfalls möglich ist die Änderung der Sortierung - im vorherigen Beispiel der alphabetisch sortierten Personen wären dann bei umgekehrter Sortierung nur noch die Namen sichtbar, die mit den letzten Buchstaben des Alphabets beginnen.

Damit Nutzenden bewusst ist, dass sie nur einen Auszug aus der Gesamtliste aller Objekte sehen können und niemand fälschlicherweise davon ausgeht, dass es sich um alle Einträge handelt, wird im Fall der Limitierung folgendes an der Tabellen- und Listendarstellung geändert:

• Es erscheint ein zusätzlicher Hinweistext Typ 3 über der Tabelle oder Liste mit folgendem Inhalt: “Hinweis: Es gibt sehr viele Treffer. Hier werden nur die ersten [Anzahl] Einträge dargestellt. Schränken Sie bei Bedarf Ihre Such- und Filterparameter weiter ein.”
• In der Überschrift “[Anzahl]+ Einträge” wird die Anzahl von Tabelleneinträgen über alle Seiten der Paginierung hinweg genannt. Diese kann hier maximal 200 betragen (auch wenn im Backend mehr Einträge existieren). An die Anzahl ist außerdem ein Plus-Zeichen angefügt. Beispiel “200+ Einträge”. Die Überschrift wird Screenreadernutzenden inklusive des Plus-Zeichens bei jeder Trefferaktualisierung ausgegeben, z. B. nach Änderung der Such- oder Filterparameter (Details siehe Ergebnisanzeige bzw. -ausgabe bei Tabellen und Listen).
• Falls die Tabelle oder Liste sich innerhalb eines Tabs befindet, in welchem die Gesamtzahl der enthaltenen Objekte genannt wird (bspw. Verfahrenstab “Beteiligte”), so wird im Tab weiterhin die tatsächliche Gesamtzahl angezeigt und ist diese ist nicht auf 200 begrenzt. Die Zahl im Tab kann also vom Text “[Anzahl] Einträge” über der Tabelle oder Liste abweichen.
• Die Paginierung ist auf maximal 20 Seiten begrenzt. (bzw. weniger, falls irgendwann mehr als 10 Einträge pro Seite angezeigt werden können).
• Auf der letzten Tabellen- bzw. Listenseite wird im Inhaltsbereich unter dem letzten Eintrag eine Hinweiszeile angezeigt, welche erneut erinnert, dass es eigentlich noch mehr Einträge gibt, welche aber an dieser Stelle abgeschnitten sind.

Obwohl 200 als Maximalzahl definiert ist, kann es auch zu geringeren Objektzahlen in Tabellen oder Listen kommen, auch wenn eigentlich noch mehr Einträge existieren. Dies kann vorkommen, wenn nach Absenden einer Such- und Filteranfrage mehrere Tabellen auf der Datenbank zuerst zusammengefügt werde, dann eine Anzahl von 400 Einträgen der zusammengefügten Tabelle abgeschöpft wird und anschließend in der neuen Tabelle erst Duplikate identifiziert und entfernt werden. Gab es viele Duplikate so kann die anschließend ans Frontend übergebene Ergebnistabelle theoretisch auch weniger als 200 Einträge enthalten. Dies ist technisch schwer vorherzusehen bzw. zu verhindern. Jedoch kann mit einem genügend großen Gap zwischen der Menge, die im Backend pro Tabelle abgeschöpft wird und den letztendlich im Frontend angezeigten Einträgen, erreicht werden, dass es möglichst selten zu einer Unterschreitung der 200 Einträge im Frontend kommt. (Falls der Fall noch zu oft vorkommt, so kann die Zahl “400” später noch angehoben werden)

Wichtig: Die Begrenzung der maximalen Trefferzahl gilt nur für Tabellen und Listen. Bei Baumstrukturen müssen – da hier nicht paginiert wird – immer alle Treffer im Frontend angezeigt werden. Bei der Konzeption wurde entsprechend darauf geachtet, dass Datenübersichten mit enorm hohen zu erwartenden Eintragszahlen nicht als Baumstruktur, sondern tabellarisch im Frontend abgebildet werden.
Bei Kalenderansichten wird ebenfalls keine Begrenzung der Treffer auf einer Ansicht (Tages-, Wochen- oder Monatsansicht) vorgenommen.