Page tree
Skip to end of metadata
Go to start of metadata

Saved Searches

A Saved Search is any set of filters and search criteria that you plan to reuse. Users can save searches to find common sets of records, like in progress records assigned to the user or their team. Saved searches are also are used throughout the system for rules, reports, permission filters, linked field filters, and more. There are many ways to use saved searches, but a few of the most important reasons include:

  • Accessing key records in the table view.
  • Filtering source records available in a linked field set.
  • Defining rule conditions that trigger an action.
  • Defining records to be included in a report.

You can access saved searches by hovering over the down arrow to the right of the search button.


Search Drop-down Menu

The Search drop-down menu includes several options for working with saved searches:

  • New: Create a new saved search.
  • Edit: Edit the currently selected saved search.
  • Manage: View or edit the existing saved searches and define which are active, visible in the left pane, and/or appear in the My Assigned menu.
  • Show All: View and manage all saved searches.
  • The links below Show All are existing, active saved searches, available here for quick access. Selecting a saved search from this list applies it to the current table and displays records defined by the search.
Once a saved search has been applied to a table, the name of the search appears next to the table name. This is helpful to identify when you are viewing a set of filtered records. 

Managing Saved Searches

To manage your existing saved searches, navigate to the Search drop-down and select Manage. In the Saved Search screen you can choose which searches should be active, available in the left pane, or available in the My Assigned menu.

  • Active: Displays the search under Show All on the Search drop-down menu.
  • Show in Left Pane: Displays the search under the expanded table name. For example, the My Assigned Tasks search appears under the Tasks table in the left pane when this option is selected for that search.
  • Show in My Assigned: Displays the search under the My Assigned menu for quick access.

See which users created a saved search

In recent releases of Agiloft, the Manage Search screen can be modified to show the user who created each saved search. To do this:

  1. Navigate to a table and select Search > Manage... from the action bar.
  2. In the Manage Search screen, select Views > Edit...
  3. On the Fields tab of the Search wizard, select the Display checkbox next to the Created By field.
  4. Click Finish to save the view.
  5. Click Save and Close to exit the Manage Search screen.

Saved Search Wizard

The Saved Search wizard has four tabs:
  • General: Defines the search criteria.
  • Sorting: Define how the search results are sorted with up to five criteria. The default sorting is by descending ID.
  • Options: Name your search so it can be saved, define summary criteria to display for the results, and choose a specific view to use with the search.
    • Optionally, show statistics like the Total, Minimum, Maximum, and/or Average of selected fields in the records found by the search.
    • Any calculations will appear above the list of results, in the Status area, when running the search. If more than one calculation is shown, each is displayed on its own line.
  • Apply: Seen only by admin users, this defines which groups can access the search and which will see the search on the Search drop-down menu, in the left pane, and on the My Assigned list.

Search Filters

Agiloft supports several types of filters, which can be further combined to create complex expressions. Each time you select a filter a new row appears, and each row represents a separate search condition. You can choose to add one filter or combine many to create a complex search with many conditions.


The search in the screenshot below finds records that fit the following criteria:

  • Records of high or higher priority
  • Last edited more than eight hours ago, according to Company team working hours
  • That changed to the value Reopened
  • Records not yet closed
  • With critical priority
  • Last modified more than one hour ago, according to Company team working hours

Each filter is unique to a specific purpose, but they all contain certain elements, such as:

  • Garbage can icon: Select this icon to eliminate the associated row.
  • Parentheses drop-downs: Located on the left and right end of each row, the parentheses allow you to group criteria and apply the necessary logic when several filters are used. The expressions can be enclosed in brackets to reflect precedence.
  • Up and down arrows: To move a row up or down in the execution order, mouse over the left of the row until the gray arrow appears and click on it.

Most of the filters are defined by existing fields in the table, values, variables, and different types of operators.

  • Fields: Listed in a drop-down menu and limited by the access permissions of the user creating the search.
  • Values: Static values that are defined either by the values available if the field is multi-choice, or by the user with a simple text box. For example, a filter on the Status field might have a value of Assigned, In Progress, or Done to find all records with the desired status.
  • Variables: Values that represent field names. They have a “$” prefix and contain no spaces. For example, a filter on the Assigned To field might use the variable $updated_by to assign a record to the user in the Updated By field.
    • Global Variables: Values stored in predefined formats that usually match a user record field value of the logged in user. They have a "$global" prefix and contain no spaces. For example, a filter on the Assigned To field might use the global variable $global.my_full_name to assign a record to the currently logged in user.


Simple filters are used to search records for a particular value within a field.

Simple filters must include...

  • A field in the record, listed alphabetically in the first drop-down list.
  • A comparison operator: =, !=, >, <, etc.
  • A value or formula.


  • Simple searches run on a default search field denoted by -TEXT-; the -TEXT- field searches all text fields within a record, including attached searchable files.  Searchable files include .doc, .docx, .txt, and non-image .pdf.
  • The appropriate selection of operators and values is provided automatically based on the type of field selected.
    • Example: Selecting a date field changes the drop-down list to a calendar of dates.
  • Choice fields are listed in descending order.


    If the priority list uses the following order...

    • Very High
    • High
    • Medium
    • Low

    A search for Priority >= Medium will find Very High, High, and Medium.

    The same search with the following priority list...

    • Low
    • Medium
    • High
    • Very High

    Returns records with a priority of Medium or Low.

  • The Now checkbox searches for records that currently hold the specified value. De-selecting the checkbox searches for records that have fulfilled the criteria at any point in time. When Now is de-selected, the system is forced to search history. Historical searches take more time and resources, but they can be useful, especially when combined with the Advanced search criteria.


    If the Now box is checked, a search for "Priority = High" returns records that have a priority of High at the present time. If the "Now" box is unchecked, the search returns all records that have ever had a priority of High. Example: Two records are created with "Urgent" Priority.

      • Record One: The record is closed.  The priority of the record remains "Urgent".
      • Record Two: The record is closed.  Later, a staff member returns to mark the priority as "Low".
      • Searching for records with urgent priority whose status has changed from anything to closed returns only Record One. The same search with the "Now" box unchecked returns both records.


Time filters search on periods of elapsed time relative to a specific field in order to find time stamps within or outside of some period relative to now.

Time filters must include...

  • A field in the record with a Date/Time, Date, Time, or an Elapsed Time data type.
  • A comparison operator: =, !=, >, <, etc.
  • A numerical amount of time.
  • A unit of time, ranging from minutes to years.
  • Whether to search in the past or look for future times.


  • The anchor point of a time filter is the field itself. The amount of time specified is an integer.
    • Example: Date Created is less than or equals to 5 hours old. If it's 5 pm when the search is run, it will find all records created from 12 pm and later.
  • Field selection includes all date, time, and date/time fields accessible to the user creating the search. The time units list includes past and future values ranging from minutes to years.
  • You can choose to limit your search to the working or non-working hours of a particular team, or you can choose a field in the record where a team is specified. This is useful for escalations for companies that only include business hours in service level agreements. When creating searches based on working hours, you should usually use the Hours operator, not Days. A "day" is defined as 24 hours, so if working hours are 9 am to 5 pm, and a search uses 1 day old, it will take three days to reach the criteria.

    • Example: If a ticket is submitted at 4:50 pm and should be escalated to a manager after one working hour, using a search in which Date Created is more than one hour old and checking the option to include only the working hours of a team, that has working hours from 9 to 5 pm, will result in the ticket being found only when the search is run after 9:50 am the next day.

  • Because of the way the Agiloft system stores time, searches on a range of times are more easily handled with the Calendar filter, discussed in more detail below.

Because Date fields store a hidden time value, avoid using an operator of equals when searching on a Date field.


Calendar filters are used to find records within or outside of a given calendar period. They are useful for finding records within a specified calendar time frame and are most often used in reporting.

Calendar filters must include...

  • A field in the record with a Date/Time, Date, Time, or an Elapsed time data type.
  • A comparison operator:   =, !=, >, <, etc.
  • An increment of time.
  • A unit of time, ranging from minutes to years.


  • Calendar weeks run Sunday through Saturday.
  • You can choose to search calendar times based on the internal KB time or the user's current time zone. The default calendar filter uses internal KB time.

  • The search returns results for any records whose day/time falls within the entire time range.
    • Example: Date Created is equal to last month. If the search is run on March 15, the filter will return records created from February 1 to February 28.
  • Because of the way the Agiloft system stores time, searches on Elapsed Time fields are best handled through a Time filter.


Advanced filters provide the ability to find records in which a specific field...

  • Did not change during the last modification.
  • Changed from any value to any value.
  • Changed from any value to one or more specific values or from one or more specific values to any other value.
  • Changed from one or more specific values to some other one or more specific values.

Advanced filters must include...

  • A field in the record, listed alphabetically in the first drop-down list.
  • A defining operator.
  • Selection of options for defining whether or not the record changed and how.


  • Two main operators are used for how the change occurred.
    • Last User’s Modification looks for changes made by a user. Even if other rules intervene and make additional changes, if the change was part of the last user’s change, it will be found.
    • Last Modification looks at the last change, whether made by a user or a rule.
  • Two less commonly used operators can also be used for how the change occurred:
    • Earliest looks for changes that have occurred since the date of the earliest record found.
    • Last looks for changes in the time period specified in the last two fields, such as the last 2 minutes, hours, days, weeks, months, or years.
  • Settings include the option to search for a Choice or Numeric field changing from a set of specified values to another set of specified values. Users can select in which period of time the change must have occurred.
    • Example: Records whose priority changed from Low or Medium to High in the last two weeks.
  • Only fields tracked by history will be available for an advanced filter.

Related Table

Related table filters are used to run searches on related tables and linked fields.

Related table filters must include...

  • A field in the record with a related table or linked field data type.
  • A comparison operator: contains or does not contain.
  • A preexisting saved search.


  • This filter is not used frequently, but it is important in certain situations because you cannot search within records in a related table using the normal search filters.
  • Related table filters only run on existing saved searches in the target table. There is no option to create a saved search for a different table within the active table.


    A saved search for Assets whose Contracts were renewed in the last three months.

    • In the example above, Assets and Contracts are two different tables.
    • In order to run the search as described, a previous saved search in the Contracts table named "Contracts renewed in the Last 3 Months" must already exist.
    • The Asset table must have linked fields to the Contracts table.
    • Once the Asset table is open, a related table filter can be applied to the linked fields in the Contracts table with the "Contracts renewed in the Last 3 Months" saved search.

    Note: While the same search can be accomplished using one or many simple filters, for large tables a related table filter is more efficient.


Run-time filters return search results based on a user-input value. They create pop-ups which allow users to define some criteria at run-time on a pre-configured search. They are useful for reports and ad hoc searching because the user-input aspect provides flexibility.

Run-time filters must include...

  • A field in the table.
  • A defining operator.


  • Other search criteria can be predefined, such as date range, status, etc. so the user is only asked for one criteria out of several.


    The search "All Support Cases related to one company with a status of Active" can be run in one particular instance using a simple filter. However, if the search must be executed for each company, there must be a different saved search for each company. Instead of creating a different search for each individual company using a simple filter, a run-time filter should be used. This requires only one saved search to be created.

    When the search below is run, a pop-up appears that allows the user to type in the desired company. 

  • It is also possible to use run-time filters for choice and linked fields. In the Saved Search wizard, the options "is contained in, <<" and "is not contained in, !<<" allow the user to select multiple values from the field at run-time. For example, you could select the values Updated by Customer and Pending Customer when the search is run to find only records with those statuses.

    • De-selecting the checkbox in the pop-up screen automatically changes the filter to search for any value.

    • This option also works with Charts/Reports. When a saved search that includes a run-time filter is applied to a chart/report, the user is given the option to select any of the choice or linked values when the report is previewed or run.

  • Example

    A run-time search that uses the filter "is not contained in" for Status, with the values Open and In Progress selected, would return records on all statuses except Open and In Progress.


Duplicate filters are used to search records for duplicate values.

Duplicate filters must include...

  • A field in the record, listed alphabetically in the search bar.
  • A whole number to identify number of matches required, which must be at least 2 or greater.


  • Duplicate filters help find duplicate records so they can be eliminated. However, there is currently no way to merge records when duplicates are found. Cleaning up duplicates is a manual process.
  • They allow you to exclude a certain number of records from the results.


    Consider a saved search for companies who have three or more expired contracts.

    • In this case, the matching field is Contract Status and the duplicate filter is set to report if there are three or more matches in the Contract Status field.
  • There can be only one filter of either the Duplicate or the First/Last filter type.


First/last filters search records for the first or last records, based on the specified number of matches. This filter is similar to the duplicate filter but allows you to limit the results found based on a sort order.

First/last filters must include...

  • A field in the record, listed alphabetically in the search bar.
  • A whole number to identify number of matches.


  • The first/last filter applies the order defined on the Sorting tab.


    Consider a saved search for the most recent contract signed by a specific partner company.

    • In this case, the matching field is Date Signed and the first/last filter is set to report on the first match.

Saved Searches and Default Values

Adding a filter on a field that is set by a default value can compromise the behavior of the default value. Sometimes this is intentional, but in case it is not, you should be aware of the ramifications.


You might set the Assigned Person for a support case to the person who created it, but filter it to only members of the Support Team. If a customer creates the case, it will not be assigned to them because they are not on the Support Team, but if a support person creates the case, they will be assigned to it automatically. In the case of the customer creating the case, the default value simply would not be set.

The previous scenario may be intentional, but if support people only work on cases in which they are the Assigned Person, this could cause problems. If so, one solution would be to add another filter that sets the default value of the Assigned Person to the support lead if the person who created the case is not on the Support Team. The support lead could then reassign the case as desired.

Saved Search Tips

  • When creating saved searches for different purposes, use one of the following letter prefixes to define the search. This allows the search's purpose to be quickly identified.
    • C: Used in a chart of report
    • R: Used in a rule
    • P: Used in a group permission definition as a filter
    • F or LF: Used to filter the available records in a linked field set or in a related table
    • CF: Used in a calculation field
    • MT: Multi-table, used to compare a value in the current record to a value in a linked table; used as a filter for a linked field.  
  • Any search created for one of the above purposes should be made available to the admin group. Searches are typically made active for the admin group as well. If a search is not made available to users in a certain group, it does not show up under the Manage menu from the Search options.
  • Renaming saved searches can be difficult. If you are trying to rename a saved search from within a rule or certain other places, you must instead create an entirely new search. If you do need to rename a search, do so from the Search > Manage... drop-down option on the table search block. This method gives the search the new name in any rules that are using it.