Filters

Filters define the process instances and tasks that should be returned from the search collection. They are used with a set of keys described in the getQueryProcesses and getQueryTasks articles.

Operators

AND

Used to AND together other operations.

"filter": {
    "AND": [{
        "key": "startedBy",
        "EQ": "timg"
    }, {
        "key": "active",
        "EQ": true
    }]
}

OR

Used to OR together other operations.

"filter": {
    "OR": [{
        "key": "startedBy",
        "EQ": "timg"
    }, {
        "key": "startedBy",
        "EQ": "timsotheruser"
    }]
}

NOT

Used to exclude results of other operations.

"filter": {
    "NOT": {
        "key": "processBusinessKey",
        "EQ": "1878-1732-8992-7336"
    }
}

EQ

Exact matching.

"filter": {
    "key": "businessKey",
    "EQ": "1111-2222-3333-4444"
}

STARTSWITH

Matching the start of a value.

"filter": {
    "key": "businessKey",
    "STARTSWITH": "1111-"
}

ENDSWITH

Matching the end of a value.

"filter": {
    "key": "businessKey",
    "ENDSWITH": "-4444"
}

LIKE

Match any part of a value.

"filter": {
    "key": "businessKey",
    "LIKE": "2222-3333"
}

LT

Return values less than that specified (Non inclusive).

"filter": {
    "key": "startedDate",
    "LT": "2016-12-01T00:00:00Z"
}

GT

Return values greater than that specified (Non inclusive).

"filter": {
    "key": "startedDate",
    "GT": "2019-10-01T00:00:00Z"
}

RANGE

Returns values between the specified range (Inclusive).

"filter": {
    "key": "startedDate",
    "RANGE": ["2019-01-01T00:00:00Z", "2019-12-01T23:59:59Z"]
}

IN

Shorthand operator for OR-ing together operations with a common key.

Supports: EQ, STARTSWITH, ENDSWITH, LIKE

"filter": {
    "key": "startedBy",
    "IN": [{
        "EQ": "thomass"
    }, {
        "LIKE": "anon"
    }]
}

PROCESSVARSCOMBINED

The combined process variables field in the search collection stores the keys and values of any process variables present in a process instance that have been indexed. This operator shifts the context to that key.

Process variables are only indexed if the form fields that supplied them are set as searchable in the "summary form" used by the process instance (the summary form a process uses is named in the _summaryForm process variable). In most cases that will be the form that started the process instance, but a different form can be set on the Workflow - Start Action field.

Process variables that hold objects, strings that look like JSON and null values are not indexed. Strings over 140 characters are not indexed in the PROCESSVARSCOMBINED field, but will be indexed in their own dynamic fields (like other searchable variables). If you use the LIKE operator with PROCESSVARSCOMBINED, the dynamic fields are also automatically searched.

Only string based matching is available within this context, this also means operators such as GT and LT are made lexically so attempting comparisons on numerical values may result in unexpected results. Comparisons of dates stored in formats such as ISO-8601 are still possible as they can be sorted lexically.

This example searches for active process instances that have a variable with a particular value:

"filter": {
    "AND": [{
        "PROCESSVARSCOMBINED": {
            "key": "form_FIELD4",
            "EQ": "test"
        }
    }, {
        "key": "active",
        "EQ": true
    }]
}

This example uses the NOT operator:

"filter": {
    "PROCESSVARSCOMBINED": {
        "NOT": {
            "key": "form_FIELD4",
            "EQ": "default value"
        }
    }
}

This example uses LIKE to search within a process variable field, it would find active results for eg "Central Park" and "Central Avenue":

"filter": {
    "AND": [{
            "PROCESSVARSCOMBINED": {
                "key": "form_SITE",
                "LIKE": "Central"
            }
        },
        {
            "key": "active",
            "EQ": true
        }
    ],
}

If your process variables were created by the submission of a repeating form page, you'll need to know the page and field name that make up the key. For example, a repeating PAGE1 withe a field called NAME could be searched for using:

"filter": {
    "AND": [{
        "PROCESSVARSCOMBINED": {
            "key": "formPage_PAGE1.NAME",
            "EQ": "test"
        }
    }, {
        "key": "active",
        "EQ": true
    }]
}

The filter will match if any of the instances of NAME equal "test". It's not possible to search by specific page instance.

KEYEXISTS

Only used within the PROCESSVARSCOMBINED operator as it's the only field that has dynamic keys. Returns processes that have a process variable key matching that provided.

"filter": {
    "PROCESSVARSCOMBINED": {
        "KEYEXISTS": "form_RADIOGROUP"
    }
}

Alternate Usage

{
    "key": "form_USERNAME"
}

KEYWORD

The following properties are indexed in the process and task body field, and can be searched using the KEYWORD operator. Unlike other operations quotes and whitespace don't get escaped, allowing for exact match searching within the stored values.

Tasks

• Task name (expanded)
• Task description (expanded)
• Process description (expanded)
• Assignee
• Business key

Processes

• Process name (expanded)
• Process description (expanded)
• Started by
• Started by proxy user
• Business key

"filter": {
    "KEYWORD": "\"Waste Crew Review\""
}

KEYWORD key

The keyword operator also supports a "key" property. It is used to query the values of indexed process variables, where "key" is the name of the variable.

"filter": {
    "KEYWORD": "test",
    "key": "form_TESTTEXTAREA"
}

As with PROCESSVARSCOMBINED, process variables are only indexed if the form fields that supplied them are set as searchable in the "summary form" used by the process instance.

The query implements search term stemming, so searching for "test" would match against "testing".

Deprecated

Note that the SEARCH operator that was used with getQueryProcesses against the description has been deprecated in version 1.7.33 of the worker (released 14/04/2021) and replaced with KEYWORD