2024:AI Search and the Search Page

2025 BETA

This article covers new or changed functionality in the current or upcoming beta version of Grooper. Features are subject to change before version 2025's GA release. Configuration and functionality may differ from later beta builds and the final 2025 release.

You may download the ZIP(s) below and upload it into your own Grooper environment (version 2024). The first contains one or more Batches of sample documents. The second contains one or more Projects with resources used in examples throughout this article. Media:2024_Wiki_Azure-AI-Search_Batch.zip Media:2024_Wiki_Azure-AI-Search_Project.zip

Glossary

Activity Processing Concept: Activity Processing is the execution of a sequence of configured tasks which are performed within a settings Batch Process to transform raw data from documents into structured and actionable information. Tasks are defined by Grooper Activities, configurated to perform document classification, extraction, or data enhancement.

Activity Processing Service: Activity Processing is a Grooper Service that executes Activities assigned to edit_document Batch Process Steps in a settings Batch Process. This allows Grooper to automate Batch Steps that do not require a human operator.

Activity: Grooper Activities define specific document processing operations done to a inventory_2 Batch, folder Batch Folder, or contract Batch Page. In a settings Batch Process, each edit_document Batch Process Step executes a single Activity (determined by the step's "Activity" property).

• Batch Process Steps are frequently referred by the name of their configured Activity followed by the word "step". For example: "Classify step".

AI Analyst: BE AWARE: AI Analysts are obsolete as of version 2025. See AI Assistant for the new and improved version of AI Analyst. An AI Analyst facilitates the ability to interact with a document as you might with an AI chatbot.

AI Search: AI Search is a Repository Option that enables Grooper's document search and retrieval features in the Search page. Once enabled, Indexing Behaviors can be added to Content Types (such as stacks Content Models), which will allow users to submit documents to a search index. Once indexed, documents can be retrieved by full text and metadata searches in the Search Page.

Azure AI Search: {{#list:Glossary|Azure AI Search}}

Batch Folder: The folder Batch Folder is an organizational unit within a inventory_2 Batch, allowing for a structured approach to managing and processing a collection of documents. Batch Folder nodes serve two purposes in a Batch. (1) Primarily, they represent "documents" in Grooper. (2) They can also serve more generally as folders, holding other Batch Folders and/or contract Batch Page nodes as children.

• Batch Folders are frequently referred to simply as "documents" or "folders" depending on how they are used in the Batch.

Batch Process: settings Batch Process nodes are crucial components in Grooper's architecture. A Batch Process is the step-by-step processing instructions given to a inventory_2 Batch. Each step is comprised of a "Code Activity" or a Review activity. Code Activities are automated by Activity Processing services. Review activities are executed by human operators in the Grooper user interface.

• Batch Processes by themselves do nothing. Instead, they execute edit_document Batch Process Steps which are added as children nodes.
• A Batch Process is often referred to as simply a "process".

Batch: inventory_2 Batch nodes are fundamental in Grooper's architecture. They are containers of documents that are moved through workflow mechanisms called settings Batch Processes. Documents and their pages are represented in Batches by a hierarchy of folder Batch Folders and contract Batch Pages.

Behavior: A "Behavior" is one of several features applied to a Content Type (such as a description Document Type). Behaviors affect how certain Activities and Commands are executed, based how a document (folder Batch Folder) is classified. They behave differently, according to their Document Type. This includes how they are exported (how Export behaves), if and how they are added to a document search index (how the various indexing commands behave), and if and how Label Sets are used (how Classify and Extract behave in the presence of Label Sets).

• Each Behavior is enabled by adding it to a Content Type. They are configured in the Behaviors editor.
• Behaviors extend to descendent Content Types, if the descendent Content Types has no Behavior configuration of its own.
  • For example, all Document Types will inherit their parent Content Model's Behaviors.
  • However, if a Document Type has its own Behavior configuration, it will be used instead.

Content Model: stacks Content Model nodes define a classification taxonomy for document sets in Grooper. This taxonomy is defined by the collections_bookmark Content Categories and description Document Types they contain. Content Models serve as the root of a Content Type hierarchy, which defines Data Element inheritance and Behavior inheritance. Content Models are crucial for organizing documents for data extraction and more.

Content Type: Content Types are a class of node types used used to classify folder Batch Folders. They represent categories of documents (stacks Content Models and collections_bookmark Content Categories) or distinct types of documents (description Document Types). Content Types serve an important role in defining Data Elements and Behaviors that apply to a document.

Data Element: Data Elements are a class of node types used to collect data from a document. These include: data_table Data Models, insert_page_break Data Sections, variables Data Fields, table Data Tables, and view_column Data Columns.

Data Model: data_table Data Models are leveraged during the Extract activity to collect data from documents (folder Batch Folders). Data Models are the root of a Data Element hierarchy. The Data Model and its child Data Elements define a schema for data present on a document. The Data Model's configuration (and its child Data Elements' configuration) define data extraction logic and settings for how data is reviewed in a Data Viewer.

Document Type: description Document Type nodes represent a distinct type of document, such as an invoice or a contract. Document Types are created as child nodes of a stacks Content Model or a collections_bookmark Content Category. They serve three primary purposes:

1. They are used to classify documents. Documents are considered "classified" when the folder Batch Folder is assigned a Content Type (most typically, a Document Type).
2. The Document Type's data_table Data Model defines the Data Elements extracted by the Extract activity (including any Data Elements inherited from parent Content Types).
3. The Document Type defines all "Behaviors" that apply (whether from the Document Type's Behavior settings or those inherited from a parent Content Type).

Execute: tv_options_edit_channels Execute is an Activity that runs one or more specified object commands. This gives access to a variety of Grooper commands in a settings Batch Process for which there is no Activity, such as the "Sort Children" command for Batch Folders or the "Expand Attachments" command for email attachments.

Grooper Command Console: Grooper Command Console is a command-line interface that performs system configuration and administration tasks within Grooper.

Grooper Repository: A Grooper Repository is the environment used to create, configure and execute objects in Grooper. It provides the framework to "do work" in Grooper. Fundamentally, a Grooper Repository is a connection to a database and file store location, which store the node configurations and their associated file content. The Grooper application interacts with the Grooper Repository to automate tasks and provide the Grooper user interface.

Indexing Behavior: An Indexing Behavior allows documents (folder Batch Folders) to be indexed via AI Search. Once indexed, users can search for and retrieve documents from the Search Page.

Indexing Service: An Indexing Service is a Grooper Service that periodically polls the Grooper database to automate AI Search indexing. It checks to see if any documents in a Grooper Repository are classified as a Document Type that inherit from a Content Type configured with an Indexing Behavior. If there are any, and they need to be added, updated, or deleted to/from the search index, the Indexing Service will submit an "Indexing Job" to be picked up by an Activity Processing service.

Machine: computer Machine nodes represent servers that have connected to the Grooper Repository. They are essential for distributing task processing loads across multiple servers. Grooper creates Machine nodes automatically whenever a server makes a new connection to a Grooper Repository's database. Once added, Machine nodes can be used to view server information and to manage Grooper Service instances.

Project: package_2 Projects are the primary containers for configuration nodes within Grooper. The Project is where various processing objects such as stacks Content Models, settings Batch Processes, profile objects are stored. This makes resources easier to manage, easier to save, and simplifies how node references are made in a Grooper Repository.

Recognize: format_letter_spacing_wide Recognize is an Activity that obtains machine-readable text from contract Batch Pages and folder Batch Folders. When properly configured with an library_booksOCR Profile, Recognize will selectively perform OCR for images and native-text extraction for digital text in PDFs. Recognize can also reference an perm_mediaIP Profile to collect "layout data" like lines, checkboxes, and barcodes. Other Activities then use this machine-readable text and layout data for document analysis and data extraction.

Repository Option: Repository Options are optional features that affect the entire repository. These optional features enable functionality that otherwise do not work without first establishing the connections these options provide. Repository Options are added to a Grooper Repository and configured using the database Root node's Options property.

Repository: A "repository" is a general term in computer science referring to where files and/or data is stored and managed. In Grooper, the term "repository" may refer to:

• PRIMARILY a Grooper Repository. This is most commonly what people are referring to when they simply say "repository".
• Less commonly a CMIS Repository

Scope: The Scope property of a edit_document Batch Process Step, as it relates to an Activity, determines at which level in a inventory_2 Batch hierarchy the Activity runs.

Service: Grooper Services are various executable programs that run as a Windows Service to facilitate Grooper processing. Service instances are installed, configured, started and stopped using Grooper Command Console (or in older Grooper versions, Grooper Config).

About

Put simply, Azure AI Search will make it easier to store and retrieve your documents in Grooper. To understand how, let's first understand what Grooper has been.

Historically Grooper has been a transient platform for document processing:

• documents come in
• data is collected from those documents
• the data and documents are pushed out of Grooper to some place

It has never been a place to store documents and/or their data.

While it has been possible to keep Batches and their content in Grooper it has never been a best practice, nor has it been convenient to do so. You could, theoretically, devise some kind of hierarchical folder and naming convention by which you organize Batches in the node tree, but this is very time consuming and is probably not even that useful. Say you wanted to retrieve all "Invoices" that have a "Total Amount" over "$1,000.00". Without "indexing" the documents and their data, and the ability to "query" that index, this would be extremely time consuming at best, even if they're nicely organized. The criteria by which you organize something one day might not align with the method by which you choose to search for them later.

By using Grooper's implementation of Azure AI Search you will be able to quickly and efficiently index your documents and their data to allow for ease of retrieval as well as gain a deeper understanding of them.

Microsoft Azure AI Search

Azure AI Search, formerly known as Azure Cognitive Search, is a cloud-based search-as-a-service solution provided by Microsoft Azure. It has allowed our developers to build a sophisticated search experience into Grooper. Here are some key features and capabilities:

• Full-Text Search: Azure AI Search supports full-text search with capabilities like faceting, filtering, and scoring, allowing users to search through large volumes of text efficiently.
• Customizable Indexing: Developers can define custom indexes tailored to their specific data schema. This flexibility allows for a more relevant and precise search experience.
• Scalability: The service can scale up or down based on the workload, making it suitable for applications of all sizes.
• Security and Compliance: Azure AI Search ensures data security and compliance with industry standards, offering features like role-based access control (RBAC), data encryption, and integration with Active Directory.
• APIs and SDKs: Azure AI Search provides REST APIs and client libraries for various programming languages, making it easy to integrate with different types of applications.

Integration with Grooper

• API Integration: Grooper can leverage Azure AI Search's REST APIs to automate the indexing of documents and retrieval of search results. This integration can be built into Grooper's workflow to ensure seamless data processing and search capabilities.
• Security and Compliance: Both Grooper and Azure AI Search offer robust security features. Integrating these ensures that document processing and search operations are secure and compliant with industry standards.
• Indexing Processed Documents: Once Grooper processes and extracts data from documents, this data can be sent to Azure AI Search for indexing. This allows users to search through the processed data quickly and efficiently.
  • Indexing is an intake process that loads content into Azure AI Search service and makes it searchable. Through Azure AI Search, inbound text is processed into tokens and stored in inverted indexes, and inbound vectors are stored in vector indexes. The document format that Azure AI Search can index is JSON.
• Querying Indexed Documents and Data: Once Azure AI Search has indexed documents and their data from Grooper, user's can leverage powerful query syntax like Lucene and OData to efficiently retrieve the information from their documents.
  • Querying can happen once an index is populated with searchable content, when Grooper sends query requests to a search service and handles responses. All query execution is over a search index that you control.

How To

Using Azure AI Search will require a few setup steps:

1. Create an Azure AI Search Service
   • This is the only step done outside of Grooper.
2. Configure the AI Search Repository Option
3. Configure an Indexing Behavior on a Content Type
4. Create the Search Index
5. Index Documents and Data from Grooper
6. Use the Search Page

Create an Azure AI Search Service

• The following article from Microsoft instructs users how to create a Search Service:

  https://learn.microsoft.com/en-us/azure/search/search-create-service-portal

• Microsoft's full Azure AI Search documentation is found here:

  https://learn.microsoft.com/en-us/azure/search/

• You will need the Azure AI Search service's "URL" and either "Primary admin key" or "Secondary admin key" to Configure the AI Search Repository Option. These values can be found by accessing the Azure Search service from the Azure portal.

• Check the "Configure authentication" section of the "Create an Azure AI Search service in the portal" linked above.

Configure the AI Search Repository Option

To search documents in Grooper, we use Azure's AI Search service. In order to connect to an Azure AI Search service, the AI Search option must be added to the list of Repository Options in Grooper. Here, users will enter the Azure AI Search URL endpoint where calls are issued and an admin's API key. Both of these can be obtained from the Microsoft Azure portal once you have added an Azure AI Search resource.

With AI Search added to your Grooper Repository, you will be able to add an Indexing Behavior to one or more Content Types, create a search index, index documents and search them using the Search Page.

1. Select the root object in the node tree.
2. Click the ellipsis button on the Options property.
3. Click the "Add" button in the "Options" window.
4. Select AI Search from the drop-down menu.

5. Enter the Azure AI Search URL into the URL property.
6. Add your Azure AI Search API key to the API Key property.
7. Click the "OK" button to close the "Options" window.
8. Click the "Save" button to save all changes.

Configure an Indexing Behavior on a Content Type

Before indexing documents, you must add an Indexing Behavior to the Content Types you want to index. Most typically, this will be done on a Content Model. All child Document Types will inherit the Indexing Behavior and its configuration (More complicated Content Models may require Indexing Behaviors configured on multiple Content Types).

The Indexing Behavior defines:

General

• The index's Name in Azure.
• Which documents are added to the index.
  • Only documents who are classified as the Indexing Behavior's Content Type OR any of its children Content Types will be indexed.
  • In other words, when set on a Content Model only documents classified as one of its Document Types will be indexed.
• What Included Elements are added to the search index (including which Data Elements from a Data Model are included, if any).
• What Built in Fields are added to the search index. Note, if you leverage any of these built in fields and also want to use Included Elements there cannot be naming conflicts between the Included Elements and the Built in Fields. The Built in Fields are typical meta-data points including:
  • Content: Index the full text content of the document. This would be the text generated by the Recognize activity.
  • Attachment Name: Index the document's attachment filename. This would be the original name of the file as it existed before being acquired by Grooper.
  • Type Name: Index the name of the document's Content Type.
  • Page Count: Index the number of pages within the document.
  • Flag Message: Index the flag message associated with the document. This would include auto-generated messages like whether or not "required" fields were empty, a type of validation error, or even null.
  • Path: Index the path in the "Batches" folder of the node three where the document exists.
  • All: Enable all Built in Elements.
• Page Limit: The maximum number of page to include when indexing the full text content of a document.
• Flatten: Specifies that the search index should be flattened. "Flattening" a search index generally refers to the process of transforming a hierarchical or nested data structure into a flat, non-hierarchical structure. In the context of a search index, this could involve several different actions depending on the specific needs and the data structure being indexed.
• Auto Index: If set, specifies that the Indexing Service should automatically add new documents to this search index. When not set, the Indexing Service will still remove deleted documents and update changed documents already in the search index.

Search Page Options

• Access List: If set, specifies a restricted set of users who may search this index. If not set, all authenticated users may search this index.
• AI Analysts: An optional list of AI Analysts available for chat sessions regarding the search result set.
• Generators: An optional list of AI Generators to be available for generating documents from the search result set. This is a collection of LLM Models, Instructions, and Examples that define how an AI would structure said documents.

1. Select the Content Model from the provided Project.
2. Click the ellipsis button for the Behaviors property.
3. In the "Behaviors" window click the "Add" button.
4. Select Indexing Behavior from the drop-down menu.

5. An Indexing Behavior will be added to the collection.
6. For our purposes the bulk of the properties can be left to their default setting. The only thing we'll change is the Included Elements property. Click the ellipsis button for this property.
7. In the "Included Elements" window ALT+LeftClick the Content Model to select it and all child elements.
8. Click the "OK" button to close the "Included Elements" window.
9. Click the "OK" button to close the "Behaviors" window.
10. Be sure to save all changes.

Create the Search Index

This will create the search index in Azure. Without the search index created, documents can't be added to an index. This only needs to be done once per index.

1. Right-click on the Content Model from the provided Project.
2. Choose "Search > Create Search Index" from the pop-out menu.
3. Click the "Execute" button in the "Create Search Index" window.

4. If you navigate to your Azure AI Search resource in a web browser...
5. ...and go to your indexes...
6. ...you will see a new index named after the Name property of the Indexing Behavior of the Content Type this command was used against.

Index Documents and Data from Grooper

With the search index created you can now add data to the search index. Documents must be classified in Grooper before they can be indexed. Only Document Types/Content Types inheriting an Indexing Behavior are eligible for indexing.

"Add to Index" Batch Folder Object Command

This is the most manual way of adding to the search index. This is an object command done on a per document basis (or via multi-selecting) in a Batch Viewer.

1. Select the provided Batch from the node tree.
2. Click on the "Viewer" tab.
3. Notice that the document in this Batch is classified as a Document Type that is inheriting from the Content Model with the Indexing Behavior.
4. Right-click on the document from the provided Batch in the Batch Viewer.
5. Select "Search > Add To Index" from the pop-out menu.
6. Click "Execute" in the "Add to Index" window.

7. Navigate to your Azure AI Search resource in a web browser.
8. Click the "Indexes" button.
9. Click on the listed index in use.

10. Click the "Search" button to perform an open query.
11. You should see the JSON results of the performed query in the "Results" portion of the site.z

"Submit Indexing Job" Content Type Object Command

This is another manual approach as it also involves an object command. Because this command is applied to a Content Type, however, it will index all documents that are classified as that Content Type or inherit from it.

First things first, we need to make sure an Activity Processing Service is running for our repository.

1. If you click on the "Machines" folder in the node tree...
2. ...and select the Grooper server where your repository is hosted...
3. ...you should see an Activity Processing Service is installed and running.
   • If you do not see the appropriate service for your repository of Grooper, please visit the Grooper Command Console article for information on installing the appropriate service.

Once you've confirmed an Activity Processing Service is installed and running, you can use the "Submit Indexing Job" object command.

4. Right-click the Content Model from the provided Project.
5. Select "Search > Submit Indexing Job" from the pop-out menu.
6. Take note of the "Added Documents", "Updated Documents", and "Deleted Documents" properties.
7. Click the “Execute” button in the “Submit Indexing Job” window.
   • If there are no “added”, “updated”, or “deleted” documents, the window will close and no job will be submitted.
   • If there are, however, an “Indexing Job” will be created and the active “Activity Processing Service” will complete the tasks of the job to update the index.

Execute Activity with "Add to Index" Command

This is an automated approach as it will create an "Indexing Job" as part of a Batch Process. This will perform the exact same command as the "Add to Index" object command explained earlier. When an Execute step is reached in a Batch Process a job will be created with a task for each document in scope.

• Keep in mind, if the document in scope does not need to be added, updated, or deleted, no task will be created. If that is true for all documents in scope, no job will be created.
• Also keep in mind that an Activity Processing Service will need to be installed and running for the given repository in order for the job to be picked up and worked.

1. Right-click the provided Project.
2. Select "Add > Batch Process" from the pop-out menu.
3. Name the Batch Process.
4. Click the "Execute" button from the "Add" window.

5. Right-click on the newly created Batch Process.
6. Select "Add Activity > Utilities > Execute" from the pop-out menu.
7. The step will be named based on the Activity chosen.
8. Click the "Execute" button in the "Add Activity" window.

9. Set the Scope and Folder Level properties.
• For our purposes a Scope of Folder, and a Folder Level of 1 are accurate.
10. Click the ellipsis button for the Steps property.
11. Click the "Add" button in the "Steps" window.
12. Choose Execute Command from the drop-down window.

13. This will add an "Execute Command" to the collection of "Steps".
14. Click the drop-down button for the Command property.
15. Select Batch-Folder > Add to Index from the drop-down menu.
16. Click the "OK" button from the "Steps" window.
17. Be sure to save all changes.

18. Click on the "Activity Tester" tab.
19. Select the document from the provided Batch in the "Batch Viewer".
20. Click the "Start" button to create an "Indexing Job" for the selected document.

Indexing Service

This is the most automated way to index documents. The Indexing Service will periodically poll the Grooper database to determine if classified documents that inherit from a Content Type with an Indexing Behavior need to be added, updated, or deleted. If it does, it will submit an "Indexing Job" with tasks for each document that needs to be added, updated, or deleted.

Keep in mind how the Auto Index property of an Indexing Behavior described above affects this service.

• If set: will add, update, and/or remove documents from the index
• If not set: will only remove deleted documents or update changed documents already in the search index

Also keep in mind:

• an Indexing Service will need to be installed and running for the given repository in order for the job to be "Indexing Job" to be created.
• an Activity Processing Service will need to be installed and running for the given repository in order for the job to be picked up and worked

First things first, we need to make sure an Indexing Service and an Activity Processing Service are running for our repository.

1. If you click on the "Machines" folder in the node tree...
2. ...and select the Grooper server where your repository is hosted...
3. ...you should see an Activity Processing Service is installed and running.
   • If you do not see the requisite services for your repository of Grooper, please visit the Grooper Command Console article for information on installing the appropriate services.

At this point there's nothing really left to do but let the service poll the database and look for updates to submit to the index.

Use the Search Page

Once you've got indexed documents, you can start searching for documents in the search index! The Search page allows you to find documents in your search index.

The image below gives an overview of the Search page interface.

• Use the following elements to perform the query in this image to get a result with the setup configured so far:
  • Search:

    invoiceNO: 1*

  • Filter:

    invoiceDate ge 2022-01-01 and invoiceDate le 2024-01-31

  • Select:

    totalAmount

  • Order By:

    poNumber

• Once the provided inputs are entered into the appropriate fields, click the magnifying glass button to perform the query.
• Once the query has been executed, select the returned document from the bottom portion of the Search page's UI, the portion "that displays query results".
• Once selected you should see the result appear in the document viewer.

Continue reading for more information on these individual fields of the Search page.

The Search page allows you to build a search query using four components:

• Search: This is the only required parameter. Here, you will enter your search terms, using the Lucene query syntax.
• Filter: An optional filter to set inclusion/restriction criteria for documents returned, using the OData syntax.
• Select: Optionally selects which fields you want displayed for each document.
• Order By: Optionally orders the list of documents returned.

Search

The Search configuration searches the full text of each document in the index. This uses the Lucene query syntax to return documents. For a simple search query, just enter a word or phrase (enclosed in quotes "") in the Search editor. Grooper will return a list of any documents with that word or phrase in their text data.

Lucene also supports several advanced querying features, including:

• Wildcard searches: ? and *

  Use ? for a single wildcard character and * for multiple wildcard characters.

• Fuzzy matching: searchTerm~

  Fuzzy search can only be applied to terms. Fuzzy searched phrases should not be enclosed in quotes. Azure's full fuzzy search documentation can be found here: https://learn.microsoft.com/en-us/azure/search/search-query-fuzzy

• Regular expression matching: /regex/

  Enclose a regex pattern in backslashes to incorporate it into the Lucene query. For example, /\d{3}[a-z]/

• Boolean operators: AND OR NOT

  Boolean operators can help improve the precision of search query.

• Field searching: fieldName:searchExpression

  Search built in fields and extracted Data Model values. For example, Invoice_No:8* would return any document whose extracted "Invoice No" field started with the number "8"

Azure's full documentation of Lucene query syntax can be found here: https://learn.microsoft.com/en-us/azure/search/query-lucene-syntax

Filter

First you search, then you filter. The Filter parameter specifies criteria for documents to be included or excluded from the search results. This gives users an excellent mechanism to further fine tune their search query. Commonly, users will want to filter a search set based on the field values. Both built in index fields and/or values extracted from a Data Model can be incorporated into the filter criteria.

Azure AI Search uses the OData syntax to define filter expressions. Azure's full OData syntax documentation can be found here: https://learn.microsoft.com/en-us/azure/search/search-query-odata-filter

The query paramters entered above in the example included a filter:

invoiceDate ge 2022-01-01 and invoiceDate le 2024-01-31

This is actually OData syntax, but a bit shortened. The Search page UI is making it a bit easier by not having to specificy the filter syntax. If so, in OData it would look specifically like the following:

$filter=invoiceDate ge 2022-01-01 and invoiceDate le 2024-01-31

This query therefore is filtering by the "invoiceData" Data Element for results greater than January 1st, 2022 and less than January 31st, 2024.

Select

The Select parameter defines what field data is returned in the result list. You can select any of the built in fields or Data Elements defined in the Indexing Behavior. This can be exceptionally helpful when navigating indexes with a large number of fields. Multiple fields can be selected using a comma separated list (e.g. Field1,Field2,Field3)

Like Filter field above, Select is shortening the OData syntax for us. In the example it was:

totalAmount

In strict OData syntax it would be:

$select=totalAmount

Order By

Order By is an optional parameter that will define how the search results are sorted.

• Any field in the index can be used to sort results.
• The field's value type will determine how items are sorted.
  • String values are sorted alphabetically.
  • Datetime values are sorted by oldest or newest date.
  • Numerical value types are sorted smallest to largest or largest to smallest.
• Sort order can be ascending or descending.
  • Add asc after the field's name to sort in ascending order. This is the default direction.
  • Add desc after the field's name to sort in ascending order.
• Multiple fields may be used to sort results.
  • Separate each sort expression with a comma (e.g. Field1 desc,Field2)
  • The leftmost field will be used to sort the full result list first, then it's sub-sorted by the next, then sub-sub-sorted by the next, and so on.