{"id":45175,"date":"2026-06-20T18:32:18","date_gmt":"2026-06-20T16:32:18","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=45175"},"modified":"2026-06-20T18:32:20","modified_gmt":"2026-06-20T16:32:20","slug":"m-files-bd-queries-objecttype-class-filters-date-tokens","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/m-files-bd-queries-objecttype-class-filters-date-tokens\/","title":{"rendered":"M-Files BD – Queries: objectType, class, filters, date tokens"},"content":{"rendered":"\n

In the previous posts of this series, I covered the anatomy of a dashboard definition<\/a> and the seven widget types (KPI & gauge<\/a>, line & area<\/a>, donut, bar & table<\/a>) the engine supports, as of now. In this one, we will go through the Business Dashboard queries, i.e. the query<\/em><\/strong> section that I pretty much ignores so far. It is now time to look at it a bit more.<\/p>\n\n\n\n

A query has four parts: objectType<\/em><\/strong>, class<\/em><\/strong>, filters<\/em><\/strong>, and aggregation<\/em><\/strong>. This post covers the first three. The fourth (aggregations, including its reducers) is the topic of the next post.<\/p>\n\n\n\n

As mentioned before, the principle that drove the design of the Business Dashboard is to be generic<\/strong>. The engine never enumerates specific business values, it only translates the structured JSON query into a standard M-Files server search.<\/p>\n\n\n\n

1. objectType – the M-Files object type to query<\/h2>\n\n\n\n

Every query starts with objectType<\/em><\/strong>. It is the M-Files object type the engine searches against, addressed by its display name (the singular form is fine, the engine resolves it and uses it).<\/p>\n\n\n\n

1.1. Single object type<\/h3>\n\n\n\n

The simplest form is a string:<\/p>\n\n\n

\n"objectType": "Document"\n<\/pre><\/div>\n\n\n
Or any other object type defined in your vault:<\/p>\n\n\n
\n\/\/ Looking for Customers\n"objectType": "Customer"\n\n\/\/ Looking for Projects\n"objectType": "Project"\n\n\/\/ Looking for Employees\n"objectType": "Employee"\n<\/pre><\/div>\n\n\n
The display name is case-insensitive<\/strong> but must otherwise match what the vault shows. Please note that, if the vault is let’s say, in German, you might need to use “Dokument” and not “Document”. In short, you need to use what the vault defines\/shows.<\/p>\n\n\n\n
If the name does not match, the widget shows a clear \u2717 Object type ‘xxx’ not found in this vault<\/em><\/strong> error.<\/p>\n\n\n\n
1.2. Multiple object types<\/h3>\n\n\n\n
When the same logical entity exists across more than one M-Files object type (for example, a “Proposal” can be both a Document and a Document collection), you can pass an array:<\/p>\n\n\n
\n"objectType": ["Document", "Document collection"]\n<\/pre><\/div>\n\n\n
The engine resolves every name and builds a single search to find all matching objects. This behaves like the “is one of”<\/em><\/strong> filter in M-Files Advanced Search. Please note that the Drill-through will also inherit the same scope, automatically.<\/p>\n\n\n\n
A small but important detail: even in this case, the engine executes a single search. This matters for performance and for consistency (a single serverScanMaxResults<\/em><\/strong> cap applies, not two independent caps).<\/p>\n\n\n\n
2. class – narrowing the scope (and the perf impact)<\/h2>\n\n\n\n
The class<\/em><\/strong> field is optional but strongly<\/em><\/strong> recommended. It restricts the query to one specific class:<\/p>\n\n\n
\n"objectType": "Document",\n"class": "Contract or Agreement"\n<\/pre><\/div>\n\n\n
Querying “all Documents” in a vault that contains 50’000 documents of which only 1’000 are Contracts is pure waste. Adding “class”: “Contract or Agreement”<\/em><\/strong> narrows the scan immediately, which both improves performance and makes the widget result more meaningful.<\/p>\n\n\n\n
Therefore, both M-Files Administrators and M-Files Users will thank you for selecting the right class to use. It avoids slowness, irrelevant results and reduces resource usage. You should always set a class<\/em><\/strong>, when possible.<\/p>\n\n\n\n
When objectType<\/em><\/strong> is an array and class<\/em><\/strong> is specified, the engine will find any object, from that class, from any of the object types listed. So the following will match Proposal-class objects from both types:<\/p>\n\n\n
\n"objectType": ["Document", "Document collection"],\n"class": "Proposal"\n<\/pre><\/div>\n\n\n
If the class is misspelled, the widget shows a \u2717 Class ‘xxx’ not found on the specified object type(s)<\/em><\/strong> error. As with object types, the name depends on what the vault defines\/shows.<\/p>\n\n\n\n
3. filters – the AND-combined conditions<\/h2>\n\n\n\n
The filters<\/em><\/strong> array, which is optional, contains zero or more conditions. If you specify multiple filters, then all filters must match<\/strong>. That means that M-Files applies a AND semantic between each filter. By the way, M-Files doesn’t directly support “OR” conditions, it always joins them. The only “kind-of-an-exception”, as far as I know, is the “is one of”<\/em><\/strong> where you can set multiple values from the Lookup\/MultiSelectLookup property values. But that’s only a single condition, not multiple conditions.<\/p>\n\n\n\n
Here is an example of a filter:<\/p>\n\n\n
\n"filters": [\n  { "property": "Effective through", "operator": "greaterOrEqual",\n    "value": "@today", "valueType": "dateToken" },\n  { "property": "Agreement type", "operator": "equals",\n    "value": "Subcontracting Agreement" }\n]\n<\/pre><\/div>\n\n\n
Each filter has up to four fields:<\/p>\n\n\n\n