DocuWare MCP Connector Update October 2026 - See Workflow Tasks, Change Index Data, Replace Files

Two weeks ago we took stock after one month and noted that the DocuWare MCP connector is used mostly for reading in everyday work. Since 12 October it can do more - in exactly the three areas asked about most often. Here is what is new, how it is secured, and what still does not happen.

1. See workflow tasks

“Which approvals are waiting for me?” was the most frequently asked question the connector could not answer. Now it can. The assistant lists the workflows that have open tasks for the signed-in user and shows for each task:

• the document concerned, with its index data,
• the values of the task row - state, received date, workflow variables,
• every decision on offer, together with the form fields it asks for.

The assistant sees the task list with the user’s own token - so it is their list and nobody else’s. The cabinet policy sits on top: a workflow whose cabinet is not enabled for the connector is withheld entirely. The name of a workflow alone can reveal what a company is processing. Anyone asking for it by name gets the same answer as for a typo. And the index columns of a task row are held to the same visibility list as a search result, because a task list is just a second road to the same index data.

What the assistant does not do: it marks nothing as read and takes no decision. Confirming a decision from the chat is the next step - with its own grant, separate from visibility. We wanted to see first how the plain overview proves itself in daily use.

2. Change index data

The first tool in the connector that writes to DocuWare. The assistant can write values into a document’s index fields - correct a wrong vendor number, add a missing cost centre, fill the empty fields it found with the data-quality query from the last post.

Three things have to come together for that:

1. The organisation allows index updates in principle.
2. The cabinet allows them too - the setting can be overridden per cabinet.
3. The field is individually marked editable - a third tick next to searchable and returned. The “all fields at once” shortcut we introduced in September for onboarding deliberately never sets this tick. Write access is granted field by field, never wholesale.

The document is resolved through the same path as a read - including the organisation’s mandatory filters. A document the policy would not show cannot be changed by ID either. Values are typed server-side: a date has to be a date, “1234,56” and “1234.56” are the same number, and an unsuitable input comes back as a readable refusal rather than an error. DocuWare’s field rights apply on top.

The audit trail records the new and the previous value for every change. Anyone wanting to know what the AI changed on invoice 4711 on Tuesday finds both sides in one line.

3. Replace or append files

The second writing tool: the assistant can replace the file behind a document or append another file to it. Typical cases are the corrected invoice that supersedes a faulty first scan, or the signed version added to a contract.

• Replace overwrites the first file and keeps the document ID, index data and all further files.
• Append adds another file without changing anything.
• The file name the assistant gives is kept - DocuWare’s viewer, download and full-text index rely on it.

The rules that already applied to reading apply here too: the organisation’s file type rules are applied to the upload, so a block on executable files keeps them out of the cabinet and not just out of search results. A size ceiling limits the upload. In cabinets with version management, replace is not a check-in: DocuWare refuses it until the document is checked out, and the assistant passes that refusal on as DocuWare words it.

The name of the replaced file is recorded. The uploaded bytes themselves are not stored - only their size.

Three switches, all off

None of the three functions is active for existing customers. The administrator enables workflow tasks per organisation, the two writing functions per organisation and additionally per cabinet, and index fields individually on top. Anyone who does nothing has the same read-only connector the day after the update as the day before.

That is intentional and follows the principle the connector is built on: nothing a model can say widens what it reaches. A person grants the permissions in the portal, every change to those permissions is logged, and every use lands in the tamper-evident audit chain.

Also since September

Two points that are less visible but deserve a mention:

• Encryption of stored responses. For audit purposes the connector keeps the responses it delivered - OCR text and, where downloads are allowed, whole files. These are now stored encrypted in the database, just like the access tokens next to them. A database dump or an old backup is no longer a document leak on its own.
• Hardened sign-in. Following a security review, we bound the sign-in flow to the browser it was started in, narrowed the allowed redirect addresses to exact matches, and protected the consent page against automatic submission by third-party sites. The portal’s two unauthenticated forms now have rate limiting as well.

Our recommendation

The order we suggest to customers is the same as in the last post - just one step longer:

1. Start read-only. Search, full text, look-ups.
2. Enable workflow visibility. Low risk, immediately useful, and the assistant can summarise the morning’s task list without changing anything.
3. Release index fields selectively. Not “all”, but the three or four fields that actually get added or corrected in daily work.
4. File changes only where a process needs them. The contract cabinet for the signed version, say.

Already using the connector and want to enable one of these functions? Get in touch - we will go through the settings together. New to the connector? Then we will gladly show you on a test cabinet how DocuWare feels in a chat.