How are we going to store our documents?

It’s a reasonable question. After all, Enterprise Content Management is often associated with storing files, replacing shared drives, and organizing folders.

But does it really matter? No, because the document itself is rarely the real asset.

True value lies in everything that happens before, during, and after a document is created.

A contract isn’t valuable just because it’s a PDF.

It’s valuable because of the processes it goes through: negotiation, approval, signing, execution, renewal, and eventually expiration.

It’s the lifecycle that creates value, not the file itself.

A document is just a snapshot

Think about an invoice.

The invoice itself contains information.

But the business process includes much more:

• Who created it?
• Has it been approved?
• Has it been paid?
• Is there a dispute?
• Which purchase order does it belong to?
• Which supplier issued it?
• Is it retained for legal purposes?

The PDF answers very few of those questions.

The lifecycle answers all of them.

Documents are always moving

One mistake many organizations make is treating documents as static.

In reality, every document evolves.

A policy may be:

Draft → Reviewed → Approved → Published → Updated → Archived → Deleted

Every stage has:

• different users
• different permissions
• different metadata
• different business rules

The lifecycle is dynamic.

The document is not.

Every stage has different needs

Consider an employee contract.

During drafting:

• HR edits it.
• Legal reviews it.

After signature:

• HR only reads it.
• Payroll needs specific information.
• Employees access a copy.

Years later:

• The contract becomes part of an archive.

The document hasn’t changed much, but everything around it has.

Metadata evolves too

Many implementations assume metadata is entered once.

In reality, metadata evolves throughout the lifecycle. Even a simple scenario might include:

At creation:

• Customer
• Supplier
• Project

After approval:

• Approval date
• Approver

At publication:

• Effective date
• Version

After archive:

• Retention category
• Destruction date

For a much more complex case, imagine how the metadata should evolve alongside the business process.

Automation should follow the lifecycle

Approval is often treated as the end of the process, but in practice it is only one milestone in a much longer journey.

Think about everything that could happen automatically.

Before approval, you can assign reviewers and validate mandatory fields.

After approval, you can notify stakeholders and publish the documentation.

While the document is valid, you can monitor deadlines or create associated tasks.

When the document expires, it may be useful to send reminders and launch the renewal process.

Finally, when the document is obsolete, you can choose to archive or automatically delete it.

Automation becomes much more valuable when viewed across the entire lifecycle.

Search changes throughout the lifecycle

People don’t search for documents the same way at every stage.

While drafting:

Show me my contracts awaiting approval.

Later:

Find the latest signed version.

Years later:

Retrieve every contract with Supplier X from 2021.

The same document.

Three completely different search expectations.

Security evolves as well

Permissions should rarely be static.

Draft documents may be confidential.

Published procedures should be visible to everyone.

Archived contracts should only be accessible to compliance officers.

Security should evolve naturally with the document.

Think beyond the document

Modern ECM systems don’t simply manage files.

They manage information over time.

The document becomes one element of a larger ecosystem involving:

• people
• workflows
• metadata
• business objects
• automation
• retention
• AI

The file itself is almost the least interesting part.

Final thoughts

A document is created only once.

Its lifecycle may last years. That’s where the real business value lies.

Organizations that get the most out of their ECM solution aren’t the ones that store documents the best.

Rather, they are the ones that understand everything that happens before, during, and after those documents exist.

After all, it’s processes, not documents, that create value!

L’article The lifecycle of a document is more important than the document itself est apparu en premier sur dbi Blog.

Yet the feature employees use more than any other is rarely the one showcased in demonstrations or marketing brochures: search.

The reality is simple. Most users don’t spend their days creating workflows or configuring metadata. They spend it looking for information.

Every unsuccessful search comes at a cost!

Search happens more often than you think

Think about your workday.

How many documents do you create?

Maybe a few.

How many do you approve?

Perhaps a few more.

Now, ask yourself a different question: How many times do you search for information?

Procedures, invoices, contracts, customer communications…

For most employees, searching is the most common interaction with an ECM system by far.

This means that even minor improvements to the search function can significantly impact productivity.

Finding a document is only half the problem

Many ECM vendors claim they can find any document in seconds.

That’s great, but it’s often not enough.

Imagine a customer calls about an invoice. You know the supplier, but not the invoice number.

A good ECM lets you find the document in seconds by searching the supplier, project, purchase order, or even the contract linked to it.

A poor search experience forces you to browse folders, ask colleagues, or search through emails.

An effective search is about relevance, not just speed.

Search starts long before someone types a keyword

Many organizations try to improve their search function by tweaking the search engine.

In reality, a good search starts much earlier.

It begins with:

• meaningful metadata
• consistent naming conventions
• well-designed object relationships
• document classifications
• quality-controlled information

Poor information management cannot be fixed with search alone.

Even the most advanced search engine will struggle to deliver useful results if the metadata is inconsistent or incomplete.

Search should reduce decisions

A good search experience should minimize the amount of thought required of users.

Instead of asking:

“What was the exact document name?”

Users should be able to search naturally:

• customer name
• supplier
• project
• Invoice number
• Contract type
• Date
• Keywords

The system should handle the complexities.

Users shouldn’t need to understand how the information is stored.

What about AI?

Generative AI doesn’t replace search, it changes users’ expectations of search.

Now users want to be able to ask questions like:

“Show me all contracts that expire next quarter.”

Or:

“Find the latest approved procedure for handling customer complaints.”

Behind these simple questions lies something much less glamorous: reliable metadata.

Without it, AI cannot consistently provide trustworthy answers.

In many ways, AI has made search even more important.

Search is a user experience feature

When discussing user adoption, project teams often focus on training.

Training certainly matters.

However, the user experience during searches is also important.

If employees consistently find what they need in seconds, their confidence in the system grows.

However, if they repeatedly fail to find information, they’ll quickly return to shared drives, email folders, or ask colleagues for help.

The quality of the search function shapes the perception of the entire enterprise content management (ECM) solution.

Search is a business capability

A good search is about more than just saving a few minutes.

• It enables better decision-making.
• It prevents duplicate work.
• It improves compliance.
• It accelerates customer service.
• It helps preserve organizational knowledge.

The value of an ECM system isn’t measured by how many documents it stores.

Rather, it’s measured by how effectively those documents can be found and used.

Final words

Search rarely appears as the headline feature in product demonstrations because every ECM platform offers some form of search.

The real difference isn’t whether a system can search, it’s how effectively users can find the right information when they need it.

A successful ECM implementation isn’t one where information is simply stored.

Rather, it’s one where information is found effortlessly, trusted confidently, and reused effectively.

After all, a document that can’t be found might as well not exist.

L’article Why search is the most underrated ECM feature est apparu en premier sur dbi Blog.

When discussing user adoption of M-Files, the conversation often centers on training, change management, and automation. While these aspects are important, another factor immediately impacts the user experience: the Metadata Card.

A poorly designed Metadata Card can overwhelm users with unnecessary fields and irrelevant questions, making creating a document feel like filling out a tax form. Conversely, a well-designed Metadata Card naturally guides users through the process by displaying only the necessary information.

The goal is not to collect as much metadata as possible but rather to collect the right metadata at the right time.

Just a reminder that in M-Files, a metadata card is the panel that displays and allows users to edit the metadata properties of an object. It is an essential component of the tool.

Start with the user journey

Before creating properties or configuring rules, ask a simple question:

What information does the user actually know at this stage?

Consider an invoice.

At creation, the user probably knows:

• Supplier
• Invoice number
• Invoice date
• Amount

They probably don’t know:

• Approval status
• Payment date
• Accounting reference
• Archive classification

Those properties should appear only when they become relevant.

Metadata Card should evolve with the document lifecycle rather than exposing every possible property from the beginning.

Hide what isn’t needed

One of the most effective improvements is dynamic property visibility.

Rather than displaying every property permanently, configure the card so that properties only appear when certain conditions are met.

For example:

• If the document class is “Contract”, display the contract expiration date.
• If the supplier is external, display vendor-specific properties.
• If the document is confidential, display the security classification section.
• If the document enters the approval workflow, display approval-related properties.

This approach reduces visual clutter and helps users focus on the task at hand.

Make properties mandatory only when necessary

One common mistake is making too many properties mandatory.

Although mandatory properties can be useful, they should only be used when appropriate.

For example:

The “termination date” property should not be mandatory when creating a new employee contract. This property only becomes relevant if the employee leaves the company.

Conditional mandatory properties allow for validation without frustrating users.

Rather than forcing users to enter placeholder values just to save the document, only ask for this information when it is required by the business process.

Group related information

Metadata cards are easier to navigate when related properties are grouped together.

Instead of a long list of unrelated fields, organize them into logical sections.

Users scan information much faster when it is visually organized.

Additionally, sections that are not needed at a given stage can be hidden or collapsed.

Reduce decisions

Every visible property asks the user to make a decision.

Should I fill this in?

Does this apply to my document?

What does this property even mean?

A good metadata card minimizes these decisions.

It is good practice to use:

• Automatic values
• Default values
• Value lists
• Metadata inheritance
• Calculated properties

The fewer decisions users have to make, the faster and more accurately they can classify documents.

Avoid the “Everything might be useful”

One of the biggest design mistakes is trying to satisfy every department.

For instance, the Human Resources department requires three properties, the Legal department requests five more, the Finance department submits a request for four additional fields, and finally, the Compliance department adds another six.

After a few workshops, the metadata card ends up with thirty or forty properties.

Technically, everything is possible.

Practically, nobody enjoys using it.

Whenever a new property is requested, ask:

• Who will maintain it?
• Who actually uses it?
• What business process depends on it?
• What happens if it remains empty?

If there isn’t a clear answer, then the property probably isn’t necessary.

Design for the common case

Most users perform the same actions repeatedly.

Optimize the metadata card for 80% of documents rather than exceptional cases.

Advanced scenarios can reveal additional properties as needed.

Simple cases should remain simple.

Think like a product designer

Administrators often focus on configuration, whereas it is the users who interact with the interface.

Therefore, it is important to keep in mind that every additional property increases cognitive load.

Similarly, every unnecessary required field creates friction.

Conversely, every hidden property reduces complexity.

A well-designed metadata card improves not only data quality but also the user experience of the entire M-Files system.

Conclusion

Metadata is one of M-Files’ greatest strengths, but only if users provide it.

The best metadata card isn’t the one that captures the most information.

Rather, it’s the one that asks the fewest questions while still collecting everything the business needs.

When users feel that the system understands their tasks instead of getting in their way, they will naturally adopt it.

Sometimes improving user satisfaction isn’t about adding new functionality; it’s about designing a better metadata card.

Whether you’re planning a new M-Files implementation or looking to improve an existing one, we can help you design a solution that is efficient, user-friendly, and aligned with your business needs. Feel free to contact us to discuss your project.

L’article Designing metadata cards that users like est apparu en premier sur dbi Blog.

Installation

The installation is very straight forward and well documented, it can take some time for the creation of the necessary self signed certificated for the Microsoft Azure Application. In addition, you must ensure that you have management access to the Microsoft Azure Admin Centre or an admin aside to perform the required steps

I will. not go through each step in detail, but I will highlight important steps from my point of view. The step by step documentation can be found on the M-Files web page for Integrations.

Important steps:

• Allow third-party cookies for Outlook Web.
  https://[*.]office365.com
  https://[*.]office.com
• Ensure that the lins below not blocked by the firewall.
  https://mfnewoutlookaddinprod.m-files.com
  https://login.microsoftonline.com/common
  https://login.m-files.com/
• Create a self signed certificate and convert them to be able to configure the M-Files Vault Application.
• Create and configure the Application in Azure, according the M-Files documentation.
• Installation and configure the M-Files Vault Application, just follow the M-Files documnetation.
• Install or deploy the M-Files for Outlook add-in. It is a certified Microsoft application. It can be installed individually or deployed to a specific group of users. This is the standard Microsoft process.
  

Create a self signed certificate for use in a cloud setup

Open PowerShell with administrative access and use the command below.

$certname = "{certificateName}"    ## Replace {certificateName}
$cert = New-SelfSignedCertificate -Subject "CN=$certname" -CertStoreLocation "Cert:\CurrentUser\My" -KeyExportPolicy Exportable -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256

Export-Certificate -Cert $cert -FilePath "C:\Users\admin\Desktop\$certname.cer"   ## Specify your preferred location

$mypwd = ConvertTo-SecureString -String "{myPassword}" -Force -AsPlainText  ## Replace {myPassword}

Export-PfxCertificate -Cert $cert -FilePath "C:\Users\admin\Desktop\$certname.pfx" -Password $mypwd   ## Specify your preferred location

In case you get an execution error from PowerShell, you can use the command below to allow the execution

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force

If everything worked as expected you have files as in the example below.

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        29/06/2026     08:18            772 testcert.cer
-a----        29/06/2026     08:20           2644 testcert.pfx

To convert the certificates, you will need to use OpenSSH and Cygwin. M-Files strongly recommends using Cygwin. I encountered issues when I did not use Cygwin and it did not work.
Conversion is required in order to configure the certificate within the M-Files Vault application.

After the installation of Cygwin the command below must be executed in a Cygwin command window.

openssl pkcs12 -in MyCert.pfx -out MyCert.pem -nokeys

openssl pkcs12 -in MyCert.pfx -out MyCert.key -nocerts

openssl rsa -in MyCert.key -out MyCert_encrypted.key -aes256

Configure the Outlook and M-Files rules

You can use the Outlook and M-Files rules to automatically save received emails to the M-Files system. It is important to understand how each rule works within the M-Files Outlook add-in. This differs from creating an object in M-Files, where the workflow and required state must be explicitly defined.

Open the M-Files Outlook Add-In in Outlook and navigate to “Manage folder rules.

The screenshot below shows the configuration of the Outlook folder “Firma A – Projekt A”, which will be imported automatically and assigned to the M-Files class ‘Email Import’. Additionally, the “Email Import Validation” workflow with the state “Import prüfen” is assigned.
If the workflow is not defined in the rule, it will not be assigned as expected. As we know, when a new object is created in M-Files, the workflow of the class is used automatically.

Conclusion

In order to automate the process of moving incoming emails into M-Files, two steps are required. First, define the usual Outlook rule, then create a rule in the M-Files Outlook add-in, as explained above.

Don’t hesitate to get in touch with us or directly with me if you have any more questions or need support with implementation.

L’article M-Files Outlook Pro add-in configuration est apparu en premier sur dbi Blog.

I picked the Sample Vault because it is the one that gets shipped when you are installing M-Files in evaluation mode and it contains some sample data, as its name suggests… Please note that since it is a rather old vault, data inside was created somewhere between 2004 and 2012. Therefore, in this blog, I will go back in time (yes, I can!) and consider that “today” is actually the “01-Nov-2011” (2011-11-01). In a real vault, you would use the dateToken “@today” instead, but for this blog, to allow you to reproduce the steps below, I chose that specific date since it gives interesting data to visualize.

1. What I am going to build

The target dashboard has eight widgets:

• Four KPI tiles in a row at the top: Active Contracts, Expired Contracts, Contract Expiry < 180d, No expiry date.
• One donut: Contracts by agreement type.
• One gauge (date-mode): days until the earliest/next contract expiry.
• One area: contract expiry per year and per agreement type.
• One table: all expired contracts (for review or sales purpose).

This layout fills the right pane with a clean “summary at the top, distribution in the middle, action items at the bottom” reading order.

2. Creating a new dashboard

The dashboard management is done on the M-Files Admin UI. To access it, open M-Files Admin -> Configurations -> Other Applications -> dbi services Business Dashboard -> Dashboard tab. Then click on the Add New button. The editor opens, by default in Visual mode with an empty canvas and the Dashboard Settings panel on the right:

3. Dashboard Settings

Before adding widgets, let’s configure the dashboard-level fields in the right panel. The below assumes you never updated the default values. If you would like to update the defaults so all future dashboards have your own, you can do it in the Configuration tab.

• Name: Contracts Snapshot (01-Nov-2011).
• Description (optional): Quick view of contracts: active, expiring, distribution..
• Auto-refresh enabled: No (leave off for now, you can flip it on later if needed).
• User can toggle: Yes (users can enable the auto-refresh).
• Export to PDF enabled: Yes.
• Export to CSV enabled: Yes.
• Drill-through enabled: Yes (this is what makes the chart elements clickable and it displays details about the matching objects).
• Leave the rest as default. There are enough query results to fetch all details, each user sees only the objects their M-Files ACL allows, etc.

4. The first KPI tile: Active Contracts

Click on the + Add Widget button in the footer. A blank tile appears on the canvas and the right panel switches to the widget config.

First, we set the widget basic details:

• Widget Title: Active Contracts.
• Description (optional): leave empty.
• Widget Type: KPI Number.
• Col Span: 3.
• Row Span: 1.

Then, we need to configure the source of the data we want to see:

• Object Type(s): Document (dropdown shows the vault’s object types).
• Class (optional): Contract or Agreement (automatically populated after selecting an object type).
• Aggregation Type: summary (already set automatically since it’s the only one supported by kpiNumber).

Optionally, we can configure one or more filters. Here, since we want to see only active contracts (i.e. that have an effective-through date superior or equal to today), then we need to apply a certain filter. Click on the + Add Filter button and a row appears:

• Property: Effective through (date) (from the property dropdown, the “(date)” is the data-type that is shown but it’s not part of the property name).
• Operator: greater than or equal (>=).
• Value type: dateToken.
• Value: 2011-11-01 (instead of “@today” in a real vault).

Finally, we define the aggregation (i.e. what to do with the results obtained) as well as the display section, which are optional graphical/rendering details:

• Reducer: count (default).
• Drill-through Columns (comma-sep): Agreement type, Effective through (the additional columns to add to table lists or drill-through details tables).
• Display Unit: contracts.

To validate that the configuration is correct, you can click on the Test Widget button in the footer. The Test Results panel expands on the right side, and shows a green OK, which confirms the definition is correct. So far, so good.

5. The other three KPI tiles

The next three KPIs follow the same pattern as the first one, with different filters.

5.1. Expired Contracts

With the 1st widget selected, click on the Clone Widget button. A new tile appears next to the first one, with exactly the same content. Simply update these fields:

• Widget Title: Expired Contracts.
• Operator (Filter): less than (<).

Click on the + Add Threshold button and a row appears:

• Value (Threshold): 1 (any value equal or above 1 will match).
• Color (Threshold): red or #e74c3c (color used if above value is reached).

5.2. Expiring in next 180 days

Click on the Clone Widget button again:

• Widget Title: Contract Expiry < 180d.
• Operator (Filter): between (from,to)
• Value (Filter): 2011-11-01, 2011-11-01+180d (instead of “@today, @today+180d” in a real vault).
• Color (Threshold): orange or #f39c12 (update the existing threshold and keep the value as 1).

5.3. No expiry date

Click on the Clone Widget button again:

• Widget Title: No expiry date.
• Operator (Filter): is empty (incl. absent) (no value field for this operator).

Click on the + Add Threshold button and a second row appears (keep the other one with 1-orange):

• Value (Threshold): 0 (any value equal or above 0 but below 1 (c.f. other threshold) will match. i.e. only valid if equal to 0).
• Color (Threshold): green or #27ae60 (color used if above value is reached).

At this point the canvas shows four KPI tiles. They each have colSpan: 3, so they sit nicely in a row of four totalling 12 (full width of the dashboard). You can click on Test Queries button (at the top) to validate that all four kpiNumber widgets are correct.

6. The donut: contracts by agreement type

Click on the + Add Widget button in the footer to add a new widget:

• Widget Title: By Agreement Type.
• Widget Type: Donut Chart.
• Col Span: 6.
• Row Span: 2 (chart widgets need height, see Post 3).
• Object Type(s): Document.
• Class (optional): Contract or Agreement.
• Aggregation Type: Group by Property (all objects with the same value of a specific property will be grouped together).
• Group-by Property: Agreement type (lookup) (the property to be used for the grouping).
• Drill-through Columns (comma-sep): Agreement type, Effective through.

7. The date-mode gauge: countdown to next expiry

The gauge is where things get more interesting. Here, I would like a dial showing how many days are left until the earliest/next contract expiry. This can be useful for making sure you never reach “0” (i.e. the date of today) on some tasks, like contracts renewal, period reviews of some documents, etc. You can see this as something similar to a fuel gauge in a car. If it reaches the minimum, you might be in trouble… The reducer is min on the Effective through property, and since this property is a date, it triggers date-mode automatically.

Add the sixth widget. You know the drill, + Add Widget:

• Widget Title: Closest Expiry.
• Widget Type: Gauge.
• Col Span: 6.
• Row Span: 2.
• Object Type(s): Document.
• Class (optional): Contract or Agreement.

Let’s add a filter to keep only valid contracts again: click on the + Add Filter button and a row appears:

• Property: Effective through (date).
• Operator: greater than or equal (>=).
• Value type: dateToken.
• Value: 2011-11-01 (instead of “@today” in a real vault).

• Reducer: min.
• Reducer Property: Effective through (date).
• Drill-through Columns (comma-sep): Agreement type, Effective through.

Now let’s add a first threshold: click on the + Add Threshold button and a row appears:

• Value (Threshold): 0 (so “today” = the contract expiry is very soon).
• Color (Threshold): red or #e74c3c.

Click on the + Add Threshold button and a second row appears:

• Value (Threshold): 40 (so “next month” = the contract expiry is coming).
• Color (Threshold): orange or #f39c12.

Click on the + Add Threshold button and a third row appears:

• Value (Threshold): 80 (so at least “2 months left” = the contract expiry is still far).
• Color (Threshold): green or #27ae60.

• Display Min (day offset): 0 (so “today”).
• Display Max (day offset): 180 (so “today” + 180 days).
• Display Unit: next expiry.

7.1. Sample Vault date limitation

Note: This widget will not fully work on the Sample Vault as-is, since the data is from 2011 and all contracts are already in the past. In a real vault, you would use @today as the filter value and set min/max to 0 and 180. The gauge would then show the number of days until the earliest active contract expires.

On the Sample Vault, since 01-Nov-2011 is roughly 5350 days in the past, you would need to set min to “-5350” and max to “-5350+180” to see a meaningful result. The exact offset depends on when you read this, which is precisely why date tokens like @today exist – they adapt automatically.

If I set the min/max offset to the accurate number of days since 01-Nov-2011, the gauge looks like this for end-users (that’s what It will look like on a real vault with @today and 0-180 values):

8. The area chart: expiry per year and per agreement type

Add the seventh widget. It didn’t change since earlier, it’s still + Add Widget…

• Widget Title: Expiry per Year and Agreement Type.
• Widget Type: Area Chart.
• Col Span: 12.
• Row Span: 2.
• Object Type(s): Document.
• Class (optional): Contract or Agreement.
• Aggregation Type: Group by Date Bucket (all objects with the same date bucket for a specific property will be grouped together).
• Date Property: Effective through (date) (the property to be used for the grouping).
• Bucket Size: year (the objects within the same year will be in the same group).
• Series Property (optional): Agreement type (lookup) (a second grouping level).
• Drill-through Columns (comma-sep): Agreement type, Effective through.
• Smooth Lines: Yes.

Note: Instead of an Area Chart, you can use a Line Chart or Bar Chart, these three are usually interchangeable and can give the same amount of information visually.

9. The table: expired contracts to review

The last widget is a table showing the list of all expired contracts. This can be used for review or for some sales purpose, as previously mentioned. So let’s + Add Widget one last time:

• Widget Title: Expired Contracts to Review.
• Widget Type: Table.
• Col Span: 12.
• Row Span: 2 (you can set 3 as well, for bigger table/lists).
• Object Type(s): Document.
• Class (optional): Contract or Agreement.
• Aggregation Type: List (list of individual objects).

Click on the + Add Filter button and a row appears:

• Property: Effective through (date).
• Operator: less than (<).
• Value type: dateToken.
• Value: 2011-11-01 (instead of “@today” in a real vault).

• Display Properties (comma-sep): Agreement type, Effective through, Owner.

10. Sanity check & Saving

Before saving, you can click on the Test Queries button from the toolbar to validate all widgets at once. The right-panel should list eight widgets, all green and without any warnings or errors. If something is wrong – a property name typo, an incompatible reducer / widget combination – this is where it would surface, with a clean message describing what to fix.

If it’s all green, then click on the Save button in the toolbar. The editor should display a message at the bottom saying it validated everything and then closes (you need to be quick to see the message). The Admin UI Dashboard tab refreshes, and the Contracts Snapshot dashboard now appears in the list, with its number of widgets and its description.

Now, let’s see what it looks like from an end-user perspective after all that work! You can open the M-Files Web or Desktop (or do a refresh CTRL+F5 / CMD+R if it’s already loaded), open the right pane by clicking on the Dashboard tab, and pick Contracts Snapshot from the dropdown (it should be displayed automatically if it’s your first dashboard). Every chart element should be clickable (drill-through is enabled), and the PDF / CSV export buttons should also be present.

See the first screenshot at the beginning of this blog post to see the final result that you can expect if you followed along the steps so far. Still, since you made it this far, here is what it looks like as a PDF Export:

11. Closing thoughts

I initially created the Business Dashboard with the JSON editor only, but I always had in mind that I needed to add a Visual Designer at some point, because not everybody knows how (or wants) to write JSON. Also, writing JSON directly requires you to know what is required, optional, supported or not supported. Even if the Test Queries and Save buttons both execute multiple layers of validations, to ensure everything you enter is supported, it still sends you warning after warning, error after error if you do not really know what you are doing. Therefore, the Visual Designer is great for that purpose, because you just click-through the details and you are guided all the way.

The Visual / JSON toggle at the top of the editor lets you switch between authoring paths at any time, and your work is preserved in both directions. If you prefer hand-editing JSON or need to do bulk changes, the JSON mode is always available—but most administrators find the Visual Designer sufficient for their day-to-day work.

Want to know more about this Business Dashboard? Contact us and we will be happy to showcase it on M-Files.

Quick access to previous blog posts of the series:

• Post 1 – Introduction to the Business Dashboard.
• Post 2 – The end-user experience: opening the panel, switching dashboards, drill-through, exports, favorites, sharing.
• Post 3 – The anatomy of a dashboard definition: the JSON structure that drives everything.
• Posts 4a, 4b, 4c – The widget catalog, split by type family: scalar widgets (kpiNumber, gauge), trend widgets (line, area), and distribution / tabular widgets (donut, bar, table).
• Post 5 – Writing queries: objectType, class, filters, date tokens.
• Post 6 – Aggregations and reducers.
• Post 7 – The Admin tab: actions, Visual Designer / JSON editor, validation, import / export, access control.

L’article M-Files BD – Putting it together with the Visual Designer est apparu en premier sur dbi Blog.

This is also where the Visual Designer lives. Some administrators write JSON directly, others stay in the visual canvas, others switch back and forth. All three workflows are supported, and the two modes are kept in sync at every moment.

1. Where to find the Admin tab

Once it has been installed (e.g. via Vault -> Right click -> Applications -> Install…), the Business Dashboard will be present in the M-Files Admin configuration page:

1. Open M-Files Admin (the desktop management application).
2. Connect to your server and open the target vault.
3. In the left tree, navigate to Configurations -> Other Applications.
4. Find dbi services Business Dashboard and click it.
5. You should end up on the Dashboard tab.

The first thing you will probably want to do is to look at the Configuration tab, that sits right next to the Dashboard one. This is where you can configure the Business Dashboard as needed.

1.1. The Configuration tab – “General” settings

At the time of writing this blog, the General section of the configuration is rather short. It only contains 4 settings:

• Table page size: controls the pagination of all tables (list & drill-through modals), i.e. the maximum number of rows that can be displayed before a new page is required. (default: 15).
• Default widget color: controls the base color of the widgets (end-user side), like the number inside the kpiNumber, the gauge and its pointer, the table header, the line and area. It’s only the base color, so it still gets updated/overwritten by the display.thresholds parameter of each widget. (default: #006eef – the M-Files “standard” blue).
• Default chrome color: controls the base color for the “chrome” things (end-user side), for example the links shown inside the tables, to navigate to objects, as well as the spinner when dashboards/widgets are loading. (default: #006eef).
• Admin UI accent color: controls the base color for the buttons (admin side), like Save, Test Queries, etc. (default: #006eef).

Exactly like any other M-Files configuration items, as soon as you modify one of these values, the “Save” and “Discard” buttons appear so you can either persist and remove what you just changed.

1.2. The Configuration tab – “New Dashboard Defaults” settings

The second section inside the configuration tab allows to overwrite the default settings for new dashboards. As I mentioned in previous blogs, a dashboard has around 10 configurable parameters, that controls things like which features are allowed, whether users can refresh or if it should be automatic, etc. All these parameters have a default value, which is usually “No” (disabled / do not bypass important checks).

This section will make it so that all dashboards created in the future will use your own personalized default values, so you don’t have to configure the same things over and over again. It doesn’t have any impact on already configured dashboards AND it doesn’t force anything. It is simply a replacement of default values, which means that you can still overwrite these settings inside each dashboards as required (because specific dashboards might have different needs).

• Auto-refresh enabled: controls whether the automatic refresh is enabled. (default: No).
• Auto-refresh interval (seconds): controls the interval between two automatic refresh. (default: 300).
• User can toggle auto-refresh: controls whether users can enable the automatic refresh. (default: No).
• Export to PDF enabled: controls whether the PDF export is enabled. (default: No).
• Export to CSV enabled: controls whether the CSV export is enabled. (default: No).
• Drill-through enabled: controls whether the drill-through is enabled, which also controls the navigation to target objects. (default: No).
• Drill-through max results: controls how many results will be paginated on drill-through modals. (default: 300).
• Server scan max results: controls how many results we can return when looking for objects. (default: 500).
• Skip template check: controls whether the “template check” are skipped. More on that later in this post. (default: No).
• Skip object permission check: controls whether the user’s ACLs are respected. More on that later in this post. (default: No).

1.3. The Configuration tab – “Logging” settings

The third section contains all the standard M-Files logging configurations. In there, you can enable the global logging, then create some specific targets, like a file target (writing to a log file on the local file system), event log target (writing to the Windows Event Log), database target (writing to a specific DB), etc…

These are usual M-Files configurations, so I won’t describe them all, but in short, you only have to enable the global logging, defining a target with the appropriate log level and target-specific details as you see fit.

2. The dashboard list and action buttons

The Dashboard tab shows all currently configured dashboards (or nothing if you have none yet) in an alternating-row list. Each row contains additional details such as the count of widget inside this dashboard, the access details (whether it can be accessed by everybody or if it’s restricted to some people/groups only) and the description.

Each dashboard row also has a compact icon button bar for quick access: ↑ ↓ 🖉 ⧉ ⎙ 🗑 (move up / move down / edit / clone / export / delete) (It took me so long to find these icons!). These per-row buttons provide faster access to the most common operations without opening a selector modal from the top-bar buttons.

Speaking of top-bar buttons, you saw them already, but at the very top, you can see global action buttons available from any of the tabs:

More on these actions lower in this blog post.

3. The editor: two modes, one source of truth

When you click Add New or Edit…, the editor modal opens. At the top of the toolbar, two buttons toggle between the modes:

• [Visual] (default): the “Visual Designer”, a form-based designer with a canvas of widget tiles and a side configuration panel.
• [JSON]: the “JSON Editor”, a manual code box that allows you to write JSON.

The two modes are kept in sync at all times. Switching from Visual to JSON shows the current visual state serialized, switching back re-parses the JSON so that the Visual Designer is also up-to-date.

The editor is split into four regions:

• The top bar shows main buttons to switch between modes, load an example dashboard (to give you some ideas), format JSON (when in JSON Editor mode), test all widgets at once or save.
• The left panel shows either the widgets display in Visual Designer mode or the JSON code block in JSON Editor mode.
• The footer bar (anchored below the canvas) has four buttons, to show the dashboard settings, add a new widget, clone an existing widget or test a widget. There is also a small place below these buttons kept for status messages, to let you know when something was done or if there are errors, etc.
• The config panel (right panel) shows the editable fields. In Visual Designer mode, it shows dashboards and widget configurations. In JSON Editor mode, it shows the user and group pickers only. Both modes also includes the “Test Results” which contains execution/validation details.

3.1. Visual mode

As said, the left panel contains the widget display, with their title, type, aggregation, objectType. It also display quick action buttons such as up-down or delete, so you can quickly re-arrange the widgets and get the visual look&feel that you want. The right panel contains the dashboard settings by default (which we described above already). When a widget is selected, the right panel will then display these different building blocks:

With this Visual Designer, you are guided by selecting things one by one. You don’t see ALL options right from the beginning, depending on what you select, only what is possible will be offered, so you can focus on what makes sense for you.

3.2. JSON mode

The JSON Editor is simply a code box which allows you to enter JSON. It shares the top-bar buttons with the Visual Designer, the only difference being the “Format JSON” one that is enabled only when in JSON mode.

I might extend this feature later, but for now there is no completion feature, it simply has a bit of highlighting so you can spot errors easily and allows for code drag-and-drop.

4. Validation

4.1. The two-stage validators

Whether you click on Test Queries (all widgets), Test Widget (1 widget) or Save and whether you are doing it from Visual or JSON mode, the engine will run a 2-stage validation of what you currently configured.

4.1.1. Stage 1

The first stage is simply a structural one. For example, are all mandatory fields present, are known values (e.g. widget types) within the accepted ones, etc. This is very fast and it doesn’t require a connection to the vault, so that we can already surface global issues.

Note: Only the “Import” feature bypasses the stage-2 validation and only performs a structural check. When using the import feature, we kinda expect that the JSON was exported from another vault and therefore if it existed inside a previous environment, it means that it is a valid dashboard. Doing the stage-2 validation on each import would considerably slow it down (especially if you import 10, 50 or even 100 dashboards at once).

4.1.2. Stage 2

The second stage is much more complex and it will verify if you made any mistakes by really checking what’s available inside the vault. This will mark typos such as wrong object types, classes or properties. It will also try to resolve value lists items that you references, to make sure they are indeed present. This is obviously slightly slower, but still completes within a couple seconds for most dashboards. It also gives you a good idea of how fast this dashboard will load for end-users, since it’s actually executing all queries.

Note: For Test Widget, the engine will only test one specific widget, as said earlier. Therefore, it automatically adds a valid dashboard structure around it so it can pass the stage-1 validation for the dashboard level. Only stage-1 validation of the widget level is tested and the query execution for the phase-2, obviously.

4.2. Errors and warnings

The Test Results panel shows three possible statuses per widget:

• OK: the query succeeded and the result is renderable.
• Warning (amber): the query succeeded but the result will probably not be rendered the way you would like to. A common occurrence is a date-valued reducer on a chart widget, where the message will tell you to switch to kpiNumber, table, or gauge.
• Error (red): the query failed. The message tells you which property name or class name to check or change.

Note: A warning will still allow the Save to complete, because even if it might not render, a placeholder widget will replace the expected chart. On the other hand, an error will prevent the Save operation because we shouldn’t persist something that is structurally or fundamentally wrong. Here is an example from the Example Dashboard where I specifically introduced some mistakes:

5. Import and Export

Dashboards live in the vault’s Named Value Storage (NVS). To facilitate transfer from DEV to QA/INT to PROD or any other environments you might have, an import/export feature was added on the M-Files Admin. To use it, simply click on the Import or Export… buttons.

First, the Export… one, open a prompt so you can select which dashboard you would like to export. On that prompt, there is also a button to Export All. If you select a single dashboard to be exported, the JSON file generated will have, by default, the name of the dashboard (you can set the name that you want, of course). If you chose to export all, then the name will simply be “dashboards-export.json” and inside, you will find an array of dashboard definition.

Once it has been exported, you can then Import it somewhere else (or on the same vault, it will merge it with existing dashboards – that’s why IDs are important!). Another prompt opens and you can then select a file (through Windows Explorer) or you can also drag-and-drop JSON to it. Its content is then displayed inside the prompt so you can take a look. Once you hit the import button at the bottom, it will quickly validate the dashboard definition and if everything is good, it will be imported into the vault.

6. The Reorder and Clone modals

Two smaller actions but these are still worth mentioning because they fix small but real pain points. The Reorder… one allows you to use the up-down arrows – same as from the dashboard list shown in the default Dashboard tab. But you have access to another facilitator with the global button: dashboards are numbered with a small text box that you can update. For example, if you have 5 dashboards, the last one will have a small text box with a “5” inside. If you update that value to “1”, then this dashboard will automatically become the 1st one. This allows for faster re-ordering than clicking 4 times on the arrow-up icon, especially when you have 50+ dashboards to manage.

If you have a good idea of what you want to build and you know that one of your dashboards is already pretty similar, then instead of recreating everything from scratch, you can use the Clone… feature. It allows the duplication of an existing dashboard into a new one. The new one will use new IDs for both the dashboard and all the widgets, and to be able to differentiate them, the name will have a ” (copy)” suffix. I see you coming – if you duplicate the same dashboard multiple times, it will be ” (copy 2)”, then ” (copy 3)”, etc.

7. Access control – two-level model

Access control in the Business Dashboard works on two distinct levels:

The two are independent. assignedTo says “you are allowed to open this dashboard”. skipObjectPermissionCheck says “once you are inside, do widgets show you everything or only what your own permissions allows you to see and read”.

7.1. assignedTo – who can open the dashboard

By default (no assignedTo field or an empty array), a dashboard is visible to everyone who has access to the vault. To restrict the access, you can define either a list of users or groups:

"assignedTo": {
  "users": ["Morgan.Patou"],
  "groups": ["Finance Team", "Management"]
}

Access is granted to any user who matches any entry (OR semantics), i.e. part of the users list or part of any of the group from the groups list.

7.2. skipObjectPermissionCheck – what data shows up

By default (“No”), M-Files permissions will be respected, so you cannot see things that you aren’t entitled to see. However, there are valid use cases where you would need to specifically bypass object-level permissions.

For example, you probably don’t want all your employees to see all the HR documents, all the contracts, etc. However, there are often KPIs that could be rendered “Public”, or at least given to a broader audience than the people that originally have access to these objects. Maybe you would like to share some executive or management reporting KPIs, some Sales Performance details, or some Security Information.

That is entirely up to you and, in addition, you control whether end-users can use the drill-through or not and what metadata the drill-through should show (if anything at all). Again, it’s not because you show KPIs that users will be able to find and read classified documents. M-Files permissions on the objects themselves (preview its content, listing all metadata, downloading the file, etc.) will always be respected. What the Business Dashboard allows is fully configurable, so there are no real security concerns.

When to use each:

• “No” (default): when different users should see different numbers based on their own M-Files ACL.
• “Yes”: when every authorized viewer should see identical numbers and performance matters (typical for overview dashboards that don’t go into details). Combine with assignedTo to restrict who can open it.

8. Performance

I already mentioned them in earlier posts, but I think it still makes sense to summarize it all again here, since we are talking about the Admin side of the Business Dashboard. There are multiple parameters that have performance impacts. Some of them are very low, some aren’t.

8.1 Performance gains

These are the things that will have either no negative performance impact or even show performance gains:

• exportToPdfEnabled / exportToCsvEnabled: these two parameters are similar in the sense that they only enable one specific feature and it has no performance impact, since it runs fully on client side. All the data is already available in the client’s dashboard, so it has no impact on the server.
• skipObjectPermissionCheck: by default, it will execute ACLs checks to ensure users only see objects they are entitled to. The way I implemented that means that whether you are doing server-level queries or user-level queries has absolutely no impact on the performance. In fact, it might be even faster to execute the ACLs checks, since you might return less objects that what the server would have access to. Therefore, the performance impact is null or slightly positive.
• objectType / class / count reducer / native filters: adding a restriction on class and adding native filters will mean less results to be fetched and processed. As previously said (c.f. Post 5), for optimal performance, make sure to restrict the objectTypes / class and apply native filters as much as possible. Therefore, adding these will definitively bring performance gains.

8.2. Potential for Medium / High performance impact

Depending on how you use them, these settings can have very low or very high impact on the performance of the Business Dashboard:

• autoRefreshEnabled / autoRefreshIntervalSeconds / userCanToggleAutoRefresh: control the refresh of widgets/dashboards. The impact depends on multiple factors, like how many users, widgets, objects fetched, etc… These will increase the “regular” load on the server, not really impact the loading speed… The performance impact can go from very low (e.g. refresh every 5 minutes with low-demanding widgets) to pretty high (e.g. refresh every 15 seconds with 10’000+ objects widgets)…
• serverScanMaxResults / drillThroughEnabled / drillThroughMaxResults: define the maximum results for the widget or the drill-through. When hit, a Partial results badge appears, to show results may be incomplete. These are basically fail-safe/lifeline, to make sure widgets do not try to retrieve the whole vault’s content. The performance impact will be important if you disable this (“0” = unlimited results) and if you try to fetch 100’000 objects.
• skipTemplateCheck / non-count reducers / post-filters: all these parameters means that there is a need to fetch additional metadata from the vault, for all objects. If you want to execute the template check, apply a non-count reducer on a property or a post-filter, you will first fetch all objects, and then, for each of them, fetch their associated metadata. As far as I culd see, M-Files doesn’t allow to return both objects and their metadata at the same time. The performance impact will be grow with the number of objects you fetch and need to process.

Note: The performance isn’t bad. There are a few tricks I implemented to make sure the performance stays pretty good, so you can load a dashboard fetching 5’000+ objects in less than 1.5 seconds, with the right configuration.

11. Wrap-up

The Admin tab is the place administrators will spend the majority of their time. The Visual Designer is there to lower the complexity of creating and managing dashboards. Even a JSON-averse administrator can build a full dashboard without ever opening the JSON editor. However, it is still available for power users that feel comfortable with it, as it gives them the flexibility, quick copy/paste, and bulk-edit comfort they can expect.

The next, and probably last, Post 8 will walk you through building a complete Contracts dashboard on the M-Files Sample Vault. I will use the Visual Designer only, so you can follow along and adapt it to your own vault.

Want to know more about this Business Dashboard? Contact us and we will be happy to showcase it on M-Files.

L’article M-Files BD – The Admin part est apparu en premier sur dbi Blog.

As consultants, we constantly face new challenges, many of which extend beyond purely technical matters, while adapting to diverse contexts and audiences.

That’s what makes this profession so exciting!

At dbi services, knowledge sharing is deeply embedded in our culture.

Over the past three months, I’ve had the opportunity to share my experience working on ECM projects for years.

This post concludes the series by highlighting the key insights that have shaped my approach to these projects.

Stop thinking “System first”

In my previous roles, I was more of a product specialist than a solutions specialist. My job was to adapt clients’ needs to the software framework.

Now, working for a company that isn’t a “pure player” enables me to select the optimal solution from the beginning rather than having to adapt, of course I love M-Files, but alfresco is another solution we like!

For me, the right approach is certainly not:
“What can this ECM do?”

Rather, it is:
“What business problems do we need to solve first, and for whom?”

ECM initiatives often fail when they attempt to tackle everything at once rather than focusing on what truly matters. In practice, users don’t adopt tools just because they exist, they embrace solutions that directly address their daily pain points. That’s why achieving early, tangible success is critical. It builds credibility and helps secure continued investment.

Rather than implementing broad, I would focus on three to five high-impact use cases, such as invoice processing, contract lifecycle management, and quality documentation.

These cases should deliver measurable results within weeks rather than quarters. Each use case should be treated as its own product, with a clear value proposition and user-centric design, rather than as just another feature within a larger system.

Put adoption at the center

I used to think: “If the solution is good, people will use it.”

That’s wrong.

Adoption requires preparation. It doesn’t just happen on its own.

The hard truth is that the best ECM solution with no adoption equals failure.

What I’d do differently:

• Identify the key users early on. They will help you get the solution adopted
• Design in collaboration with actual users, not with their representatives.
• Invest time and resources in on-boarding with in-app guidance, simple training paths, and internal champions.

Remember, if users need a manual to use the solution, you’ve already lost them.

Simplify the information model

One of the biggest mistakes I’ve seen (and made) is overengineering metadata and taxonomy.

We aimed for a perfect structure. We got complexity.

The reality is that users don’t care about your taxonomy. It adds complexity, makes classification difficult, slows down their work, and ultimately reduces user adoption.

Here’s what I’m doing now:

• I’m trying to limit the number of fields to seven or fewer.
• I take full advantage of automation features, such as default values, smart classification, and recognition.
• I use an iterative approach if it results in tangible improvements.

A good structure that is used consistently is better than a perfect one that nobody follows.

Design for automation

Projects often treat automation as a second phase. For me, that’s a mistake.

Today, without automation, ECM is just a digital archive.

Here are some things to do from day one:

• It is essential to pinpoint tasks that are repetitive in nature and convert them into workflows. Examples of such tasks include approvals, classification, team collaborations, and more. This conversion process must be incorporated into the initial release.
• Use AI carefully and for meaningful topics. AI is trendy and can benefit us if we use it to accelerate work in areas such as classification, translation, and summarization, not just because it’s hype.

The goal is to eliminate unnecessary work and allow users to focus on what is important.

Measure the right things

Keep in mind that success metrics are not the number of documents migrated, users trained, or system uptime.

True success is measured by the positive impact the solution brings, such as reduced processing time, increased adoption, improved compliance, and saved time.

Measure the real impact to prove added value.

Treat ECM as a product, not a project

This is a common mistake that I still often see during ECM implementation, and it needs to change.
An ECM is not a static project consisting of analysis and implementation, and then it’s finished.

We must adopt an agile approach of building, learning, improving, and repeating.

As soon as users start using the solution, we must maintain a backlog of improvements, perform regular releases, and continuously gather user feedback.

An ECM project is never truly finished because it must evolve with business needs. Otherwise, businesses will adapt their work to the tool and slowly abandon it.

Don’t forget the governance

Although governance is essential, it can also become an obstacle.

I’ve seen governance frameworks delay projects by several months because they lack flexibility.

Nothing is perfect, so while you should meet compliance requirements, keep things simple.

Clearly define responsibilities from the start:

• Who is responsible for metadata?
• Who approves changes?

Ensure that governance remains light and practical.

Strike the right balance between control and ease of use.

Think about who you’re doing it for.

Although IT leads this type of project, users are often not part of the team.

Therefore, establishing strong collaboration between IT and business users is crucial.

Involve users in the decision-making process.

Hold them accountable for adoption, this is a company-wide project, and its success depends on them.

The platform is just a tool

To sum up my years of experience in ECM.

While it’s initially reassuring to master a product and understand its inner workings, ultimately, clients don’t care about that.

They have various problems and want a solution and very often, the specific product doesn’t matter.

They count on us to recommend the most suitable solution because they are busy running their business and don’t have time to compare products on the market.

ECM success isn’t just about managing documents; it’s about enabling better work.

• Help users work more efficiently.
• Provide business value.
• Improve the user experience over time.

If you’re about to start a project, ask yourself:

• Are we solving real problems?
• Are users involved from day one?
• Are we delivering value early on?

If not, now is the perfect time to ask us for help!

L’article After years of ECM projects, here’s how I do things differently nowadays est apparu en premier sur dbi Blog.

The aggregation is what transforms the set of matching objects into a value the widget can render. There are five aggregation types, six reducers, and one optional second dimension (seriesProperty). Together, they cover every widget shape from a single KPI number to a cross-tab pivot table.

1. The two-dimensional model

The aggregation has two complementary components:

• The aggregation type is the shape of the result: one value (summary), one value per group (groupByProperty), one value per time bucket (groupByDateBucket), one value per admin-defined range (groupByRange), or a simple list of objects (list).
• The aggregation reducer is the operation applied within each group (or over the whole matching set for summary): count (default), sum, avg, min, max, median. Note: The reducer is ignored for list.

In other words, type decides whether you get a number, a chart, or a table; reducer decides what that number, bar, or cell actually measures.

2. The five aggregation types

2.1. summary – one value over everything

summary reduces the entire matching set into a single value. By default it counts the matching objects. However, with a different reducer, you can make it compute a property aggregate in different ways. Here are a few example of summary aggregations:

// Total count of matching objects
"aggregation": { "type": "summary" }

// Total revenue of matching objects
// (sum all values from the "Amount" property)
"aggregation": {
  "type": "summary",
  "reducer": "sum",
  "reducerProperty": "Amount"
}

// Latest contract expiry date
// (display only the date with the highest value - drill-through still list all objects)
"aggregation": {
  "type": "summary",
  "reducer": "max",
  "reducerProperty": "Effective through"
}

The widgets that accept summary are kpiNumber, gauge, and table. If you followed this series, you probably saw a bunch of the first two, already. The last one, in this case, will render the value as a one-row table. For all other chart widgets (donut, bar, line, area), summary does not really make visual sense, as a single value cannot be plotted on an X-Y axis.

2.2. groupByProperty – one value per group

groupByProperty groups objects by the distinct values of a property (the propertyName) and applies the reducer to each group independently. Here are two examples:

// Count of matching objects per Agreement type
"aggregation": {
  "type": "groupByProperty",
  "propertyName": "Agreement type",
  "includeEmptyResults": "No"
}

// Total revenue of matching objects per Customer
// (sum all values from the "Amount" property for each Customer independently)
"aggregation": {
  "type": "groupByProperty",
  "propertyName": "Customer",
  "reducer": "sum",
  "reducerProperty": "Amount"
}

The supported fields are the following ones:

The widgets that accept groupByProperty are donut, bar, line, area and table. Basically, all charts widgets, plus the table which is kind of a Swiss knife, that works with everything.

2.3. groupByDateBucket – one value per time period

It is very similar to the groupByProperty, but the target must be a date / timestamp. Basically, something that contains a date, whether its only the date or a full date-time is fine. Because dates would probably be a bit too wide, there is a concept of buckets, to group dates by a pre-defined range that might make sense. The default time periods are day, week, month, quarter or year. Here are two examples:

// Count of contracts expiring per month
"aggregation": {
  "type": "groupByDateBucket",
  "propertyName": "Effective through",
  "bucketSize": "month",
  "includeEmptyResults": "Yes"
}

// Sum of invoice amounts per quarter
"aggregation": {
  "type": "groupByDateBucket",
  "propertyName": "Invoice date",
  "bucketSize": "quarter",
  "reducer": "sum",
  "reducerProperty": "Amount"
}

The supported fields are pretty similar to the groupByProperty:

Note: you would usually combine groupByDateBucket with a date filter to limit the range of results. Without filters, the chart would show everything from the earliest object in the vault to the most recent, possibly spanning decades. If that’s what you want to see, then that’s absolutely fine. However, most of the time, a filter like between @startOfYear and @endOfYear for an annual trend chart might be more appropriate.

2.4. groupByRange – one value per admin-defined range

This one is also very similar to the last two groupings. With the main difference that this is the only one that allows you to define the exact range.

2.4.1 The groupByRange itself

If you have a certain property that has a high cardinality, it might be difficult to display it with a groupByProperty. Let’s take for example the “Amount” property from before. When you want to apply math on it (sum/avg/min/max/median), then that’s fine because it only returns one value. But if you want to see the revenue themselves, without a prior grouping on something else (e.g. above we first group by “Customer”), then you would end-up with dozens/hundreds/thousands of groups? That’s where groupByRange shines, because you define the grouping (e.g. 0-1’000, 1’000-5’000, >=5’000).

You can use that grouping method with numeric / time / text / lookup properties. On the other hand, date / timestamp and boolean aren’t supported. The reason for that is simple: there is already groupByDateBucket for date / timestamp, and boolean can only have 2 values (Yes / No), so groupByProperty works just fine.

// Invoices by specific range
// 3 ranges: 0-1000, 1000-5000, 5000-10000
"aggregation": {
  "type": "groupByRange",
  "propertyName": "Amount",
  "boundaries": ["0", "1000", "5000", "10000"]
}

// Invoices by specific range, with open ranges
// 4 ranges: 0-1000, 1000-5000, 5000-10000, >=10000
"aggregation": {
  "type": "groupByRange",
  "propertyName": "Amount",
  "boundaries": ["*", "1000", "5000", "10000", "*"]
}

// Efficiency / speed of processing / duration of some actions / etc...
// 4 ranges: 0-30s, 30s-1min, 1min-2min, >=2min
"aggregation": {
  "type": "groupByRange",
  "propertyName": "Duration",
  "boundaries": ["*", "00:00:30", "00:01:00", "00:02:00", "*"]
}

// Customers by country name
// 3 ranges: A-F, F-M, >=M
// e.g. "France" in 2nd group, Switzerland in 3rd group
"aggregation": {
  "type": "groupByRange",
  "propertyName": "Country",
  "boundaries": ["A", "F", "M", "*"],
  "reducer": "count"
}

Again, the supported fields are fairly similar to the groupByProperty:

2.4.2. How boundaries work

Each boundary value marks the inclusive lower bound of a range and the exclusive upper bound of the range below it, except for the last range, which is fully inclusive. For example, ["0", "1000", "5000", "10000"] creates three buckets: [0, 1000), [1000, 5000) and [5000, 10000]. This means that a value of “1000” will end-up on the 2nd bucket only. A value of “5000” or “10000” will end-up on the 3rd bucket.

In addition, as you can see in the examples above, you can use a wildcard ("*") on either end: a leading "*" creates a bucket for everything below the first boundary, and a trailing "*" creates a bucket for everything at or above the last boundary.

2.5. list – one row per object

list are pretty similar to search results from M-Files, in the sense that it will just list something, with pre-defined columns. When using this aggregation type, the reducers have no effect, because it only lists objects but do not apply any modifications / computing on them.

// List all contracts with 3 specific columns
"aggregation": {
  "type": "list",
  "displayProperties": ["Agreement type", "Effective through", "Responsible person"]
}

For simple lists, the objects will be pre-sorted alphabetically but the user is then able to re-sort them, by each of the columns displayed. When drillThroughEnabled is set to “Yes”, then table rows become clickable and allows navigation to the object in question. There is no modal/drill-through in this case, since the table list already display the target object (no grouping).

3. The six reducers

As mentioned, all five aggregation types, except list, accept a reducer. You probably understand them already, but just as a quick table:

3.1. The date/time-valued reducer rule

When min or max is applied to a date, timestamp, or time property, the reducer returns the value and it will be formatted for end-users based on their localization / regional settings: e.g. DD/MM/YYYY for dates, DD/MM/YYYY HH:mm for timestamps (minute precision), and HH:mm:ss for times.

When sum, avg or median is applied to a time property, it allows you to compute a total (or average/median) duration for a certain activity. This might be useful if you have time-constraints.

Three widgets can render date/time values: kpiNumber (a single big number), gauge (switch to date mode, covered in Post 4a) and table (simple display in rows).

4. seriesProperty – the second dimension

The series details were already covered a bit in the posts 4b and 4c. But, this is the feature that turns a single-series widget into a multi-actor comparison. When you set a seriesProperty on a groupBy aggregation, the engine will automatically produce one series per distinct value of the series property. This allows a two-dimensional comparison.

The behavior per widget type is the following:

• line / area – one colored line per series, with an auto-generated legend.
• bar – one colored sub-bar per series (display.barLayout controls stacked vs grouped).
• donut – a multi-mini-pie grid, one donut per series, with a shared legend.
• table – a cross-tab pivot, one column per series.

As a reminder, kpiNumber and gauge ignore seriesProperty, since they only display single-values.

4.1. Use low-cardinality series only

I repeated this in every widget post but it is worth restating: seriesProperty should be low-cardinality. A property with five distinct values produces a readable multi-series chart. A property with two hundred values produces a colored mess. In that case, you might want to use a groupByRange, to reduce the amount of groups and therefore the series.

4.2. includeEmptyResults in multi-series

In single-series mode, includeEmptyResults: “Yes” fills empty time buckets with zero values. In multi-series mode, it does the same across both dimensions: every series gets a zero in any bucket where it has no data. This avoids broken lines and visually confusing gaps.

The behavior also adds a (none) bucket for objects whose primary group property has no value, and a (none) series for objects whose series property has no value. These are appended at the end so it doesn’t disrupt the “main story”.

4.3. Multi-select lookups in seriesProperty (and propertyName)

A subtle but important case: as you probably know, M-Files has a multi-select lookup property type. These allow the selection of multiple pre-defined values. Because of that, objects with multiple values will end-up in multiple buckets/groups, with the “counted once per value” rule.

Example: a customer with office locations in Geneva, Zurich and Berlin could appear three times, once for a Geneva bucket, once for a Zurich bucket and finally once for a Berlin bucket. The total of all bucket counts can therefore exceed the total number of objects when some objects have multiple values.

This is the correct and expected behavior for multi-select lookups. The alternative (counting each object only in its first value) would silently hide the multi-value relationships that often matter most.

5. displayProperties on drill-through

I mentioned displayProperties in section 2.5 above, as optional column to be added for list aggregations. The same field has a second role for all other aggregation type (summary, groupByProperty, groupByDateBucket, groupByRange): it controls the columns in the drill-through modal.

"aggregation": {
  "type": "groupByProperty",
  "propertyName": "Agreement type",
  "displayProperties": ["Effective through", "Responsible person"]
}

When the user clicks a donut slice (or a bar, or a row in a count table), the drill-through modal shows one row per object in that group, with the object name plus all the optional columns defined in the displayProperties value (e.g. Effective through and Responsible person).

6. The compatibility cheat sheet

I already put this table at the end of Post 4c, but it is short enough, so:

Combine this with the reducer table in section 3 and you have the full answer to “can I use aggregation X with widget Y, and with reducer Z on property type T”. In any case, the Visual Designer and the validation process will prevent you to make any mistake.

7. What this gives you

The query side (Post 5) plus the aggregation side (this post) together cover everything the engine supports. If that wasn’t the case before, you should now be able to read and understand every line from any of the previous JSON example.

The combinations are richer than they look at first. A groupByDateBucket on monthly invoices with a sum reducer on Amount and a seriesProperty on Customer, rendered as a line widget with includeEmptyResults: “Yes”, gives a multi-customer revenue trend that takes about 15 lines of JSON. A groupByProperty on Agreement type with a seriesProperty on Workflow state rendered as a table gives a cross-tab pivot with drill-through on every cell.

The possibilities aren’t endless, obviously, but good luck if you would like to try them all… Last time I checked, you could create several million different widget combinations. An important part of that would trigger warnings or errors for non-supported cases, but still a considerable scale.

So far, I covered the end-user part, the JSON, the widgets and now the queries. These are the building blocks of dashboards. The remaining posts of the series will cover:

• Post 7 – The Admin tab: the actions, Visual Designer / JSON editor, the two-stage validator, import / export, access control.
• Post 8 – Building a dashboard with the Visual Designer.

Want to know more about this Business Dashboard? Contact us and we will be happy to showcase it on M-Files.

L’article M-Files BD – Aggregations, reducers and series est apparu en premier sur dbi Blog.

A query has four parts: objectType, class, filters, and aggregation. This post covers the first three. The fourth (aggregations, including its reducers) is the topic of the next post.

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

1. objectType – the M-Files object type to query

Every query starts with objectType. 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).

1.1. Single object type

The simplest form is a string:

"objectType": "Document"

Or any other object type defined in your vault:

// Looking for Customers
"objectType": "Customer"

// Looking for Projects
"objectType": "Project"

// Looking for Employees
"objectType": "Employee"

The display name is case-insensitive 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.

If the name does not match, the widget shows a clear ✗ Object type ‘xxx’ not found in this vault error.

1.2. Multiple object types

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:

"objectType": ["Document", "Document collection"]

The engine resolves every name and builds a single search to find all matching objects. This behaves like the “is one of” filter in M-Files Advanced Search. Please note that the Drill-through will also inherit the same scope, automatically.

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 cap applies, not two independent caps).

2. class – narrowing the scope (and the perf impact)

The class field is optional but strongly recommended. It restricts the query to one specific class:

"objectType": "Document",
"class": "Contract or Agreement"

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” narrows the scan immediately, which both improves performance and makes the widget result more meaningful.

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, when possible.

When objectType is an array and class 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:

"objectType": ["Document", "Document collection"],
"class": "Proposal"

If the class is misspelled, the widget shows a ✗ Class ‘xxx’ not found on the specified object type(s) error. As with object types, the name depends on what the vault defines/shows.

3. filters – the AND-combined conditions

The filters array, which is optional, contains zero or more conditions. If you specify multiple filters, then all filters must match. 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” where you can set multiple values from the Lookup/MultiSelectLookup property values. But that’s only a single condition, not multiple conditions.

Here is an example of a filter:

"filters": [
  { "property": "Effective through", "operator": "greaterOrEqual",
    "value": "@today", "valueType": "dateToken" },
  { "property": "Agreement type", "operator": "equals",
    "value": "Subcontracting Agreement" }
]

Each filter has up to four fields:

• property: the property display name on which to apply the operator / value.
• operator: one of the operators listed in section 4 below.
• value: the value to use for the comparison with the property’s actual value. For the four “presence” operators (isEmpty, isNotEmpty, isPresentEmpty, isPresentNotEmpty), this parameter should NOT be defined. For the “begin-end” operators (between / notBetween, this parameter should be an array of two elements. For the “is one of” operators (inList / notInList), this parameter should be an array of at least two elements. Finally, in all other cases, it’s simply a string.
• valueType: either “literal” (default, it means to use the value as-is) or a “dateToken” (covered in section 5).

4. The filter operators

The engine supports a rich set of operators across two execution paths:

• Native: runs server-side before the serverScanMaxResults cap is applied. Therefore, this is the preferred option, when possible.
• Post-filter: runs in memory after the server returns up to serverScanMaxResults objects. Therefore, this is correct and useful when you want to do something that M-Files doesn’t support out-of-the-box but that still makes sense for your Business use-case.

In short, whenever possible, prefer to apply a native filter. The main reason for this is simple. Let’s assume that you have 1’000 Contracts in the vault:

• If you apply a native filter, for example Effective through >= @today, then if only 200 of them match that criteria, then M-Files will only return these 200 objects directly. There is no loss of performance here.
• If you apply a post-filter, for example Effective through contains 2026-12, then M-Files will have no other choice than returning all 1’000 Contracts first. On top of that, the post-filter compares the value of Effective through and checks whether it contains “2026-12”. This is because the “contains” condition doesn’t exist in M-Files for Date properties. Therefore, we cannot use what doesn’t exist, but we still want to provide that possibility / logic, and therefore it is done in memory after returning all results. In that example, you get 5x more results and on top of it, you also need to check which ones match the expected value.

The performance difference between native and post-filter is imperceptible for small result sets (<few hundreds), but you would probably feel it if you expect to fetch thousands of results. A great catch, if you need to apply a post-filter for a valid business reasons, is to first apply a native one, which highly reduces the result set, and then apply the post-filter one that you need. Also, don’t forget to specify a class!

Then, let’s proceed with a deep-dive on the different operators (if you only want the “summary”, look at the end of section 4 for the cheat sheet). The 22 operators support all data types, without exceptions, contrary to M-Files operators which offer much less capabilities. The only distinction is, as mentioned above, whether the operator is native or post-filter.

4.1. equals and notEqual

As you would expect, these are for exact match. Only the MultiLineText properties are processed as post-filter.

{ "property": "Agreement type", "operator": "equals",
  "value": "Subcontracting Agreement" }

{ "property": "Customer", "operator": "notEqual",
  "value": "ESTT Corporation (IT)" }

When using display names on Lookup properties (Lookup or MultiSelectLookup), as its the case in above example, the value lists are cached, so that each execution doesn’t need to re-fetch the things that it already knows of, and it can just use it directly, to ask M-Files what’s the updated count.

4.2. lessThan, greaterThan, lessOrEqual, greaterOrEqual

These “range” operators support all property types except Boolean, because it doesn’t make any sense to apply a “lessThan” to a Boolean… In addition, and similarly to above, only the MultiLineText properties are processed as post-filter, everything else is native. Obviously, you can apply these operators on Date and Numeric values, but it also works with Text, Lookup or MultiSelectLookup. When it needs to work on Text-based properties, it does a lexicographic comparison (e.g. ABC < ABD, ACE > ABB).

{ "property": "Due date", "operator": "lessThan",
  "value": "@today", "valueType": "dateToken" }

{ "property": "Amount", "operator": "greaterOrEqual", "value": 1000 }

4.3. between and notBetween

These as also “range” operators but I put them separately because the value must be a two-element array, as previously written. between is, otherwise, exactly the same as lessThan/greaterThan/lessOrEqual/greaterOrEqual. In the array, you would provide the begin and the end of the range. to fetch.

{ "property": "Effective through", "operator": "between",
  "value": ["@startOfYear", "@endOfYear"], "valueType": "dateToken" }

{ "property": "Amount", "operator": "between", "value": [100, 1000] }

notBetween is the opposite of between, obviously, but it’s a bit more than that… As previously mentioned, M-Files does NOT handle OR logic. But if you think about it, a “notBetween” is actually an OR, because you want values below the range OR above the range (value < low OR value > high). Because of that, notBetween is always a post-filter, without exception.

{ "property": "Amount", "operator": "notBetween", "value": [100, 1000] }

4.4. isEmpty, isNotEmpty, isPresentEmpty, isPresentNotEmpty

These four operators test whether a property has a value, as the name suggests… However, there is a catch: M-Files only distinguish between “the property is present and empty” or “the property is present and non-empty”.

You might have faced that with Templates for example. That’s a pretty common occurrence. In M-Files, there is a parameter “Is template” which indicates whether a specific object has been defined as a template. But that parameter is only present in a few select objects, it’s usualy not present on all of them. Therefore, if you search for “Is template – is empty”, you will most probably find 0 results, because M-Files only check for documents where the property is present and where it is empty.

The distinction is simple but it matters a lot. That’s why in the Business Dashboard, the native M-Files “is empty” / “is not empty” have been renamed as isPresentEmpty and isPresentNotEmpty. These are the fully native option from M-Files, and therefore they run on the server-side.

{ "property": "Effective through", "operator": "isPresentEmpty" }

{ "property": "Responsible person", "operator": "isPresentNotEmpty" }

In addition, I also defined two other operators, isEmpty and isNotEmpty. These two are always post-filters, they scan all matching objects in memory after the server returns them:

{ "property": "Effective through", "operator": "isEmpty" }

{ "property": "Responsible person", "operator": "isNotEmpty" }

Because of that post-processing, isEmpty matches objects where the property is absent OR where it is present but empty. This allows a more “complete” result set, which might be required in some specific business use-cases.

isNotEmpty matches objects where the property is present AND non-empty. You might think it is exactly the same as isPresentNotEmpty, right? Well, in 99% of the cases, yes it is the same (but slower, since done as post-filter)… Except when there are bugs in M-Files ;). While developing the Business Dashboard, I found a few bugs, including one with lexicographic processing on MultiSelectLookup properties. The usage of my own operator was giving me a slightly different result and while investigating why, I found the reason and the bug in M-Files’s own operator.

In summary:

4.5. inList and notInList

As the name suggests, if you are looking for multiple values, inList is what you should use. It must be an array of at least 2 elements, but you can put 50 if you want to. M-Files only support Lookup for this one, natively. Therefore, all other property types are handled as post-filters.

{ "property": "Agreement type", "operator": "inList",
  "value": ["Subcontracting Agreement", "Project Agreement"] }

{ "property": "Workflow state", "operator": "inList",
  "value": ["In review"] }

notInList is simply the opposite, so it just excludes all elements provided. It supports exactly the same thing as inList and works in the same way too.

{ "property": "Workflow state", "operator": "notInList",
  "value": ["Approved"] }

A subtle catch with “not” operators (notInList and similar): an object whose Lookup property is present but has no item selected satisfies “not in list” by default, because there is no value to match or compare with. If you don’t want to see these objects, then you can simply add a second filter on that same property with isPresentNotEmpty!

4.6. contains and doesNotContain

contains is a substring match (similar to matchesWildcardPattern (c.f. below) with implicit wildcards on both sides), it finds objects where the property value includes the given string anywhere inside.

{ "property": "Title", "operator": "contains", "value": "NDA" }

{ "property": "Title", "operator": "doesNotContain",
  "value": "draft" }

For Text, MultiLineText and Lookup properties, both operators are native. The rest is supported as post-filters, comparing against the string representation.

4.7. startsWith, doesNotStartWith, endsWith, doesNotEndWith

startsWith and doesNotStartWith match objects based on the beginning of a property’s value. These are native only for Text and Lookup properties.

{ "property": "Name or title", "operator": "startsWith",
  "value": "PO-"    }

{ "property": "Name or title", "operator": "doesNotStartWith",
  "value": "DRAFT-" }

endsWith and doesNotEndWith match based on the end of a property’s value. This doesn’t exist in M-Files, there is no equivalent and therefore, these are always post-filters for all property types.

{ "property": "Name or title", "operator": "endsWith",
  "value": "(final)" }

{ "property": "Name or title", "operator": "doesNotEndWith",
  "value": "(draft)" }

4.8. matchesWildcardPattern and doesNotMatchWildcardPattern

These are the most expressive pattern operators. The value is a regex string where \* matches any number of characters and ? matches exactly one character. This is pretty similar to the contains/startsWith/endsWith (and their opposite), obviously, but it is a bit more powerful if you need to match an exact pattern that you know of.

{ "property": "Title", "operator": "matchesWildcardPattern",
  "value": "PO-????-2026" }

{ "property": "Title", "operator": "doesNotMatchWildcardPattern",
  "value": "ID-*" }

4.9. Complete operator reference

You reached this point, so it’s time to have a cheat sheet of all operators. In the below table:

• Text and MultiLineText are NOT interchangeable
• “Lookup” includes both Lookup and MultiSelectLookup (these ARE interchangeable – one exception for between on MultiSelectLookup because of a bug in M-Files – the one I mentioned above)
• “Date” includes Date, Time and Timestamp (these ARE interchangeable – one exception for notEqual on Timestamp because of a bug in M-Files – not the same as the one mentioned above)
• “Numeric” includes Integer, Integer64 and Floating (these ARE interchangeable) (“integer”/”real”)

4.10. Pattern operators on date properties

All pattern operators (contains, startsWith, endsWith, matchesWildcardPattern and their negations) work on date properties via the post-filter path, comparing against the ISO yyyy-MM-dd string representation (or yyyy-MM-dd HH:mm for timestamp or HH:mm:ss for time properties). This opens up some convenient patterns, even with “valueType”: “literal”:

{ "property": "Effective through", "operator": "startsWith",
  "value": "2026" }

{ "property": "Effective through", "operator": "startsWith",
  "value": "2026-04" }

{ "property": "Effective through", "operator": "endsWith",
  "value": "-31" }

{ "property": "Effective through", "operator": "matchesWildcardPattern",
  "value": "2026-??-??" }

And with “valueType”: “dateToken”, the token resolves to a full ISO date used as the exact string pattern:

{ "property": "Effective through", "operator": "contains",
  "value": "@today", "valueType": "dateToken" }

{ "property": "Effective through", "operator": "startsWith",
  "value": "@startOfMonth+5d", "valueType": "dateToken" }

A resolved token produces a full ISO date for the operators, c.f. next section for a deeper dive into dateToken details.

5. Date tokens – relative filters that always make sense

Hardcoding a date like “2026-01-01” in a filter works, but it ages badly. The dashboard built today shows different data on January 2nd than it did on December 31st, because the filter is now relative to a different “today”.

Date tokens solve this. Any string value used with “valueType”: “dateToken” is resolved to an absolute date at query execution time, so the dashboard stays meaningful as time passes.

5.1. Anchor tokens

The following anchors are recognized:

So @startOfYear, at the time of writing this blog (i.e. in 2026) is 2026-01-01 00:00:00. Starting from January 1st 2027, the same token will automatically resolve to 2027-01-01 00:00:00 instead. Therefore, the dashboard rolls forward automatically.

If there is a need to add more date tokens, it’s always possible.

5.2. Offsets: days, hours, minutes, and seconds

Any anchor presented above can be followed by one or more offsets to add or subtract time:

Each offset uses d for days, h for hours, m for minutes, and s for seconds. As you can see above, offsets can be chained together in any order, so @today+2d+10h+30m is valid, as is @now-8h+30m.

The day offset is calendar days, not business days. There is no built-in concept of holidays in the engine as of now.

5.3. Fixed ISO dates (with optional offset)

A literal ISO date works as both literal as well as a date token. However, if you want to apply an offset, then only dateToken can be used. As previously mentioned, “literal” really means a literal strings, so there is no computation done on it.

{ "property": "Effective through", "operator": "greaterOrEqual",
  "value": "2026-01-01+90d", "valueType": "dateToken" }

This resolves to 2026-04-01 00:00:00, at query time. This can be useful when you want a stable absolute anchor but with an offset relative to it.

5.3a. When to use @now instead of @today

The key difference between @now and @today is that @now captures the current time including hours, minutes, and seconds, while @today is truncated to midnight.

Use @today for day-level filters (most common): “contracts expiring within 30 days”, “documents created this month”. Use @now when you need intra-day precision: “events logged in the last 2 hours”, “tasks to process in next 4 hours”. Examples:

// All activity since this morning at 7am (a fixed time each day)
{ "property": "Modified", "operator": "greaterOrEqual",
  "value": "@today+7h", "valueType": "dateToken" }

// Flagged tasks created in the last 8 hours
{ "property": "Created", "operator": "greaterOrEqual",
  "value": "@now-8h", "valueType": "dateToken" }

6. Boolean filter values

For boolean-typed properties (M-Files “Boolean (yes/no)”), the engine accepts both “Yes” / “No” and “True” / “False” (case-insensitive):

{ "property": "Accepted", "operator": "equals",
  "value": "Yes" }

{ "property": "Accepted", "operator": "equals",
  "value": "True" }

“Yes” / “No” is the preferred form because that is what M-Files displays in the UI and what users see in their property cards. Worth noting: the M-Files Admin label “Boolean (yes/no)” is always English even on a localized vault. So you do not need “Ja” / “Nein” mappings on a German vault (at least as of today).

7. Wrap-up

The query model covers the questions that come up in practice. objectType and class define the scope, filters narrow it with a rich set of operators spanning native server conditions and post-filter cases. Date tokens make filters relative without effort.

What is not in this post: the aggregation block. That is the topic of Post 6, which covers the aggregation types, the reducers, and the multi-series seriesProperty feature. Once those are explained, every JSON block in the widget posts will make complete sense.

Want to know more about this Business Dashboard? Contact us and we will be happy to showcase it on M-Files.

L’article M-Files BD – Queries: objectType, class, filters, date tokens est apparu en premier sur dbi Blog.

When everything was delivered on time and within the budget. Yep it’s not fiction, it happens really

Every KPI is green!

At the last steering committee meeting, congratulations were in order. A slide presentation highlighted the project’s key milestones, its features, and its smooth rollout. Everyone agreed that it was an exemplary project.

However, month after month, interest gradually declined and fewer employees used it.

There was no official postmortem or formal acknowledgment. It just gradually faded into irrelevance.

This is the story of a project that seemed successful but actually wasn’t.

Why does it look successful?

At first glance, everything seems perfect:

• Deadlines are respected.
• Budget is controlled.
• Scope is delivered.
• Stakeholders are informed.

All of the classic project management success criteria were met.

However, those metrics measured output, not outcome.

No one asked the simple question:

Did the project actually solve the intended problem?

Behind the illusion

Under the surface, cracks were real, if you knew where to look.

Here are some key points:

Users

The training sessions were completed. The documentation was published.

But what about adoption? It remains minimal.

Employees continued to use spreadsheets, emails, and old tools. Though technically superior, the new system felt like a constraint rather than support.

It wasn’t part of their workflow. It was an extra step.

Requirements

The team implemented everything according to the original specifications.

However, no one ever questioned those specifications.

Also, the team wrote them too early, based on assumptions and disconnected them from actual user behavior.

As a result, the project delivered exactly what stakeholders requested,but not what users needed.

Success was narrowly defined

The project team optimized for:

• Delivery speed
• Cost control
• Scope completion

What they didn’t optimize for:

• User adoption
• Business impact
• Long-term value

When success is defined narrowly, failure has space to hide.

Feedback ignored

During the pilot phase, users raised concerns:

• “This doesn’t fit our daily work.”
• “This adds complexity.”
• “We don’t see the benefit.”

Rather than viewing these signals as valuable insight, they were labeled as resistance to change.

It’s easier to push forward than to pause and rethink.

Premature victory

Once the project was delivered, attention shifted elsewhere.

There was no plan for:

• Adoption tracking
• Continuous improvement
• Measuring real outcomes

The project ended when it should have evolved.

The cost behind that

Because everything appeared successful, the failure went unnoticed.

But the cost was real:

• Lost investment
• Frustrated users
• Erosion of trust in future initiatives
• Reinforcement of shadow IT (spreadsheets, workarounds, etc.)

Even worse, the organization learned the wrong lesson:

“We know how to deliver successful projects.”

Lessons learned

As I’ve written several times in previous blog posts, ECM failures are rarely due to the solution itself.

Rather, they are due to how it was implemented and the lack of improvements after it went live, an ECM is a living system.

Here are some point that need to be appreanded differently:

Redefine success

Move beyond the classic triangle of time, cost, and scope.

Focus on what brings business value:

• adoption
• user satisfaction
• simplification and consolidation of processes

If people don’t use it, it’s not successful.

Be realistic

Specifications should not be set in stone.
They should evolve based on the following:

• user feedback
• iterations
• real-world testing

Projects fail when assumptions take precedence over observation.

Think critically

A fully green status report can be misleading.
Ask deeper questions:

Are users engaged?
Are behaviors changing?
Is there a measurable impact?

If the answers are unclear, the project isn’t finished.

Go-Live is the beginning

Delivery is not the finish line, but rather the starting point.
Real success happens after adoption, iteration, and proven value.

Listen to resistance

Resistance is often misinterpreted.

It is rarely a matter of resistance to change, but rather a matter of recognizing that every complaint reveals a discrepancy and provides a clue for improvement.

Finally

The most dangerous projects are not the ones that fail visibly. When a project fails, we know why.

The real danger lies in projects that succeed…on paper.

Everything looks good because we aren’t considering what makes sense.

It’s important to keep in mind who we’re doing those kinds of projects for: the users, and why: to help them with their daily work.

Everything else is nonsense.

If you’re interested in making your ECM project with M-Files a true success, feel free to contact us at dbi services, we’d be happy to help.

L’article A project that looked successful. But… est apparu en premier sur dbi Blog.