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.

To administer an Oracle Database Appliance (ODA), you probably use the odacli commandline tool.

The principle of this tool is to run jobs in background. Fire-and-forget… or Fire-and-poll

odacli update-repository -f "/tmp/odacli-dcs-19.30.0.0.0-260210-GI-19.30.0.0.zip"

This command returns a jobId (e.g. f1338963-87a2-4cb9-8a3e-06e104270203) and the job is executed in background. To see if this job is (sucessfully) completed, you have to poll for the above jobId and wait for Status: Success.

odacli describe-job -i f1338963-87a2-4cb9-8a3e-06e104270203
watch -n 2 odacli describe-job -i f1338963-87a2-4cb9-8a3e-06e104270203

Automation with Ansible

For automation, e.g. with Ansible, that is not optimal. We have to implement a polling mechanism for the odacli commands.

For example. we will add new software to the ODA-repository. (version=19.30, software_zip=/tmp/odacli-dcs-19.30.0.0.0-260210-GI-19.30.0.0.zip)

First of all, we run odacli to create the job to add the software to the repository and extract the jobId from the output.

  - name: import software in repository
    ansible.builtin.shell: |
      /opt/oracle/dcs/bin/odacli describe-dbsystem-image -j \
        | jq -e '.[].dbSystemImageComponents[]|select(.componentName=="DB")|.availableVersions[]|select(startswith("{{version2}}")) ' \
        |grep  {{version2}} >&2 && echo 'ALREADY_INSTALLED' && exit 0
      /opt/oracle/dcs/bin/odacli update-repository -f "{{software_zip}}"
    register: repo
    changed_when: "'ALREADY_INSTALLED' not in repo.stdout"

  - name: set job-id
    set_fact:
      jobid: "{{ (repo.stdout | from_json).jobId }}
    when: "'ALREADY_INSTALLED' not in repo.stdout"

Hint: the 1st command is to check if this software is already imported

Now, we can poll the job until it is completed. Ansible is optimized to work with json. So we will enforce odacli to return the output in json format (-j):

/opt/oracle/dcs/bin/odacli describe-job -i f1338963-87a2-4cb9-8a3e-06e104270203 -j
{
  "jobId" : "f1338963-87a2-4cb9-8a3e-06e104270203",
  "status" : "Created",
  "message" : "/tmp/odacli-dcs-19.30.0.0.0-260210-GI-19.30.0.0.zip",
  "reports" : [ ],
  "createTimestamp" : "February 24, 2026 13:58:30 PM CET",
  "resourceList" : [ ],
  "description" : "Repository Update",
  "updatedTime" : "February 24, 2026 13:58:30 PM CET",
  "jobType" : null,
  "cpsMetadata" : null
}

For polling, we can use the ansible loop control, see the Ansible documentatioon

  - name: check until job completed
    ansible.builtin.shell: /opt/oracle/dcs/bin/odacli describe-job -j -i {{jobid}}
    register: check_status
    until: "(check_status.stdout|from_json).status == 'Success'"
    retries: 10
    delay: 8
    changed_when: false
    when: "'ALREADY_INSTALLED' not in repo.stdout"

That means, Ansible will run the command every 8 seconds until status Success is returned (Success) or after 10 attemts (Failed)

TASK [check until job completed] ************************************************************************
FAILED - RETRYING: check until job completed (10 retries left).
FAILED - RETRYING: check until job completed (9 retries left).
FAILED - RETRYING: check until job completed (8 retries left).
FAILED - RETRYING: check until job completed (7 retries left).
FAILED - RETRYING: check until job completed (6 retries left).
FAILED - RETRYING: check until job completed (5 retries left).
FAILED - RETRYING: check until job completed (4 retries left).
ok: [server01]

Re-usability with roles

For re-usablility, I recommend to move the job-polling to a role, so that it can be used for all asynchronous jobs

# roles/odacli_job/tasks/main.yml
  - name: set job-id
    set_fact:
      jobid: "{{ (job_stdout | from_json).jobId |default('') }}"
    when: job_stdout|default('') != ''
  - debug: var=jobid

  - name: check until repo job completed
    ansible.builtin.shell: /opt/oracle/dcs/bin/odacli describe-job -j -i {{jobid}}
    register: check_status
    failed_when: false
    until: "(check_status.stdout|from_json).status == 'Success' or (check_status.stdout|from_json).status == 'Failure'"
    retries: "{{retries}}"
    delay:   "{{delay}}"
    changed_when: false

The role can be used as follows:

  - name: include role to poll job
    include_role:
      role: odacli_job
    when: "'ALREADY_INSTALLED' not in repo.stdout"
    vars:
      job_stdout: repo.stdout 
      retries: 50
      delay: 3

The job to poll can be specified by variable “jobid”, or you can provide the json-output of launching the job via “job_stdout”, then the role extracts the jobid

After the import of the software (you will see it in /opt/oracle/oak/pkgrepos/orapkgs/clones/), you can now deploy an ORACLE_HOME with it. For that, we can use the same role to poll this asynchronous job:

  - name: create database home
    ansible.builtin.shell: |
      /opt/oracle/dcs/bin/odacli create-dbhome -j -v {{version}}
    register: home

  - name: include role to poll job
    include_role:
      role: odacli_job
    vars:
      job_stdout: home.stdout
      retries: 80
      delay: 10

Errorhandling

What is not done in the role is the error-handling. It is up to you to define an adequate error-handling. You will get the result of the asynchronous job in the variable check_status.stdout which is of json format.

(check_status.stdout|from_json).status

If the status is

• “Success”, it is OK
• “Failure”, it is not OK
• Any other value (e.g. “Created”), you got a timeout (>retries*timeout sec.), then the result it is unknown (maybe the job completes at a later time, sucessful or not).

L’article Administer Oracle Database Appliance (ODA) with odacli and Ansible 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.

The grouping is loose but useful: donut and bar answer questions like “how does my population break down into categories?”, while table can answer pretty much any question… Together, they cover the rest of the use cases, where you want either a visual distribution or the actual details of what is in the vault.

1. donut – distribution across categories

The donut chart shows how a population splits across the distinct values of a property. Labels and values appear on the slices, while the legend is placed next to the donut when the pane is wide enough (otherwise below it). The engine computes a layout that estimates the legend width from the longest label, then centers the donut in the remaining space, with the ring filling the main part of the available area.

{
  "id": "",
  "title": "Contracts by Agreement Type",
  "type": "donut",
  "gridColumnSpan": 6,
  "gridRowSpan": 2,
  "query": {
    "objectType": "Document",
    "class": "Contract or Agreement",
    "aggregation": {
      "type": "groupByProperty",
      "propertyName": "Agreement type",
      "resolveValueListLabels": "Yes",
      "includeEmptyResults": "No"
    }
  }
}

1.1. Aggregations the donut accepts

Two aggregation types work with donut:

• groupByProperty: group by the values of that specific property, often the natural choice for category distributions.
• groupByDateBucket: group by dates based on a certain bucket size. The date buckets will be ordered chronologically, where usually donut slices would be ordered by decreasing counts of objects.

1.2. resolveValueListLabels

For properties backed by an M-Files value list, resolveValueListLabels: “Yes” (the default) shows the human display names on the slices’ tooltip and in the legend. On the other hand, “No” shows the internal IDs. The default is correct for almost every dashboard, “No” might be useful for technical investigations.

1.3. seriesProperty: the multi-mini-pie grid

This is the most distinctive feature of the donut widget. When you set a seriesProperty, the widget switches to a multi-mini-pie grid: one donut per distinct value of the series property, all sharing a single legend. Each small donut shows the distribution of the primary propertyName within that series slice.

{
  "id": "",
  "title": "Contracts by Agreement Type x Year",
  "type": "donut",
  "gridColumnSpan": 12,
  "gridRowSpan": 4,
  "query": {
    "objectType": "Document",
    "class": "Contract or Agreement",
    "aggregation": {
      "type": "groupByDateBucket",
      "propertyName": "Effective through",
      "bucketSize": "year",
      "seriesProperty": "Agreement type",
      "includeEmptyResults": "No"
    }
  }
}

This produces, for example, one donut per Agreement type, with each donut showing the distribution by year for their Effective through property. As you can see below, it takes more space, since multiple donuts will be displayed. Depending on what you want to see, you could also simply display multiple donut widgets with the associated filters, instead of a single widget with a multi-series. That is, if you know how many series you need (and therefore how many widgets you need with their dedicated filters) and if it’s not a dynamic number.

A few practical notes:

• The donuts are all resize-aware: when the right pane is resized, the engine recomputes the size of all donuts. The number of donuts per row is fixed and defined at first rendering, based on the size that the widget has available (based on its configuration) and the number of series that were found.
• A series where every visible slice is zero is shown as a grey ring, so the user does not have to wonder whether the chart loaded. This is the same for single-series donuts too.
• Like every seriesProperty, this should be a low-cardinality property. A grid of six donuts is most probably fine, but a grid of fifty might be difficult to display properly, unless if you have a very big screen!

1.4. The tooltip touch

As all other tooltips, the one on the Donut will show the numbers that match the query with a thousand separator (e.g. 1’520 or 1,520 (depending on your regional settings) rather than 1520). But in addition, it will also include the percentage that this slice represents. It is a small detail, but it usually helps and avoids the need to calculate that yourself.

2. bar – vertical and horizontal bar charts

The bar widget covers a large surface and deserves its own deep dive. It supports both vertical and horizontal orientations, both single-series and multi-series modes, and per-bar threshold coloring in single-series too. Most of the configuration lives in two display keys: barLayout and thresholds.

2.1. A first vertical bar

Taking the same example as for the previous blog post on the Invoices/Revenue:

{
  "id": "",
  "title": "Monthly revenue",
  "type": "bar",
  "gridColumnSpan": 12,
  "gridRowSpan": 2,
  "query": {
    "objectType": "Document",
    "class": "Invoice",
    "filters": [
      { "property": "Invoice date", "operator": "between",
        "value": ["@startOfYear", "@endOfYear"], "valueType": "dateToken" }
    ],
    "aggregation": {
      "type": "groupByDateBucket",
      "propertyName": "Invoice date",
      "bucketSize": "month",
      "reducer": "sum",
      "reducerProperty": "Amount",
      "includeEmptyResults": "Yes"
    }
  }
}

The X-axis labels rotate at -15 degrees always (not conditionally), so they never overlap the bars or the chart area below them. This was a small thing needed to avoid strange display when the space for the widget is very small or when there are long labels to be displayed. As you can see below, it is very similar to the line/area widgets in its essence:

2.2. display.thresholds in single-series mode

In single-series mode, display.thresholds colors each bar individually based on its own value. You can either use text values representing colors or the HTML color code:

"display": {
  "thresholds": [
    { "value": 0, "color": "red" },
    { "value": 40000, "color": "orange" },
    { "value": 100000, "color": "yellow" },
    { "value": 120000, "color": "green" }
  ]
}

So bars with value 0 to 40’000 will be displayed in red (when value is 0, there is no bar, so only the tooltip will show a red “0”). Bars with 40’000 to 100’000 will become orange, etc.:

As with line / area, thresholds are ignored in multi-series mode (each series uses the automatic palette so the legend color stays consistent).

2.3. display.barLayout

Bar charts have two orthogonal choices: orientation (vertical vs horizontal) and multi-series mode (stacked vs grouped). The display.barLayout key combines them into a single value:

For single-series bars (i.e. when no seriesProperty is used), only orientation matters. The stacked / grouped distinction has no visible effect, since there is a single value anyway). So a single-series chart with vertical-stacked and one with vertical-grouped render identically.

Horizontal charts place categories on the Y axis (top to bottom in the same order they would appear left to right on a vertical chart) and values on the X axis. This is useful when category labels are long enough that the -15 degree rotation still does not fit or when you want more space to display the values rather than the different categories.

See the screenshot on the following section for the distinction between the vertical/horizontal and stacked/grouped.

2.4. seriesProperty: stacked or grouped

"aggregation": {
  "type": "groupByDateBucket",
  "propertyName": "Invoice date",
  "bucketSize": "month",
  "reducer": "sum",
  "reducerProperty": "Amount",
  "seriesProperty": "Country",
  "includeEmptyResults": "Yes"
}

With seriesProperty: “Country” and display.barLayout: “vertical-stacked”, you get a stacked bar chart where each month bar is split into each values found for the “Country” property (here: Switzerland & USA). With vertical-grouped, you get two side-by-side bars per month (one for each “Country” value). The chart tells the same story with two (or rather four) different displays. Note: for the below screenshot, I reduced the filtering to only the first 6 months of the year, to be able to do a side-by-side comparison of how these charts look. The goal isn’t to see the full year here, only to show you how these different display options render:

2.5. Aggregations the bar widget accepts

The bar widget accepts groupByProperty and groupByDateBucket, same as the donut and trend widgets, and the date-valued reducer rule from posts 4a and 4b applies here too: a reducer that returns a date string cannot be plotted on a numeric axis, so the widget will show a placeholder.

3. table – sortable, paginated, multipurpose

The table widget is the last, and most flexible of the catalog. It accepts all four aggregation types (summary, groupByProperty, groupByDateBucket, list), and it is the only widget that supports list. This makes it the natural fallback when other widget types cannot display a specific combination, and the obvious choice when the user wants to see the raw objects (without the drill-through).

3.1. A list-aggregation table

This is the “give me the details” case. The aggregation is list and with the displayProperties parameter, it is possible to control which columns are shown alongside the object name.

{
  "id": "",
  "title": "All Projects",
  "type": "table",
  "gridColumnSpan": 12,
  "gridRowSpan": 4,
  "query": {
    "objectType": "Project",
    "aggregation": {
      "type": "list",
      "displayProperties": ["Class", "In progress", "Customer", "Project Manager"]
    }
  }
}

The result is a sortable table with one row per Project, and five columns (object name, Class, In progress, Customer and Project Manager). Above, there was no Class enforced, so all classes from M-Files will apply. That’s why in the screenshot, you can see both Internal Project and Customer Project objects, which are the two classes in question. Only the Customer Project has a Customer property, but it isn’t a problem, it is simply displayed as “-“ for the Internal Project objects. Clicking a row name navigates the user directly to the object in M-Files, no drill-through modal is opening, since the row already represents one object.

3.2. Sorting and pagination

Every column header is clickable to sort ascending or descending. In above screenshot, the second column is sorted in descending order. The sort applies across all fetched rows, not just the currently visible page, which (I believe) is the behavior users would expect when sorting.

Note: This is NOT how M-Files behaves in its own search! In M-Files, by default, when you search for something and you get more than 1 page of results, if you sort a column, only what is displayed on the screen gets sorted… Which is a problem from my point of view, since it sorts only partial data and you might see things you don’t expect. Therefore, M-Files is doing a page-by-page sorting and not a global sorting. On the other hand, the Business Dashboard will sort correctly and apply the sorting on ALL data, and not just the current page.

Pagination kicks in at 15 rows per page, by default (configurable), and the pagination bar at the bottom shows the current range and the total fetched.

3.3. Display details

Numeric columns honor display.decimals and both numeric and dates honors regional settings as well. In above example, you can see the 4th row with a Customer column that shows a value “Tennessee Land Surveyors (Nashville) || Lance Smith Engineering (Surveying)”. This is actually a concatenation of two customers. This project, in the M-Files Sample Vault, is assigned to two different customers, and therefore, it is shown in the table (or any drill-through modal) as a concatenation of Customer1 || Customer2. No data is silently cut or hidden, everything that is actually part of the metadata model is shown as it should. That’s how multi-select lookup values are displayed.

3.4. seriesProperty: the cross-tab pivot

As other widgets, the table supports multi-series (via the same seriesProperty) when it is using a groupByProperty or groupByDateBucket aggregation. In this case, it becomes a cross-tab pivot. This means that rows will remain the groups for the primary group property, while additional columns will be added for each group of the series property. Therefore, both rows (primary group) and columns (series group) are fully dynamic. Here are two table widgets definitions, the first one without multi-series and the second one with it:

"aggregation": {
  "type": "groupByProperty",
  "propertyName": "Project manager",
  "displayProperties": ["Class", "In progress", "Customer", "Project Manager"]
}
...
...
"aggregation": {
  "type": "groupByProperty",
  "propertyName": "Project manager",
  "seriesProperty": "Class",
  "displayProperties": ["Class", "In progress", "Customer", "Project Manager"]
}

With the above, you get the count of Projects that each Project Manager handles for the first one. While the second widget, adds another dimension that is the “Class” of the objects, i.e. whether the Projects that the managers handle is an Internal Project or a Customer Project. The result of these two widgets is the following:

In this multi-series case, all series columns include a link on their count. Therefore, each number is clickable, and it will display the drill-through that matches this series AND this primary group. E.g. which Customer Projects are handled by Tommy Hart.

3.5. Drill-through on tables

Table drill-through behavior depends on the aggregation type, which is documented in detail in Post 2 (the end-user post) but worth recapping here:

• For summary, groupByProperty, groupByDateBucket: clicking a row (or a specific column from a row in case of multi-series as mentioned above) opens the drill-through modal showing the underlying objects.
• For list: clicking a row name navigates directly to the object. No modal, because the row already represents one object.

3.6. The “safe fallback” role

I mentioned earlier that table accepts every aggregation type. This makes it the safe choice for cases where other widgets refuse. The most common one is date-valued reducers: if the answer to your question is a date per group (e.g. “latest invoice date per customer”), the chart widgets cannot plot that, but the table widget will happily render it with one row per customer and a date value for each row.

Whenever the validation flags a date-valued reducer warning on a chart widget, switching the widget type to kpiNumber or gauge might be the right answer if you need only one date. Otherwise, switching to table is the only remaining and valid option.

4. The compatibility cheat sheet

To close the widget posts, here is the full compatibility matrix the validator enforces, as of now. You can use that as a quick reference when authoring:

When the validation reports an incompatible combination, the message usually includes the right alternative (typically “use kpiNumber, gauge or table” for date-valued reducers, or “use table for list aggregations”).

5. Closing thoughts

That closes the widget catalog. The seven widget types cover the full range of business questions I typically see: scalar answers (kpiNumber, gauge), trends (line, area), distributions (donut, bar), and raw enumerations or whatever else (table).

Two observations from real customer dashboards:

• Most useful dashboards mix widget types. A row of KPIs at the top, a couple of distribution charts in the middle, a list table at the bottom. The mental model the user builds reading top to bottom is “summary, distribution, details”.
• Most pitfalls live at the boundary between aggregation and widget type. If a widget shows a placeholder, the explanation is almost always “this aggregation produces a shape this widget cannot render”. The validation spells it out before save, so trust it.

Post 5 shifts from “what widgets exist” to “how to write the query that feeds them”: object types, classes, filter operators, and date tokens. After that, Post 6 covers aggregations and reducers in detail. With those two, 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 – Distribution and tabular widgets: donut, bar, table est apparu en premier sur dbi Blog.

• Tables where all columns can be used to identify uniqueness (bad_column='N')
• Tables where not all columns can be used (bad_column='Y')

To show what happens when primary keys are missing in GoldenGate replication, let’s see a few examples. In all the examples, I will extract data from APP_SOURCE schema and replicate it into an APP_TARGET schema.

The parameters of the replication do not really matter here, but to be precise, here is the extract parameter file:

EXTRACT EXT1
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL pdb1/aa
SOURCECATALOG PDB1
DDL INCLUDE MAPPED
TABLE APP_SOURCE.*;

And here is the replicat parameter file:

REPLICAT REP2
USERIDALIAS target_pdb DOMAIN OracleGoldenGate
DDL INCLUDE MAPPED
MAP PDB1.APP_SOURCE.*, TARGET PDB2.APP_TARGET.*;

First test : simple table with primary key

First, let’s try the most common example, with a table APP_SOURCE.TEST_PK created with a primary key. You can skip this part if you know how GoldenGate works, but I just wanted to include this for comparison.

CREATE TABLE APP_SOURCE.TEST_PK
(
    id   NUMBER PRIMARY KEY,
    data VARCHAR2(100)
);

Let’s insert a few rows in this table and look at the content of the table in both the source and the target.

INSERT INTO APP_SOURCE.TEST_PK VALUES (1,'A');
INSERT INTO APP_SOURCE.TEST_PK VALUES (2,'B');
COMMIT;

-- Verify source/target
SELECT * FROM APP_SOURCE.TEST_PK ORDER BY id;
SELECT * FROM APP_TARGET.TEST_PK ORDER BY id;

You will see the same content in both tables.

SQL> SELECT * FROM APP_SOURCE.TEST_PK ORDER BY id;

        ID DATA
---------- --------------------
         1 A
         2 B

Now, if you update the row with id=1, it will be updated in both tables as well.

UPDATE APP_SOURCE.TEST_PK SET data='A_UPDATED' WHERE id=1;
COMMIT;

-- Verify
SELECT * FROM APP_SOURCE.TEST_PK ORDER BY id;
SELECT * FROM APP_TARGET.TEST_PK ORDER BY id;

Checking the tables will give you the updated data.

SQL> SELECT * FROM APP_TARGET.TEST_PK ORDER BY id;

        ID DATA
---------- --------------------
         1 A_UPDATED
         2 B

Until then, nothing really interesting, but let’s look at the report file of the extract on the source. You will see the following information:

2026-06-06 07:00:52  INFO    OGG-06509  Using the following key columns for source table PDB1.APP_SOURCE.TEST_PK: ID.

Because the table has a primary key, GoldenGate knows that it should only use this column to identify unique rows.

Second test : table with no primary key and no LOB columns

In this second test, I will create a table without a primary key, but using only types that GoldenGate can use to identify uniqueness.

CREATE TABLE APP_SOURCE.TEST_NOPK
(
    id   NUMBER,
    data VARCHAR2(100)
);

We can already query the DBA_GOLDENGATE_NOT_UNIQUE view to find this new table listed with bad_column='N' :

SELECT *
FROM dba_goldengate_not_unique
WHERE owner='APP_SOURCE'
ORDER BY owner, table_name;

OWNER                          TABLE_NAME                     BAD_COLUMN
------------------------------ ------------------------------ ----------
APP_SOURCE                     TEST_NOPK                      N

Let’s do the same steps as before, inserting data and updating the content.

INSERT INTO APP_SOURCE.TEST_NOPK VALUES (1,'A');
INSERT INTO APP_SOURCE.TEST_NOPK VALUES (2,'B');
COMMIT;

SELECT * FROM APP_SOURCE.TEST_NOPK ORDER BY id;
SELECT * FROM APP_TARGET.TEST_NOPK ORDER BY id;

UPDATE APP_SOURCE.TEST_NOPK SET data='A_UPDATED' WHERE id=1;
COMMIT;

The content of the table is the same on source and target, as expected.

SQL> SELECT * FROM APP_TARGET.TEST_NOPK ORDER BY id;

        ID DATA
---------- --------------------
         1 A_UPDATED
         2 B

And looking at the extract report file, we can see that all viable columns were used. In that case, it meant taking ID and DATA.

2026-06-06 07:08:13  INFO    OGG-06508  Wildcard MAP (TABLE) resolved (entry PDB1.APP_SOURCE.*): TABLE "PDB1"."APP_SOURCE"."TEST_NOPK".

2026-06-06 07:08:13  WARNING OGG-06439  No unique key is defined for table TEST_NOPK. All viable columns will be used to represent the key, but may not guarantee uniqueness. KEYCOLS may be used to define the key. If using KEYCOLS, make sure that you create an INDEX in the target database for those column(s) as well.

2026-06-06 07:08:13  INFO    OGG-06509  Using the following key columns for source table PDB1.APP_SOURCE.TEST_NOPK: ID, DATA.

As mentioned in the other blog about primary keys in GoldenGate, this will work, but you will of course have performance issues when replicating data.

Third test : Table with no PK and a CLOB column

Now, let me show you the bad use case, where you don’t have a primary key and the table contains a non-viable column for uniqueness identification. In this example, I will use a CLOB column, but it could be another unbounded data type.

CREATE TABLE APP_SOURCE.TEST_CLOB
(
    id   NUMBER,
    code VARCHAR2(10),
    txt  CLOB
);

If we check the DBA_GOLDENGATE_NOT_UNIQUE view, we see the new table listed with bad_column='Y'.

SELECT *
FROM dba_goldengate_not_unique
WHERE owner='APP_SOURCE'
ORDER BY owner, table_name;

OWNER                          TABLE_NAME                     BAD_COLUMN
------------------------------ ------------------------------ ----------
APP_SOURCE                     TEST_CLOB                      Y
APP_SOURCE                     TEST_NOPK                      N

Let’s insert some data. But this time, I will add two more rows that are unique, but for which only the TXT content differs.

INSERT INTO app_source.test_clob VALUES (1,'A',TO_CLOB('LOB_1'));
INSERT INTO app_source.test_clob VALUES (2,'B',TO_CLOB('LOB_2'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_1'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_2'));
COMMIT;

The data was correctly inserted, and the content is the same on the source and target.

SQL> SELECT id,code,DBMS_LOB.SUBSTR(txt,40,1) txt FROM app_target.test_clob ORDER BY id;

        ID CODE       TXT
---------- ---------- ----------------------------------------
         1 A	      LOB_1
         2 B	      LOB_2
       100 DUP	      LOB_1
       100 DUP	      LOB_2

In the report file, we do not see any difference between this example and the one before. GoldenGate mentions using two columns for uniqueness identification : ID and CODE. GoldenGate never mentions that a third column existed and was not used. The warning displayed is the same as before.

2026-06-06 07:10:13  INFO    OGG-06508  Wildcard MAP (TABLE) resolved (entry PDB1.APP_SOURCE.*): TABLE "PDB1"."APP_SOURCE"."TEST_CLOB".

2026-06-06 07:10:13  WARNING OGG-06439  No unique key is defined for table TEST_CLOB. All viable columns will be used to represent the key, but may not guarantee uniqueness. KEYCOLS may be used to define the key. If using KEYCOLS, make sure that you create an INDEX in the target database for those column(s) as well.

2026-06-06 07:10:13  INFO    OGG-06509  Using the following key columns for source table PDB1.APP_SOURCE.TEST_CLOB: ID, CODE.

And now, the main problem I wanted to discuss regarding LOB replication with GoldenGate. If you try to delete one row by specifying all three columns, it will not always work.

DELETE FROM app_source.test_clob
WHERE id = 100
AND code = 'DUP'
AND DBMS_LOB.COMPARE(txt,TO_CLOB('LOB_1')) = 0;

Sometimes, the line with LOB_1 will be deleted:

        ID CODE       TXT
---------- ---------- ----------------------------------------
         1 A	      LOB_1
         2 B	      LOB_2
       100 DUP	      LOB_2

But sometimes, the line with LOB_2 will be deleted:

        ID CODE       TXT
---------- ---------- ----------------------------------------
         1 A	      LOB_1
         2 B	      LOB_2
       100 DUP	      LOB_1

More precisely, it will just delete the first line that was inserted. You then have two cases. If you insert LOB_1 first, it will be deleted correctly:

DROP TABLE app_source.test_clob PURGE;

CREATE TABLE app_source.test_clob (id NUMBER, code VARCHAR2(10), txt CLOB);

INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_1'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_2'));
COMMIT;

DELETE FROM app_source.test_clob
WHERE id = 100
AND code = 'DUP'
AND DBMS_LOB.COMPARE(txt,TO_CLOB('LOB_1')) = 0;
COMMIT;

SQL> SELECT id,code,DBMS_LOB.SUBSTR(txt,40,1) txt
FROM app_target.test_clob
WHERE code='DUP';

        ID CODE       TXT
---------- ---------- ----------------------------------------
       100 DUP	      LOB_2

And if you insert LOB_2 first, the incorrect line will be deleted:

DROP TABLE app_source.test_clob PURGE;

CREATE TABLE app_source.test_clob (id NUMBER, code VARCHAR2(10), txt CLOB);

INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_2'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_1'));
COMMIT;

DELETE FROM app_source.test_clob
WHERE id = 100
AND code = 'DUP'
AND DBMS_LOB.COMPARE(txt,TO_CLOB('LOB_1')) = 0;
COMMIT;

SQL> SELECT id,code,DBMS_LOB.SUBSTR(txt,40,1) txt
FROM app_target.test_clob
WHERE code='DUP';

        ID CODE       TXT
---------- ---------- ----------------------------------------
       100 DUP	      LOB_1

You now know why you should always pay attention to tables in the DBA_GOLDENGATE_NOT_UNIQUE view with bad_column='Y'. If you have such tables, there are several scenarios that I presented in the last blog on the topic. But ignoring them is not one of them. This way, you will avoid issues regarding LOB replication with GoldenGate.

L’article LOB Replication With GoldenGate and Importance of Primary Keys est apparu en premier sur dbi Blog.

1. Why these two are in the same post

The wire format and the rendering pipeline for line and area are nearly identical. They produce the same JSON on the server, they use the same client code path, they accept the same aggregation types, the same reducers, the same display options. The only meaningful difference is visual: area fills the region under the line with a translucent color, while line leaves it transparent.

In other words: choose area when you want to emphasize cumulative volume or magnitude, choose line when you want to emphasize the trajectory. Both communicate the same thing, it’s more about what you want to focus on.

2. A first example: monthly revenue trend

Here is the canonical example: total invoice amount per month for the ongoing year, displayed as a line chart.

{
  "id": "",
  "title": "Monthly revenue",
  "type": "line",
  "gridColumnSpan": 12,
  "gridRowSpan": 2,
  "display": { "smooth": "Yes", "decimals": 0 },
  "query": {
    "objectType": "Document",
    "class": "Invoice",
    "filters": [
      { "property": "Invoice date", "operator": "between",
        "value": ["@startOfYear", "@endOfYear"], "valueType": "dateToken" }
    ],
    "aggregation": {
      "type": "groupByDateBucket",
      "propertyName": "Invoice date",
      "bucketSize": "month",
      "reducer": "sum",
      "reducerProperty": "Amount",
      "includeEmptyResults": "Yes"
    }
  }
}

A few things to note in this JSON:

• The filter restricts the data to the current calendar year using two date tokens. The full date-token vocabulary is covered in the future Post 5.
• The aggregation is groupByDateBucket on the same date property, bucketed by month. Each bucket is reduced with sum of the Amount property. In other words, this means that all invoices with a date within this calendar year will be grouped by month and the value coming from the Amount property will all be summed within each month to arrive to a Total per month.
• includeEmptyResults: “Yes” ensures that months with no invoices appear as zero values, so the trend line is continuous from January to December rather than skipping empty months (e.g. you were closed for vacations or weren’t able to sell anything for some other reasons).

Switching the widget type from line to area in this exact JSON gives the area-chart variant, nothing else changes:

3. The aggregation types these widgets accept

line and area are valid with two aggregation types:

• groupByDateBucket: the natural fit for time series. It groups a date / timestamp property into a certain bucket: day, week, month, quarter, or year.
• groupByProperty: groups by the distinct values of any property. It supports date/time properties, but it’s uncommon, as each day would be a data-point. It also support any other type of properties, to display them as categorical trends (e.g. “Monthly revenue per region” rendered as a line for some reason). Depending on requirements, a bar display might be more adapted.

The visual designer will only allow you to select one of these two aggregations. But if you try to set a summary or list aggregation in the JSON editor directly, then an error will be thrown, as it isn’t possible.

4. display.smooth

The single most common display option for these widgets is smooth:

"display": { "smooth": "Yes" }

When set to “Yes”, the line/area charts draws a Bézier-smoothed curve between data points (c.f. example above). When “No” (or omitted), the connecting line is made of straight segments. Smoothing makes monthly or quarterly trends look more visually pleasant. It can also slightly hide outliers, so use it where the trend story is more important than the exact per-bucket value.

5. display.decimals

For numeric reducers (sum, avg, min, max, median), this controls how many decimal places are shown in tooltips (default 0).

"display": { "smooth": "Yes", "decimals": 2 }

In the monthly-revenue example above, if amounts are stored as floats (which is probably the case), you may want decimals: 2 so the tooltip would show 116’520.43 rather than 116’520.

6. display.thresholds in single-series mode

In single-series mode (no seriesProperty), the thresholds array colors each data point marker based on its own value. The connecting line (and the area below) itself stays brand blue. The configuration is the same as on kpiNumber and gauge. You can either use text values representing colors or the HTML color code:

"display": {
  "smooth": "Yes",
  "thresholds": [
    { "value": 0, "color": "red" },
    { "value": 40000, "color": "orange" },
    { "value": 100000, "color": "yellow" },
    { "value": 120000, "color": "green" }
  ]
}

This is useful to highlight specific buckets that crossed a business threshold without changing the overall trend visualization. As mentioned in Post 4a, the default falls back to brand blue for values below the lowest threshold.

7. seriesProperty: multiple lines on the same chart

This is where these widgets become genuinely powerful. When you set a seriesProperty on the aggregation, the engine produces one line per distinct value of that additional property, with an automatic legend and color palette.

For instance, splitting the monthly revenue line into separate lines per country:

"aggregation": {
  "type": "groupByDateBucket",
  "propertyName": "Invoice date",
  "bucketSize": "month",
  "reducer": "sum",
  "reducerProperty": "Amount",
  "seriesProperty": "Country",
  "includeEmptyResults": "Yes"
}

A few notes that matter in practice:

• display.smooth applies to every series. There is no per-series smoothing.
• display.thresholds are silently ignored in multi-series mode. If they were applied per-point, they would override the series palette colors and break the relationship between line color and legend label. So the engine drops them in multi-series and keeps the legend honest.
• includeEmptyResults in multi-series mode fills gaps across both dimensions (every series gets a zero in any time bucket where it has no data). This avoids broken lines.

7.1. Use low-cardinality series only

The seriesProperty is best used with low-cardinality properties: lookup values, booleans, short text ranges. A monthly revenue chart with 5-6 customers is readable, but the same chart with two hundred customers becomes a colored mess where no individual line is distinguishable from the others. If there are too many series, it loses its usefulness. The validation wouldn’t block it though, since it is technically a valid compatibility. Try it, and see what it looks like!

8. includeEmptyResults: gap filling

I mentioned this earlier already, and as you could see above, there are actually months with “0” values/amounts.

With includeEmptyResults: “Yes” present, the graph will fill the gaps between the earliest and the latest data points found with zero values. In above example, we can see in March that there was 0 revenue in total. And similarly, in October, there was 0 revenue for the USA. There is no discontinuity in the lines, all months are present, even if there is “0” as a result.

With includeEmptyResults: “No”, the chart will only display the buckets that have at least one matching object (across the series). So, if no invoice was issued in March, the X axis jumps from February to April directly. For above case, it would still display October, since there is a revenue in Switzerland, therefore the USA line will display a “0” value still, the line cannot be “cut”. Visually, that compresses the time scale and hides the meaningful “we had no revenue in March” signal.

There are valid use cases for both situations, so just select the one that makes sense depending on what you want to see.

Note: Adding includeEmptyResults: “Yes” can also add a (none) bucket for objects whose property used by the groupByProperty has no value. For example, if you group by a boolean state Yes/No, and some objects do not have a value on that boolean, they would end up in this (none) group. For groupByDateBucket, they usually don’t appear since you usually filter on a date in a certain range (like a month, or a year). Therefore if there is no date, usually it is just outside the range, but it technically also behaves in the same way if you fetch all results.

9. The “no date-valued reducer” rule

Same rule as on chart widgets in general: line and area cannot render a reducer that returns a date string. If you write something like:

"aggregation": {
  "type": "groupByProperty",
  "propertyName": "Customer",
  "reducer": "max",
  "reducerProperty": "Invoice date"
}

Then, with a line widget, the display would contain a placeholder and the query validation would show a warning. The reason was discussed in the previous post: ISO dates cannot be plotted on a numeric axis at the moment, so it wouldn’t make sense as a display.

The workaround is the same: use kpiNumber or a gauge in date mode if you only want to display one value, or a table for one or more values.

10. Drill-through on trend widgets

When drillThroughEnabled is “Yes”, clicking a data point opens the drill-through modal with the objects in that bucket. In multi-series mode, the click respects the series the point belongs to: only objects matching both the time bucket and the series value are shown. This makes it easy to answer questions like “show me the May invoices from Switzerland” with a single click on the right point of the line.

11. Wrap-up

line and area are the natural choice for time-series questions. They are fundamentally one widget with two visual modes, sharing the same aggregation contract and the same display vocabulary. The interesting part is what you can do with seriesProperty: turning a single trend into a multi-actor comparison without writing any extra logic.

Post 4c picks up the remaining three widgets: donut, bar, and table. The grouping rationale will be that they all answer distribution questions (how a population breaks down by category) or tabular questions (give me the raw rows), as opposed to the time-trend questions that line and area handle.

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 – Trend widgets: line and area est apparu en premier sur dbi Blog.

Before explaining what this view contains and how to interpret it, you should remember that GoldenGate replicates data by replaying changes that occurred on the source database. One of the most important problems GoldenGate must solve is to identify the exact row that must be updated or deleted on the target database. This means that GoldenGate needs a way to uniquely identify every row in a table.

The simplest solution is a primary key, but GoldenGate row identification can also be done through a non-null unique index. When neither exists, GoldenGate must fall back to less efficient mechanisms. This means using all available columns to identify a row.

The DBA_GOLDENGATE_NOT_UNIQUE view contains tables that have no primary key and no non-null unique index. It is there to help you identify potential issues in your database schema and prepare in the best possible way a migration with GoldenGate or any replication work.

Here is an example of the content of the view:

OWNER			       TABLE_NAME		      BAD_COLUMN
------------------------------ ------------------------------ ----------
APP_PDB1		       TEST_NOPK		      N
APP_PDB1		       TEST_CLOB		      Y

The view is very simple, yet very often misunderstood. The owner and table_name column names are self-explanatory, but let’s talk about bad_column. This column has two possible values: Y and N.

First case – bad_column = 'N'

N is what you will most often see in this view. You should treat these as warnings. If you intend to replicate a table from this list, you can choose to ignore the warning if you don’t care about replication performance.

Tables in this list will be replicated using all columns as a substitute key. GoldenGate can usually handle these tables without any functional issue. However, UPDATE and DELETE operations become more expensive because every column must be used to identify the target row.

From my experience, you should still always discuss with the application owner or someone who knows the underlying database schema to try to avoid performance issues. A list of solutions is given at the end of the blog.

Second case – bad_column = 'Y'

If there is one point to remember from this blog, it’s this: you should never replicate data from tables with bad_column='Y' without thorough investigation.

Tables listed here contain one or more columns that GoldenGate cannot safely use as part of a substitute key, such as LONG or CLOB.

Since GoldenGate cannot build a complete substitute key from all columns, row identification becomes problematic. Depending on the table structure and replication configuration, GoldenGate may be unable to correctly locate rows for UPDATE or DELETE operations.

In practice, a table with bad_column='Y' should be considered a candidate for schema remediation before replication (see the list of options below).

Will there be an error if GoldenGate cannot identify uniqueness ?

This is a very common misconception when talking about these primary key issues. GoldenGate does not verify that the columns used for row identification are truly unique. If duplicate rows exist, a replicat may update or delete an unintended row. In many cases no explicit GoldenGate error will be generated because, from GoldenGate’s perspective, a matching row was found. It could silently delete the wrong row, and you will never hear a word about it. In the logs, you won’t see the difference.

What can be done to solve these issues ?

Essentially, there are four possible approaches:

• If you have the ability to create a primary key or a non-null unique index on the source database, go for it before the initial load of your target database. This is the safest approach because uniqueness is enforced by the database itself.
• If you cannot alter the source schema but are 100% sure that a subset of columns that already exists in the table can uniquely identify every row, you can use the KEYCOLS keyword in your parameter files.
• Sometimes, the application design prevents duplicates from being generated. Again, you need to be sure about this. But sometimes, it means that you could rely on the application design.
• When bad_column is N, you could decide to not do anything. For tables with a lot of activity, it could slow down your replication. During a migration, it could even completely block it in production. This should only be done in last resort.

A common misconception is that every table listed in DBA_GOLDENGATE_NOT_UNIQUE is unsupported by GoldenGate. This is not the case. At the other end of the spectrum, I’ve heard countless of times that these warnings can be ignored. Do that, and you will have nightmares solving issues once you hit production. The view merely highlights tables for which GoldenGate cannot rely on a primary key or a non-null unique index for row identification. The real concern is the bad_column flag: N is a performance warning, while Y deserves immediate investigation before any replication project.

L’article GoldenGate Row Identification: Misconceptions and Solutions est apparu en premier sur dbi Blog.

Monitoring a PostgreSQL environment involves much more than simply checking whether the database is running. In a modern high availability architecture, multiple components work together to keep the service available and stable.

In this article, we will explain how to monitor a PostgreSQL cluster environment with Zabbix:

• PostgreSQL
• Patroni
• HAProxy
• ETCD
• Keepalived

The goal of this blog is to provide a simple and clear overview that can be understood by both beginners and experienced administrators.

PostgreSQL High Availability Architecture

A typical PostgreSQL high availability environment often contains several components:

In a PostgreSQL HA environment, monitoring only the database is not enough because every component directly impacts cluster stability and application availability. Moreover, a failures in components like HAProxy, ETCD, or Keepalived can directly impact application availability and cluster stability. Comprehensive monitoring ensures the entire ecosystem remains healthy and operational.

Monitoring PostgreSQL with Zabbix

Zabbix already provides an official PostgreSQL template.

This template allows administrators to monitor:

• Database availability
• Connections
• Transactions
• Cache hit ratio
• Replication status
• Locks
• Deadlocks
• Database size
• Query statistics
• WAL activity
• Performance metrics

Therefore, using the official template is usually the fastest and easiest way to start monitoring PostgreSQL.

ETCD

Zabbix already provides an official template for ETCD monitoring.

The template uses HTTP Agent items to collect metrics directly from the /metrics endpoint exposed by ETCD.

In addition, the template works without external scripts and uses Prometheus-style metrics collection.

The official template already includes many useful triggers and metrics for monitoring ETCD health, performance, and cluster activity.

HAProxy

HAProxy plays a critical role in a PostgreSQL high availability environment, ensuring that client connections are automatically routed to the correct PostgreSQL node and maintaining application connectivity during failovers.

Zabbix already provides an official HAProxy monitoring template that can be used as a base for monitoring and customization: HAProxy by HTTP

The number of active servers in HAProxy is also monitored by the template. However, the template does not create a trigger by default for this metric. This means that a backend could lose one or more active servers without generating any alert in Zabbix. For this reason, it is highly recommended to create custom triggers on this item to immediately detect backend availability issues and avoid unnoticed service degradation.

To implement this properly, a new macro should be created in the template to define the minimum expected number of active servers. Then, a custom trigger must be added on the item prototype available in the Low-Level Discovery (LLD) section of the template. Consequently, Zabbix can automatically monitor and alert on all discovered HAProxy backends.

Patroni

Zabbix does not directly include Patroni monitoring in the standard PostgreSQL templates.

One approach is to use the Zabbix Systemd template, which allows monitoring of services running on the server. In this case, it is simply necessary to filter on the patroni service name to verify that the service is active.

Another approach is to create a custom item in a template using a Zabbix agent item with the following key:

net.tcp.service["{$HAPROXY.STATS.SCHEME}","{$HAPROXY.STATS.HOST}","{$HAPROXY.STATS.PORT.PATRONI}"]

This item performs a direct HTTP TCP connection test on port 5000, which is commonly used by the Patroni API. This configuration allows Zabbix to verify that the Patroni service responds correctly and remains reachable.

Additionally, combining both monitoring methods significantly improves monitoring reliability.

Monitoring Keepalived

Keepalived monitoring is not included by default in the standard Zabbix templates.
To properly monitor the VIP management layer, administrators should create custom items whether the Virtual IP (VIP) is correctly present on one of the cluster nodes.

A common approach is to create three different items:

• Two items using the net.tcp.service key to test TCP connectivity for:
  • the READ-ONLY access
  • the READ-WRITE access
• One additional item using a system.run command to directly verify the VIP status on the server.

Together, these checks help ensure that:

• the VIP is correctly assigned
• the PostgreSQL services are reachable
• the failover mechanism is working properly

Finally, administrators should create the appropriate triggers for these items in order to immediately detect VIP failover or connectivity issues.

Conclusion

In conclusion, monitoring PostgreSQL alone is not enough in a high availability environment.

A complete monitoring strategy must include:

• PostgreSQL
• Patroni
• HAProxy
• ETCD
• Keepalived

Using Zabbix with both official and custom templates provides a centralized and efficient monitoring solution.

The PostgreSQL template available in Zabbix already offers excellent database monitoring capabilities.

Additional templates for ETCD and HAProxy help extend monitoring to the full HA architecture and improve visibility across the entire platform.

As a result, this approach helps administrators detect failures earlier, improve troubleshooting, and ensure better service availability.

If you need you can try other blogs regarding Zabbix or postgreSQL here: dbi Blog

L’article Zabbix – Monitoring full cluster Patroni/PostgreSQL est apparu en premier sur dbi Blog.

# odacli describe-job -i 2ff3fd5d-f611-4ae6-aae0-63df7c08ec71
 
Job details
----------------------------------------------------------------
                     ID:  2ff3fd5d-f611-4ae6-aae0-63df7c08ec71
            Description:  DB Home Patching to 19.31.0.0.0: Home ID is 1c101fd3-2ca8-55f6-9415-22ec5abc53da
                 Status:  Failure (To view Error Correlation report, run "odacli describe-job -i 2ff3fd5d-f611-4ae6-aae0-63df7c08ec71 --ecr" command)
                Created:  June 09, 2026 15:07:23 CEST
                Message:  DCS-10001:Internal error encountered: Unable to autoextend tablespace TEMP.

The issue is that Oracle tries to “set autoextend on” on the temporary files in 19.31., but runs a syntactically wrong command. E.g. in the alert.log I could see

2026-06-09T15:54:14.898088+02:00
alter database tempfile '/u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4kz32_.tmp /u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4l3wf_.tmp' autoextend on next 100m maxsize 20g
ORA-1516 signalled during:  alter database tempfile '/u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4kz32_.tmp /u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4l3wf_.tmp' autoextend on next 100m maxsize 20g ...

I.e. Oracle just listed all tempfiles separated by blank in one string. This is of course wrong and produces the error.

The workaround was to 

 – create a temporary tablespace temp2

 – make temp2 the default temporary tablespace

 – drop temporary tablespace temp

 – create the temporary tablespace temp with just 1 tempfile

 – make temp the default temporary tablespace

 – drop temporary tablespace temp2

Then run the “odacli update-dbhome” again and it will be successful. Afterwards add your temporary files to tablespace temp again. 

Please consider that it is not obvious in the produced errors of odacli in what DB the error happened (odacli update-dbhome patches all DBs running in the specified ORACLE_HOME). To find out what DB is affected it’s a good idea to scan the alert-logs for the error:

$ find /u01/app/odaorabase/oracle/diag/rdbms/*/*/trace -name "alert*.log" -exec grep -il "ORA-1516" {}\;

To proactively avoid the issue when patching to 19.31. on the ODA, I’d recommend to check your databases in advance if they have more than 1 tempfile in the temporary tablespace and implement the workaround mentioned above.

select count(*) from dba_temp_files where tablespace_name='TEMP';

We opened a SR with Oracle to get the issue fixed for the next release.

Update 18.06.2026:

If you do use a Standby DB (Data Guard) and use the workaround mentioned above, then please consider that you have to add the tempfiles at the standby site as well after recreating TEMP. See here, here and here.

L’article Temporary tablespace and ODA 19.31. est apparu en premier sur dbi Blog.

The benefit is real; otherwise, I would have moved on to something more meaningful. However, this promise isn’t so straightforward.

Most ECM ROI models are overly optimistic and lack objectivity.
It’s not always intentional, though. But they are systematically so. They persistently misrepresent the facts. Often, they are politically motivated. After all, this is business.

As a vendor-free ECM consultant, I will try to take an objective look at it.

The myth of measurable value

ECM vendors and internal champions love spreadsheets.
They’re full of neat formulas like:

• Save 5 minutes per document
• Process 20,000 documents per year
• Average employee cost: 75 CHF/hour

Result: 125000 CHF annual saving.

Looks solid, right?

But it’s not!

The problem

This model assumes that time savings are perfectly converted into productive output, that organizational friction magically disappears, and that users actually change their behavior.

In reality, things are more nuanced. Saved time becomes micro-idle time rather than reinvested capacity. Users continue to work around the system, and the complexity simply shifts elsewhere instead of disappearing.

If your ECM project “saves time,” ask yourself: where exactly does that time go?

If you cannot demonstrate a real reduction in costs or an increased throughput, then your ROI is theoretical.

Fake precision

ROI models often disguise assumptions as facts.

Typical inputs:

• “Average handling time before ECM”: estimated
• “Handling time after ECM”: projected
• “Error rate reduction”: assumed
• “Adoption rate”: overestimated

These are not actual measurements, but rather assumptions (sometimes bordering on wishful thinking) that are expressed as numbers.

When you multiply uncertain assumptions together, you don’t get accuracy, you get amplified uncertainty.

Yet the final number is presented with:

• Two decimal places
• A confident tone
• A fancy PowerPoint slide

This creates the illusion of rigor.
However, it’s still just guesswork in a better format.

The political nature of ROI

That’s where things get complicated.

The return on investment for ECM projects often doesn’t reflect reality.

The main goal is to convince decision-makers.

Who needs ROI?

• Project sponsors → need funding
• Vendors → need deals
• Consultants → need positive vibes (Yep, I don’t want to work with customers who don’t recognize the value I bring.)
• Managers → need justification

So what? the ROI model becomes a political artifact:

• Inflated enough to pass governance
• Flexible enough to survive scrutiny
• Vague enough to avoid accountability

No one says:

“We don’t really know the value, but we think it’s worth doing.”

Instead, they say:

“This project will deliver €2.4M in savings over 3 years.”

Everyone knows it’s lax. But (very) few people are willing to question it.

Misleading indicators (that seem convincing)

Let’s look at the usual suspects.

Time saved

Most overused metric in ECM.

• Highly variable
• Rarely measurable at scale
• Almost never translated into realized financial gain

The truth is that saving time and saving money are not the same thing.

User satisfaction

It often increases temporarily, mainly due to the initial gains associated with novelty. Then, it declines as complexity sets in.

It is difficult to establish a link to business results.

Satisfied users alone do not justify platforms that cost millions!

Documents Processed Faster

It sounds powerful, but is it really challenging? Does faster generation actually generate more revenue? Is there a bottleneck at this stage?

Just because you do things faster doesn’t mean you’re creating value!

The real economic impact

The question to ask is: Which economic variable is actually changing?

Real ROI should come from:

• Avoid hiring and even reduce headcount.
• Increased transaction volume
• Shorter revenue cycles
• Lower regulatory penalties (measured, not hypothetical)
• Reduced external costs (printing, storage, outsourcing)

If your ECM project doesn’t impact at least one of these directly, your ROI is likely cosmetic.

Why the “lie” persists

If the flaws are so obvious, why does this narrative persist?

Because it delivers, at least in the ways that matter internally. It secures budget approval, aligns stakeholders around a common narrative, and provides a simple, reassuring story.

To be fair, many ECM projects do create value, just not in a way that can be easily captured in a spreadsheet.
Thus, the industry quietly sustains a shared illusion. It’s a cycle where belief matters more than proof and ROI becomes a tool for getting things done rather than a measure of value.

What to do instead?

Don’t get me wrong, ECM is one of the most important business applications.

The problem lies in how the project is presented, which seems dishonest to me.

As soon as human beings are involved, we can no longer rely solely on mathematical formulas. Consequently, ROI calculations are theoretical and idealized.

Nevertheless, the benefits are very real. Rather than claiming users will save five minutes per document, it’s better to state that the approval process has sped up by 20 or 30 percent and that the follow-up system is now automatic and systematic rather than dependent on an employee’s availability for that task.

Just because not everything can be monetized doesn’t mean we aren’t delivering operational value. ECM goals are to improve and simplify daily work or add strategic features.

Instead of hiding your assumptions, list them explicitly and present various possible scenarios based on confidence levels.

To avoid surprises after implementation, we must ask the tough questions.

• What will happen if the adoption rate isn’t as high as expected?
• Will this project reduce costs, or will they simply be shifted elsewhere?
• Who is responsible for delivering this value?

Ultimately, an ECM project is never just a financial equation. At dbi services, we refuse to reduce a project’s value to an artificial or approximate ROI. We focus on the real values that ECM delivers on a daily basis: human, operational, and strategic. These values are realized long before the attractive but often misleading numbers. Our goal is not to promise theoretical savings, but to tangibly transform the way teams work, collaborate, and make decisions.

L’article The ROI mirage in ECM projects est apparu en premier sur dbi Blog.