The answer comes back immediately: a clear, precise quote from the contract. It sounds right, so nobody checks it. However, the quoted contract is an expired draft. The signed amendment that changed the notice period is stored somewhere else entirely.

This is a hypothetical scenario, but I believe similar situations are already occurring. It illustrates what I think is the most underestimated aspect of AI in ECM: a poor search result is obvious, but a poor AI response can be convincing.

AI turns content quality into a risk

Before AI, poor content quality was mostly just an annoyance. Searches took longer and users had to scroll through several versions of the same document, but they usually noticed when something looked wrong. Humans were still the filter.

With AI, however, this filter becomes less effective. The assistant reads the content, selects what it deems relevant and presents a coherent summary. Users may never see the other versions, outdated drafts or documents that contradict the answer.

In my post on information debt, I wrote about the shortcuts organizations take with their content and the price they pay later. AI is often the moment when that debt becomes payable. All those duplicates, forgotten drafts, and incomplete properties are now the raw material that your AI works with.

AI does not fix messy content. It simply reads it faster, summaries it with confidence and spreads the mess further.

What AI struggles with in typical repositories

When I look at how content is usually managed, I see five recurring problems.

Duplicates and near-duplicates. Which version is the truth? A person might know from experience. An AI assistant has no instinct for this unless the system gives it clear signals.

Outdated content. A procedure valid in 2019 sits next to the current one. Both are well written, and both look equally credible.

Missing or inconsistent metadata.. AI depends on context: the type of document, its status, its owner, the period it applies to. When the “Status” property is empty, or means different things in different departments, that context disappears. I covered part of this in The metadata trap. Metadata can fail by being too complex, and it can also fail by being unreliable.

Missing relationships. A contract, its amendments and its invoices tell one story. If they are stored as separate islands, the AI sees fragments. This is exactly the point I made in The forgotten power of relationships in ECM.

Unclear authority. Is this document a draft or approved? An internal opinion or an official policy? Without lifecycle information, an AI can’t tell the difference, and often neither can the user.

The good news: ECM discipline is AI readiness

Here’s what I find reassuring: All the features that make content manageable in an ECM also make it trustworthy for AI:

• Lifecycle and status tell the AI what is current and approved.
• Metadata tells the AI what a document is and what it applies to.
• Relationships show which documents belong together.
• Permissions determine what each user’s AI is allowed to see.

The practices we have promoted for years, such as clear metadata, defined workflows and linked objects, were not just housekeeping measures. They provide the context that transforms a collection of documents into a knowledge base that an AI can utilize responsibly.

I made a similar point in ‘ECM + AI: achieving optimal synergy’: AI does not replace a well-structured ECM; it depends on it.

The permissions blind spot

There is one more risk that deserves its own section because it takes many organizations by surprise.

For years, content that was shared too widely was protected by obscurity. A document might be accessible to more people than intended, but it would remain hidden because no one was looking for it. AI changes that. An assistant that can search and summarize everything a user has access to will surface content in seconds that nobody knew was reachable.

Therefore, before enabling AI features, check who can access your sensitive content. This includes broad groups, inherited rights, and shared links. It is much better to discover over-sharing during a controlled review than through an AI-generated response in front of the wrong person.

A practical way forward

Making all content ‘AI-ready’ can seem overwhelming, but it doesn’t have to be. Here is the approach I would recommend:

Start with one use case, rather than the entire repository

Choose an area where AI could clearly add value, such as contracts, quality procedures or customer documentation. Prepare that content first.

Define what ‘authoritative’ means

Decide which statuses, document types and validity dates identify trusted content. If your team cannot answer the question ‘What counts as the official version?’, neither can the AI.

Remove the obvious noise

Archive or delete expired, duplicate and abandoned documents. This is where the lifecycle thinking from my earlier posts comes in useful.

Fix the important metadata

Don’t try to perfect every property. Focus on the ones that users and AI rely on, such as type, status, owner, validity and relationships with related objects.

Review permissions before activation

NOT AFTER!

Keep a human in the loop at the beginning

Require AI answers to show their sources so that users can verify them. During the pilot, review the results and collect feedback on incorrect or unexpected answers.

Measure and provide feedback

When an answer is incorrect, establish the reason why. This is usually due to a content problem, such as a missing status or a duplicate. Fixing these issues improves every future answer.

AI can help with the cleanup too

This doesn’t mean that you have to have perfect content before you start. AI can help you achieve this. As I explained in M-Files AI: From Intelligent Metadata to AI Agents, it can suggest properties, classify documents, and identify similar content. This makes it a useful tool for identifying duplicates and filling in missing metadata.

A sensible approach is to work in cycles rather than gates: improve the content a little, use AI, see where it fails, then improve it again. However, it is important to have a human validate what the AI suggests, especially for properties that drive decisions.

A simple readiness check

Ask yourself the following questions about the content that AI would use:

• Can you tell whether any document is current and approved?
• Are the metadata for your key document types consistent and complete?
• Do you have an idea of how many duplicates exist of your most important content?
• Are related documents linked to each other?
• Do you know who can access your sensitive content, including via shared links?
• Can every AI answer be traced back to a source that users can verify?
• Is the quality of this content owned by someone?

If you answered “no” or “I don’t know” to several of these questions, that’s not a reason to stop. It’s a reason to start preparing!

Conclusion

AI readiness isn’t a separate project. Rather, it is what good ECM practice looks like when you finally ask your content to do more than just sit in a repository. It also provides a business reason to invest in quality work that was often postponed in the past.

The organizations that benefit most from AI won’t necessarily be those with the most advanced model. They will be the ones whose content can be trusted.

Have you tested AI features on your own content yet? I’d be interested to hear what surprised you.

L’article Is your content ready for AI? est apparu en premier sur dbi Blog.

The permission model has done exactly what it was designed to do. However, the document has now left the system with no audit trail or version control, and a copy is sitting in someone’s inbox indefinitely. Security hasn’t improved. It got worse.

I’ve seen versions of this story in many projects. This is why I think permissions are one of the most misunderstood aspects of ECM.

Permissions are a user experience decision

We tend to treat permissions as a security topic, and they are!

However, every permission rule also affects how people work every day. A rule that blocks access does more than just protect information. It also creates friction, and friction incurs a cost that is paid repeatedly.

When this cost becomes too high, people will find another way. They email files, save copies on their desktop or maintain a private folder ‘just in case’. The ECM slowly becomes the place where documents are archived, while real work happens elsewhere.

This is why I would argue that an overly restricted system does not become safer. It is bypassed.

Why do we default to control?

If restrictive models cause so many problems, why do organizations continue to build them? I can think of a few reasons why.

Fear of the worst-case scenario. Designs are driven by the one incident that everyone wants to avoid, rather than the thousand normal situations that occur every day.

Incentives that point one way. Nobody gets credit for granting access that turns out to be fine. But everyone remembers who was in charge when something leaked. Over-restriction feels like the safe personal choice, even when it isn’t the safe organizational one.

Copying the past. Many permission models are a direct translation of the old file sharing system, with the same folders, groups and exceptions that have been built up over the last fifteen years. The new system inherits this old mess, and it’s now harder to see.

The hidden costs of “just lock it down”

Over-restriction rarely shows up in a project report, but its effects are real:

• Workarounds and shadow copies. Every document that gets emailed or duplicated is a new piece of information debt.
• Access requests. Administrators and support teams spend their time granting, one exception at a time, what the model should have allowed from the start.
• Poor search. People can’t find what they can’t see. When users learn that search often returns nothing useful, they stop trusting it.
• Lower adoption. If the system blocks people during their first week, they form an opinion that’s hard to change later.

A useful indicator: look at the number of access requests you receive each month. It tells you more about your permission model than any design document.

The opposite mistake

I’m not suggesting that everything should be opened up. Some content genuinely requires strict control, such as HR files, legal matters and financial data, or anything else that is subject to confidentiality obligations. Being open by default doesn’t mean being careless.

The goal is to be deliberate. Protect what needs strong protection, strongly. Make the rest easy. Problems arise when the same level of restriction is applied to everything, simply because it’s easier than making decisions.

A better approach

These are the principles that I try to apply when designing a permission model:

Think in terms of exceptions rather than grants

For most content, ask ‘Who shouldn’t see this?’ rather than ‘Who is allowed to see this?’ Reserve the strict whitelist approach for truly sensitive content.

Use roles and context rather than individuals

If you find yourself managing permissions on a document-by-document or user-by-user basis, the model is too granular. People change roles, projects end and individual permissions are never cleaned up.

Let metadata drive access

This is an area in which a metadata-driven system like M-Files has a real advantage. When access follows properties such as project, department or confidentiality level, the permission model reflects how the business is organized rather than how a folder tree happens to look. With workspaces, this becomes even more intuitive: the context defines who is involved.

Let the lifecycle do the work

Access requirements often change as a document moves through its lifecycle. For example, a draft might be visible only to its authors, an approved version to the whole department, and an archived version to a read-only audience. If your workflow can adjust access permissions at each stage, there is no need for manual management.

Keep the model explainable

A good test is to ask yourself if you can explain your permission model to a colleague in five minutes. If administrators cannot explain it, users certainly won’t trust it. Complex permissions carry their own risks, because nobody dares to change anything.

Trust as a design principle

Another way to think about this is as follows. A permission model is not just a set of restrictions. It also reflects how much the organization trusts its people.

Granting broader access, combined with clear audit trails, can often provide better protection than blocking. People behave differently when they know access is being recorded. This approach also enables you to detect real problems instead of preventing hypothetical ones at the expense of everyday work.

Two things are key to making this approach work in practice:

• Make requesting access easy. Exceptions will always exist. If access requests are quick, visible and responded to promptly, people will use the system instead of finding a workaround.
• Explain the model. Users who understand why something is restricted will accept it far more easily than users who just see a ‘You don’t have permission’ message.

A quick self-check

If you’re wondering where your own system stands, ask yourself:

• Can a new employee do useful work on their first day?
• How many access requests do you receive per month, and what patterns do you see?
• Which content is really sensitive, and is it protected differently from the rest?
• Can you explain your permission model in five minutes?
• What workaround are people using today, and what does it tell you about the model?

The answers are usually more revealing than any audit.

Conclusion

Security and usability aren’t opposites, but they do compete for attention when you design a permission model. If you optimize only for control, you end up with a system that looks safe and pushes people to work around it.

The best permission model is one that users barely notice: it gives them what they need, blocks what truly matters, and leaves an audit trail for everything in between.

How do you handle permissions in your projects? I’d be curious to hear what has worked and what hasn’t.

L’article Permissions: design for trust, not for control est apparu en premier sur dbi Blog.

• What metadata should they contain?
• What workflow should they follow?
• Who should have access to them?

However, there is another crucial consideration: Is everything we need a document?

Or should it be something else?

• Customer
• Supplier
• Contract
• Complaint
• Invoice
• Project
• Product

In a traditional document management mindset, we tend to think about everything as a file.

• A contract is a PDF.
• An invoice is a PDF.
• A project plan is an Excel file.
• A customer request is an email.

But the file is often just one representation of something that exists in the business.

This is where the concept of objects becomes interesting.

Knowing when to turn something into an object can change the way you design an ECM solution fundamentally, so let’s take a look at it!

The document-centric way of thinking

Let’s start with a familiar example.

Imagine a company that manages supplier contracts.

You might have documents such as:

• Supplier_Agreement_ACME.pdf
• Supplier_Agreement_Contoso.pdf
• Supplier_Agreement_Fabrikam.pdf

You then add metadata:

• Supplier
• Contract type
• Contract number
• Start date
• End date
• Responsible person
• Contract status

This is already much better than a shared folder. The document is no longer just a file. It has context. However, something is still missing.

In this case, the supplier is treated as metadata attached to the document.

That might be perfectly fine. But what happens when the supplier becomes important in many different business processes?

The supplier has:

• contracts
• invoices
• contacts
• certificates
• purchase orders
• quality documents
• complaints
• audits
• correspondence

Suddenly, “Supplier” is doing a lot more work than simply describing a document.

It has become a business entity.

And that is usually the point where I start asking: Should Supplier become an object?

Metadata describes, Objects exist

This distinction is at the heart of the question.

Metadata answers: What is this?

An object answers: What exists in the business?

For example:

A document might have metadata saying:

Supplier = Nordic Components

That’s useful.

But if “Nordic Components” is an object, we can start saying:

Contract → relates to → Nordic Components

Invoice → relates to → Nordic Components

Certificate → relates to → Nordic Components

Complaint → relates to → Nordic Components

Now “Nordic Components”is no longer just a value in a metadata field.

It becomes a piece of the information model, offering a fundamentally different way of thinking.

Use metadata to describe an object. Use relationships to connect objects.

Not everything should become an object

This is important.

Once you discover the concept of objects, it can be very tempting to treat everything as one.

But that’s a mistake.

You don’t need an object for:

• document language
• document type
• creation date
• priority
• confidentiality level
• department
• status

These are characteristics, they describe something.

They don’t usually need an independent identity.

Creating objects for every piece of information can make your ECM model unnecessarily complicated.

So the question isn’t: Can I make this an object?

Almost anything can be modeled as an object.

The better question is: Should this be an object?

So, when should something become an object?

There isn’t a single universal rule. But I use a few questions to make the decision.

Does it exist independently from the document?

Consider a customer.

The customer exists even if there are no documents associated with them.

You can have a customer with:

• no contract yet
• no invoice yet
• no correspondence yet

The customer still exists.

Compare that with the confidentiality.

Confidentiality does not exist in isolation; it is an attribute of something else.

That’s a strong indication that:

Customer → object

Confidentiality → metadata

Is it referenced by many things?

This is probably one of the strongest indicators.

Suppose you have: Supplier = Nordic Components

attached to 200 documents.

You could store “Nordic Components” as a metadata value on every document.

But now imagine you want to know:

• Which contracts do we have with Nordic Components?
• Which invoices came from Nordic Components?
• Which complaints are associated with Nordic Components?
• Which certificates are about Nordic Components?
• Who is responsible for Nordic Components?
• When does our relationship with Nordic Components need to be reviewed?

The supplier is no longer simply describing documents.

It is becoming a central point of reference. That’s where an object starts to make sense.

Does it have its own lifecycle?

This is another important question, if we consider a contract.

A contract might have its own lifecycle:

Draft → Review → Approval → Signature → Active → Expired → Archived

The document representing the contract also has a lifecycle.

But sometimes the business entity has a lifecycle that is larger than the document itself.

For example, a project might move through: Initiation → Planning → Execution → Closure

During that lifecycle, hundreds of documents may be created.

The project isn’t one of those documents. The project is the thing that connects them.

This is a strong argument for making Project an object.

Does it have its own attributes?

An object usually has information that belongs to the object itself.

Take a customer.

You might want to store:

• Customer number
• Name
• Address
• Country
• Customer type
• Account manager
• Status

These aren’t really properties of a particular document.

They are properties of the customer.

If you keep them as metadata on every document, you introduce duplication.

And duplication creates another problem:

Which value is correct?

If Nordic Components changes its address, do you update:

• 10 documents?
• 100 documents?
• 10,000 documents?

Or do you update the customer once?

This is where object-oriented information modeling starts to provide real business value.

Do users need to navigate to it?

This question is often overlooked. Consider how users actually work.

A user may not start with: I need to find a document.

They might start with: I need to work on this customer.

Or: I need to see everything related to this project.

Or even: I need to understand this supplier.

The document is then only one part of the information they need.

If users naturally think in terms of an entity, that entity may deserve to be an object.

Instead of navigating through folders:

Customers → CustXYZ → Contracts

you can have a relationship-based information model:

CustXYZ

• Contracts
• Invoices
• Certificates
• Complaints
• Correspondence

The difference is subtle. But the user experience can be completely different.

The object should have a reason to exist

As mentioned above, there is one rule that I find particularly important:

Don’t create an object just because you can. Create one because the business needs it.

This sounds obvious. But it is surprisingly easy to create overly complex information models.

For example, imagine a project document with:

• Project
• Customer
• Country
• Department
• Manager
• Product
• Business unit
• Region
• Cost center

You could potentially turn all of these into objects.

But should you? Not necessarily.

If “Region” is simply used to classify documents, a metadata property might be enough.

If “Product” has its own lifecycle, documents, specifications, certifications, and relationships, then perhaps it deserves to be an object.

The distinction is not technical. It is about business meaning.

Objects connect information

This is where the model becomes much more powerful. An object isn’t valuable simply because it is an object. Its real value comes from what it allows you to connect, reuse and understand.

Imagine you have:

Customer

↓ has

Project

↓ governed by

Contract

↓ generates

Invoice

↓ supported by

Documents

Now the information is no longer a collection of isolated documents. It becomes a connected business context.

The question is no longer: Where is the document?

It becomes: What does this document relate to?

But what about the document itself?

This is where things get interesting!

Sometimes, the object and the document are closely related.

Take a contract, for example.

Is the contract an object? Or is the PDF the contract?

In many cases, you actually need both.

The contract object represents the business entity. The documents represent the content associated with that contract.

For example:

Contract 2026-001:

• Contract number
• Customer
• Start date
• End date
• Status
• Contract owner

Related documents:

• Proposal contract
• Signed contract
• Amendment #1
• Amendment #2
• Renewal letter

The contract now has its own identity and context, while the documents provide the actual content.

This distinction is particularly valuable when a business entity is represented by multiple documents over time.

A contract doesn’t disappear just because the initial PDF is replaced by a signed version.

Similarly, the customer doesn’t disappear just because a contract expires.

The project doesn’t disappear just because the project plan is updated.

The object represents the business entity.

Documents represent the associated content and evidence.

Once you start thinking this way, relationships become much more than a technical feature. They become a way of representing how the business actually works.

And this is where ECM becomes information management

This is, for me, one of the most interesting evolutions in ECM.

Traditional document management starts with: Where should I store this document?

Metadata-driven ECM moves to: What is this document?

Relationship-driven ECM goes one step further: What does this document relate to?

And object-oriented information management goes even further: What business entities exist, and how are they connected?

That’s a very different mental model. The document is no longer the center of the universe. The business information is.

The real question

So, when should something become an object?

Not when the technology allows it.

Not because objects are more sophisticated than metadata.

And certainly not because we want to build the most complex information model possible.

Something should become an object when it represents something the business recognizes as existing in its own right.

That’s the shift.

From: Where do I put this document?

To: What is this?

Then: What does it relate to?

And finally: What business information are we really trying to manage?

Because once you stop seeing the document as the center of the ECM world, a lot of things start to make more sense.

The document is only one piece of the information. The real value comes from understanding what it represents, what it relates to, and how it fits into the business. Want to find out more?

L’article When should something become an object? est apparu en premier sur dbi Blog.

This involved extracting information, classifying documents, suggesting properties, and identifying similar content or patterns.

To be honest, that was already quite useful.

For years, M-Files has offered capabilities such as Text Analytics, Matcher, Smart Metadata, and Smart Classifier. These intelligent services analyze document content and existing metadata to help users classify and enrich information.

However something has changed. Whether you’re skeptical or enthusiastic, one thing is certain: advances in artificial intelligence are creating new possibilities.

M-Files understood it perfectly, and its latest AI capabilities are particularly interesting.

With Aino, Metadata Agent, Metadata Agent at Scale, Search Agent, Custom Agents, Custodian Agent and the move toward MCP, M-Files is evolving from a document management platform with AI features into something much closer to an AI-enabled information platform.

So, what are all these capabilities actually doing?

And perhaps more importantly:

How are they different from the AI capabilities M-Files already had?

M-Files & AI, a long love story

AI didn’t start with ChatGPT and other Large Language Models.

M-Files has offered “Intelligence Services” for almost ten years.

For example, when a document arrives, M-Files might help determine:

• what class the document belongs to;
• which customer it relates to;
• what project it belongs to;
• what keywords are relevant;
• which existing objects might be related;
• or what other metadata should be assigned.

Technologies such as Text Analytics, Matcher, Smart Metadata and Smart Classifier belong to this generation.

They are still valuable because they reduce the effort required from workers and solve a fundamental ECM problem: Users are not very good at consistently describing the information they create.

This is especially important because M-Files relies on metadata for views, searches, relationships, workflows, security, and lifecycle management.

These features had already established M-Files as both a visionary and a disruptor of traditional enterprise content management (ECM) systems.

But the new generation goes considerably further.

The shift: from intelligence services to AI agents

The easiest way to understand the new capabilities is not to view them as a list of features.

Instead, look at them as the different roles that AI can play with enterprise information.

That is a very different proposition from simply adding a chatbot to an ECM system.

Let’s take a look at them!

Aino: AI that understands

Aino, launched in late 2023, is undoubtedly the feature that users will first notice: the integrated conversational AI experience.

It can summarize documents and answer questions about their content. Depending on the configuration, users can ask questions about a specific document, related content, or broader vault content. Aino respects M-Files permissions when generating responses and can display the source documents used.

This changes the way users interact with information.

Traditionally, to understand a 50-page contract, I might:

• Find the document.
• Open it.
• Search for keywords.
• Read several sections.
• Compare information.
• Build my own conclusion.

With Aino, the interaction becomes:

“What are the termination conditions in this contract?”

Or:

“Summarize the main obligations for the supplier.”

Or:

“What financial risks are mentioned in this document?”

The important point isn’t that AI can summarize a document. Anyone can do that now.

What’s interesting is where the AI gets its context from.

Unlike other systems that simply throw documents into a generic chatbot, Aino works with the information available in the M-Files environment. According to M-Files, Aino uses vault content and applies user permissions when generating answers.

Metadata Agent: AI that understands what a document is

Metadata has always been one of the most powerful and frustrating parts of ECM.

We know metadata is important.

However, users don’t particularly enjoy filling it in.

This is where the M-Files Metadata Agent comes in.

The M-Files Metadata Agent uses large language models to analyze document content and suggest relevant metadata. Administrators can configure which properties to suggest and provide descriptions to guide the AI toward relevant information.

Imagine uploading this:

Supplier Contract – ACME Corporation.pdf.

Instead of asking the user to manually enter:

• Class = Contract
• Customer = dbi services
• Contract Type = Supplier Agreement
• Effective Date = 01/01/2026
• and Expiry Date = 12/31/2028.

The system can analyze the document and suggest these values. The user would then validate them.

This is a subtle but important change.

The traditional approach was:

• Human reads → Human interprets → Human enters metadata.

The AI-assisted approach is:

• AI reads → AI proposes → human validates.

This doesn’t eliminate governance. It just changes where humans spend their time.

Instead of doing mechanical work like extracting information, humans can focus on exceptions and decisions.

This is also where M-Files’ older intelligence services and new AI capabilities start to overlap.

So, what’s different from Smart Metadata?

I expect this to be a question asked by M-Files administrators and consultants.

After all, M-Files already has Smart Metadata and Smart Classifier.

Why do we need another AI capability?

The answer is not simply: “Because the new one uses an LLM.”

A more interesting difference is the type of reasoning that can be applied.

Traditional intelligence services are useful when defined patterns, classifiers, rules, training data, and matching logic are available.

Generative AI offers another possibility: You can describe what you want the system to identify using natural language.

Rather than trying to encode every possible variation of a contract, for instance, you can give the AI instructions that describe the meaning of the property and the information it should look for.

This doesn’t render traditional intelligence services obsolete. It provides administrators with another tool.

In many cases, the best solution will probably be a combination of both.

Metadata Agent at Scale: AI starts paying back information debt

Now, we’ll discuss a capability that I find particularly interesting from an ECM perspective: Metadata Agent at Scale.

There is a huge difference between: “Help me classify the document I am uploading.”

and: “Help me classify the 300,000 documents we already have.”

M-Files describes the Metadata Agent at Scale as a capability that enriches large volumes of existing content in the background. It is specifically designed for legacy archives, migrations, and metadata quality initiatives and can run enrichment jobs on a recurring schedule.

This changes the problem completely.

Consider a typical ECM implementation.

You have: 500,000 documents.

And perhaps:

• 80,000 missing a customer
• 60,000 with incomplete metadata
• 30,000 using an old classification model
• thousands containing information that was never extracted
• relationships between objects that were never created

Traditionally, this becomes a data cleanup project. Data cleanup projects are rarely anyone’s favorite.

Now, imagine being able to define what good metadata looks like and letting AI progressively enrich the existing content.

This is much more than automatic indexing.

It is information remediation.

There is a concept I have written about before that fits perfectly here: Information debt. We constantly talk about technical debt.

However, organizations also accumulate enormous amounts of information debt. This includes information that is poorly classified or described, difficult to find, or disconnected from the surrounding context.

Metadata Agent at Scale provides a mechanism to start paying that debt back.

This could be one of the most important AI use cases in ECM.

It’s not about creating more information. It’s about making the information we already have more useful.

Search Agent: stop searching like a database

Search has always been one of the most underrated features of an ECM system (Oh, I also wrote something about that!).

Traditional search assumes that users know how to articulate what they are looking for.

• They enter keywords.
• They apply filters.
• Then, they inspect the results.
• They refine the search.
• Repeat.

However, humans don’t always think in keywords. They think in questions.

For example:

“I need the contract we signed with the German supplier for the equipment delivered to the Basel project around 2024.”

This is a reasonable way to describe what someone wants.

However, it’s not an effective keyword query.

Aino Search introduces natural-language search, which allows users to describe what they are looking for instead of entering isolated keywords. The Aino Search Agent can then ask follow-up questions to help refine the results. According to the current M-Files documentation, this capability is still in limited beta.

This is an important evolution.

Traditional search:

• Query → Results

AI-assisted search:

• Describe → Results → Clarify → Refine → Find.

The difference might seem small. It isn’t!

It shifts the focus of searches from database interactions to conversations.

Once again, metadata becomes extremely important.

The better M-Files understands: customers, projects, contracts, people, dates, document types, and relationships, the easier it becomes for AI to understand what the user actually means.

This brings us back to one of my favorite ECM topics: Context.

Custom Agents: AI that can actually do something

• Aino answers questions.
• The Metadata Agent suggests metadata.
• The Search Agent helps you find information.

But what happens when AI participates directly in a business process?

This is where Custom Agents become interesting

M-Files introduced Custom Agents as AI-powered workflow automation capabilities. They can be configured with natural-language instructions and operate within M-Files workflows. An agent can read a document and the related business context, make a determination, and update only the properties it is authorized to change. M-Files currently describes Custom Agents as a public beta capability.

Consider the following invoice workflow.

Traditional case:

Invoice received → Employee opens invoice → Employee reads invoice → Employee checks contract → Employee decides → Employee enters metadata → Employee routes invoice

With an AI Agent:

Read invoice → Read related contract → Read supplier information → Reason → Set appropriate metadata → Route according to result → Employee handles exceptions

That’s no longer simply document intelligence. That’s process intelligence, and this distinction is important.

A traditional automation rule might say:

• If invoice amount > CHF 10,000, send it to the manager.

An AI agent can potentially reason over more complex information:

• “Check whether the invoice corresponds to the contractual terms, identify discrepancies, explain the discrepancy and route the invoice accordingly.”

That’s a completely different type of automation.

The governance question becomes much more important

This is also where I become more cautious about AI.

If AI provides an inaccurate summary, it’s frustrating. However, if an AI agent assigns the wrong keyword, I can probably fix it.

However, if an AI agent changes metadata, routes a document, triggers a workflow, makes a recommendation, or takes an action, then we have entered a different world.

We need governance.

M-Files’ approach is interesting here. For custom agents, M-Files states that the agent is constrained regarding which properties it can modify and that values set by the agent can include reasoning and source information to support an auditable trail.

This is exactly the kind of thing enterprise AI needs.

The question should not be, “Can AI do this?”

It should be: “Under what conditions are we willing to allow AI to do this?”

These are very different questions.

Custodian Agent: AI that looks after information

The next step is perhaps even more interesting.

What if AI not only helps users and executes workflows, but also helps maintain the information environment?

This is the idea behind the Custodian Agent.

One of the main challenges of ECMs is determining if a document is still relevant months after its creation.

Should we keep it in primary storage and pay the high price associated with it?

Can we optimize performance by reducing inactive content in our vault?

Should static documents, like PDFs, take full advantage of the capabilities offered by AI agents?

These features are useful, of course, but they also come at a cost in terms of tokens per query. Optimizing that cost is also part of the overall strategy.

Note: this feature is not yet officially released.

MCP: what happens when AI doesn’t live inside M-Files?

I also appreciate this about M-Files. Even though they provide incredible solutions, they don’t fear competition.

The MCP (Model Context Protocol) server is a perfect example of this. Unlike the Aino or Metadata agents, which are integrated into M-Files, the MCP server is an interoperability mechanism. It differs from the AI modules we’ve seen previously!

Today, we are still at the beginning of what AI can do for us. Often, the capability is limited to the app we are running.

But imagine tomorrow when we can use one AI agent that works across all enterprise apps (ERP, CRM, ECM, etc.).

This agent would need access to governed enterprise information.

M-Files has stated that it is developing support for emerging interoperability standards, including the MCP, to extend the trusted enterprise context to broader AI platforms and agents.

Note: This feature is still in development and will be available soon.

The real shift is from documents to information

There is a deeper point here. For decades, ECM systems have been built around documents.

We created:

• document classes
• metadata
• workflows
• permissions
• versions
• views
• retention rules

All of this was designed to manage documents.

However, AI doesn’t care about documents as files.

AI cares about:

meaning.

It wants to understand:

• Who is involved?
• What happened?
• What is this related to?
• What obligations exist?
• What decisions were made?
• What should happen next?
• What information is missing?

This is precisely where the M-Files approach becomes interesting.

Rather than focusing solely on the physical location of a file, M-Files has built its information model around metadata, relationships, and context.

As AI becomes more prevalent in ECM, this approach becomes increasingly valuable.

This is because AI needs context.

What does this mean for ECM consultants?

An important, even vital, question: Will AI replace my job?

Obviously, the answer is no, and, as with many other professions, we’ll have to adapt. But is that really surprising if you work in IT?

For years, our role as consultants was to ask:

• What metadata should we create?
• Which workflow should we configure?
• Which properties should be mandatory?
• What classification should we use?

Those questions aren’t disappearing. But new questions are arriving:

• What information can AI safely infer?
• What decisions can AI make?
• Which decisions require human approval?
• What changes should an AI agent be allowed to make?
• How do we measure AI accuracy?
• How do we audit AI decisions?
• What happens when AI is wrong?
• How can we design information models that AI can understand?

We have a crucial role now more than ever because we are designing more than just ECM solutions.

We are increasingly designing the environment in which humans and AI agents collaborate.

I find that much more exciting.

AI is changing the role of the ECM

The interesting thing about M-Files’ latest AI capabilities isn’t a single feature, but rather the direction in which they’re headed.

We started with AI that could help identify information.

Then, it could classify information.

Next, it could answer questions about the information.

Now, AI can enrich information at scale, conduct conversational searches, participate in workflows, and perform actions.

The next step is connecting that information to AI agents outside the ECM itself.

This represents a very different vision of enterprise content management.

Discussions and concerns about AI remain intense (and rightly so). Can we really go against progress? Or should we choose to embrace it and make the most of it? – I’ve made my decision!

We have reached the point at which we can begin designing an information environment in which humans and AI agents can safely collaborate.

If that is where ECM is heading, then metadata, relationships, context, and governance are not becoming less important. They are becoming the foundation.

The future of ECM may not be about using AI to manage documents. It may be about managing information for an AI-powered organization.

L’article M-Files AI: from Intelligent Metadata to AI Agents est apparu en premier sur dbi Blog.

This is broadly true and can encourage user adoption by explaining what obscure acronyms like DMS, ECM, and IMS mean.

However, this definition is too restrictive. A good ECM can do much more and help users be more productive.

But the document itself is only one piece of the puzzle. For example a contract is related to a customer, an invoice is related to a supplier or to a purchase order.

Metadata tells you what a document is, relationships tell you what it means!

Documents rarely exist in isolation

If we think again about a customer contract.

When you open the PDF, you can read the contract.

But knowing that it is a contract isn’t enough.

You probably also want to know:

• Which customer is it for?
• Which project does it belong to?
• Who is responsible for it?
• When does it expire?
• Are there related invoices?
• Are there amendments?
• Is there a renewal?
• Are there other contracts with the same customer?

The answers aren’t necessarily contained within the document.

They exist in the relationships between the document and the rest of the business information.

This is where traditional document management often reaches its limits.

The folder doesn’t tell the whole story

Traditional document management relies heavily on folders.

For example: Customers → ACME → Contracts → 2026 → Contract.pdf

This structure provides some context.

But what happens when you want to answer a different question?

• Show me all contracts for projects managed by Guillaume.
• Show me all invoices related to this contract.

The folder structure wasn’t designed to answer these questions.

The problem isn’t the folder itself. The problem is that a folder represents only one relationship.

Business information usually has many.

One document can have many relationships

This time if we take a supplier contract, it could be related to

• Supplier
• Project
• Purchase orders
• Invoices

and this contract might also be related to:

• a responsible employee
• a department
• an external contact
• a legal review
• …

Representing all these relationships with folders quickly becomes complicated, if not impossible.

You end up either duplicating documents or creating increasingly deep folder structures, which becomes unmanageable.

Relationships provide another way of thinking.

Instead of asking: Where should I store this document?

Start thinking: Which business entities is this document related to?

That’s a much more powerful question.

Relationships reduce duplication

Imagine you have a supplier invoice for hardware required by a customer project. Where would you store this document? Do you have a strict rule?

In the supplier folder? Or in the customer folder as proof of the ordered/delivered hardware? Or would you store it directly in the project folder?

In reality, this document is often stored in several locations.

Duplication becomes particularly problematic when the information changes or when users need to know which copy is authoritative

A relationship-based approach enables business objects to exist independently.

For example, a customer object can have its own characteristics (name, address, etc.). Then, when something changes, you can simply change the information in one place. Clever, right?

Relationships make metadata more valuable

Metadata is powerful.

But metadata on its own can still leave you with isolated pieces of information.

Consider:

• Document Type = Contract
• Customer = dbi services
• Project = Project Zeta

That’s useful.

But if dbi services and Project Zeta are actual objects with their own information, the relationship becomes much more powerful.

The contract can inherit context from the customer.

The project can provide additional context.

Other documents can be connected to the same objects.

Suddenly, you’re no longer just classifying a document.

You’re building an information map.

Relationships improve search

This is where relationships become particularly valuable.

The search becomes less about finding a filename and more about navigating the relationships between business information.

This is a very different way of thinking about search.

Instead of searching for documents, you’re searching for business context.

Relationships make automation smarter

Relationships aren’t just useful for finding information.

They can also drive automation.

Imagine a contract approaching its expiration date.

The system could identify:

• the contract
• the customer
• the responsible employee
• the related project

and automatically trigger the appropriate process.

Or consider an invoice.

If the invoice is related to a purchase order and supplier, the system can use those relationships to:

• validate information
• apply metadata
• determine permissions
• trigger an approval workflow
• notify the appropriate people

The more context the system understands, the less information users need to provide manually.

Relationships can improve security

Security is another area in which relationships can be useful.

A document may need to be accessible to everyone working on a project.

Another document may only be available to people responsible for a specific customer.

Instead of manually maintaining permissions on every individual document, relationships can provide the context needed to determine who should have access.

This doesn’t mean relationships automatically solve every security problem.

But they provide something extremely valuable: context.

And context is essential when defining access to information.

AI loves relationships

This becomes even more interesting with AI.

AI can retrieve information from documents.

But finding a relevant document is only part of the problem.

Imagine asking: “What contracts do we have with this customer?”

A document-centric system might find contracts containing the customer’s name.

A relationship-aware system can understand that the documents are actually connected to the customer object.

Now consider a more complex question: “Which customers have contracts expiring in the next six months, and which projects are affected?”

This isn’t simply a document search anymore.

It’s a question about relationships between business objects.

AI may provide the natural-language interface, but the underlying information model still matters.

AI doesn’t eliminate the need for structure.

In many cases, it makes good structure even more valuable.

From Documents to Business Information

Once you understand the power of relationships, it can be tempting to connect everything to everything.

But relationships should exist for a reason.

Ask:

• Does it provide useful context?
• Does it improve search or automation?
• Who will use it?
• Who will maintain it?

If nobody has a clear answer, you’re probably creating more complexity than value.

The real shift is therefore not about creating more relationships. It’s about creating the right ones.

This is one of the areas where M-Files takes a different approach from traditional folder-based ECM. Documents can be connected to customers, suppliers, projects, contracts, employees, and other business objects, allowing users to access the same information through different business contexts.

The result is a shift from storage to context. Metadata tells us what information is. Lifecycle tells us how it changes. Search helps us find it.

Relationships tell us how everything fits together.

And when these elements work together, an ECM system becomes much more than a document repository.

Because sometimes the most valuable information isn’t inside the document.

It’s the connection between the documents.

L’article The forgotten power of relationships in ECM est apparu en premier sur dbi Blog.

Take shortcuts today, pay the price tomorrow.

Everyone knows it: developers, architects, project managers…

But there’s another kind of debt quietly accumulating inside almost every organization.

Information debt.

Unlike technical debt, it does not appear in sprint backlogs or architecture diagrams.

Instead, it hides in duplicate documents, outdated procedures, abandoned SharePoint sites, inconsistent metadata, and files that nobody dares delete.

This is why good information governance matters long before technology becomes part of the conversation.

The dangerous part?

Most organizations don’t realize they’re paying interest on it every single day.

What is Information debt?

Information debt is the accumulated cost of poorly managed information, which slows down, increases the risk of, and makes future work more expensive.

It does not result from one bad decision. It happens because of hundreds of small ones:

• “We’ll clean up later.”
• “Let’s create another copy.”
• “Just save it here for now.”
• “We’ll update the procedure next month.”

Months turn into years and the debt grows.

You’re already paying interest

Unlike financial debt, information debt doesn’t issue invoices.

Instead, it accrues over time.

Consider the following situations:

• Someone spends ten minutes searching for the latest contract.
• A team recreates a document that already exists.
• An employee follows an outdated procedure because the previous version has not been archived.
• A customer receives conflicting information from two departments.

Individually, these moments may seem insignificant.

Together, however, they can be costly.

What Information debt looks like

Information debt rarely announces itself.

Instead, it manifests as familiar, everyday frustrations.

Duplicate documents:

Nobody knows which version is correct.

Obsolete procedures:

Employees keep finding documents that should have been discarded years ago.

Missing Ownership:

Everyone assumes someone else is maintaining the information.

Inconsistent metadata:

Searches become unreliable because similar documents are classified differently.

Forgotten workspaces:

Old Teams channels, SharePoint sites, and project folders continue to accumulate information long after the project has ended.

None of these problems seem catastrophic.

Together, however, they create friction across the entire organization.

Why AI makes information debt more visible

Artificial intelligence is changing expectations.

People now expect to be able to ask questions such as:

“Show me the latest approved supplier contract.”

Or:

“Find the current on-boarding procedure.”

These questions sound simple, but the answers aren’t.

If the system contains three conflicting versions, incomplete metadata, and outdated documents, AI can’t magically create trustworthy information.

It simply exposes the existing chaos faster.

In many ways, AI isn’t creating new information problems. It’s revealing the ones that were already there.

The real cost isn’t storage

When organizations discuss information problems, storage costs often dominate the conversation.

Storage has become relatively inexpensive.

However, poor decisions have not.

The real costs are:

• time wasted searching,
• duplicated work,
• compliance risks,
• delayed decisions,
• lost organizational knowledge.

Information debt isn’t measured in gigabytes.

It’s measured in productivity.

How to reduce information debt

The good news is that information debt can be reduced.

Not by launching another massive migration project.

But by improving how information is managed every day.

Give information an owner

Every important document should have someone responsible for ensuring its accuracy.

Manage the lifecycle

Information shouldn’t live forever.

In fact, document lifecycle management is often more valuable than the document itself.

Drafts, approved versions, archives, and deletion are all important.

Design better metadata

Good metadata reduces ambiguity and improves search results.

Remove what no longer creates value

Just because information makes sense at one point in time doesn’t mean it will always be the case. Deleting obsolete information is often just as important as creating new information.

Automate repetitive governance

Retention rules, approval workflows, and automatic notifications prevent debt from accumulating.

Small improvements compound over time. Just like debt.

Prevention is easier than cleanup

One of the biggest misconceptions is that organizations can clean up anything later.

In reality, information grows faster than cleanup projects can handle.

The longer debt accumulates, the harder it is to determine what information is still valuable.

The best time to prevent information debt is before it becomes invisible.

The real debt to pay

Technical debt affects software.

Information debt affects people.

Every duplicate document is an example of information debt. A forgotten workspace, an outdated procedure, or an inconsistent metadata property also contribute to information debt.

These are all small decisions that shape tomorrow’s productivity.

Organizations that succeed with enterprise content management aren’t necessarily the ones with the most advanced technology.

They’re the ones that continuously reduce information debt before it becomes impossible to repay.

The most expensive document isn’t the one you lose. It’s the one that everyone thinks they can trust but shouldn’t.

L’article Information debt: The technical debt nobody talks about est apparu en premier sur dbi Blog.

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.

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.