Cases
Changed: The Pending tab has been removed from the case list
Cases with the status Pending were placeholders created automatically from ERP imports, not matters anyone had written in about. They are no longer shown as their own tab, are no longer counted in the All tab, and are no longer included in Analytics reports by default. The practical effect is that the count on the All tab and the totals in your reports now agree with each other.
Nothing has been deleted. Existing pending cases still open normally, still show their status, and can still be moved to a live status. What is no longer possible is moving a case into Pending.
New: A warning before you resolve a case that still has email suggestions
If a case still has an email suggestion waiting for your review, setting the case to Resolved or Rejected used to bury that suggestion without a word. You now get a confirmation dialog with two options: resolve anyway, or jump straight to the first suggestion still waiting. The warning appears wherever you can change a case status — the case screen, the case list, and the email overview.
New: Re-ingest an email that failed processing
When an email cannot be processed, CK marks it with an error and sets it aside so it is not retried endlessly. Until now, giving such an email another chance meant asking an administrator to remove that marker in Outlook by hand.
Emails in this state now show a Re-ingest button. Pressing it clears the marker so the email is collected again on the next check. This replays the same processing as before, so an email that failed for a permanent reason — a corrupted attachment, for example — will fail again; re-ingest is for cases where the cause was temporary.
Improved: You can see when a case is being updated in the background
Linking an email or an ERP ticket to a case can start a background update in which Gustav revises the case description and proposes follow-up actions. Previously the case simply looked idle while this happened. The case now shows a processing indicator for as long as the update is running.
Gustav AI Assistant
Changed: Future and former occupants appear in property searches again
In the June release we narrowed Gustav's occupant searches to current tenants only, with options to include former and future ones. In practice this hid people you legitimately need to find — someone reporting a defect before they have moved in, or a tenant who moved out last week and is writing about their deposit.
Future and former occupants are now included by default and labelled with their status and dates, for example (future, moving in 01.09.2026) or (former, moved out 30.06.2026). A unit with no current tenant shows the incoming tenant instead, marked as vacant with the start date of the coming tenancy. You can still narrow a search to current tenants when you want to.
ERP Integration
New: Keep a case and its ERP ticket status in step
Your team can now have CK synchronise the status of a case with the status of its linked D+ ticket. Two modes are available: changes made in D+ can be reflected onto the case, or the two can be kept in step in both directions, so resolving a case in CK also closes the ticket in D+.
Which D+ status CK writes for each case status is configurable per team, so "resolved" can map to whichever code your organisation actually uses. This is off by default — contact us if you would like it enabled for your team.
Bug Fixes
Work orders could not be created for some buildings: On roughly one building in five, every trade (Gewerk) you could pick was rejected with a message saying it did not match the building's type — leaving no way to create a work order at all. CK was applying its own copy of a rule that only D+ can answer correctly. It now asks D+ directly whether a trade is permitted for that building, and where a building genuinely has no trades available it says so instead of asking you to pick a different one.
Gustav could pick the wrong building in a property split for billing: Where a property is divided into billing units that share the same name, number and address, Gustav had nothing to distinguish them by and could attach the ticket to the wrong one — which then left the D+ ticket without a proper assignee. The billing units are now clearly marked, and a ticket that lands without an assignee is reassigned to the team's fallback.
Emails were documented into D+ more than once: Retrying, re-importing or re-linking an email created a fresh document container each time, so the same email could appear several times on one ticket. CK now checks what is already documented on the ticket before uploading.
A document rejected by D+ was reported as filed: When D+ refused a document, CK recorded it as successfully uploaded, and Gustav reported the same. Rejections are now reported as failures, and when a container is incomplete the specific documents D+ refused are named.
Common-area issues attached every resident in the building: A complaint about a stairwell or lift could pull the building's entire resident list onto the case and onto the D+ ticket. Only people actually involved are attached now; a common-area matter is linked to the building alone.
Cases that had been archived could still be suggested: The matcher could propose linking an email to an archived case, and an archived case could be imported into. Archived cases are now excluded, and if you do want to use one you are asked to unarchive it first.
An archived case made its email impossible to review: If a suggested case was archived, the email showed as needing review but displayed nothing to review or dismiss. Archived cases now appear in that list, marked as archived.
Accepting an ERP ticket suggestion could duplicate documents or fail outright: Accepting the same suggestion twice created duplicate documents in D+, and accepting a suggestion for a ticket that had since been linked elsewhere failed with an unexplained error.
An owner could be described as a tenant: When CK assessed the legal context of an incoming email, it inferred whether the writer owns or rents from indirect clues, and could label an owner as a tenant. It now reads the unit's actual occupancy rights, including the person's role and the period it applies to. The "New Communication" report email also names each occupant's role and its validity period.
Emails could be lost when an attachment could not be read: A single unreadable attachment — an empty or corrupted file — could stop an entire email from being processed, with no case created and no visible trace. Such attachments are now marked as unreadable and the rest of the email is processed normally. The attachment list shows that the file could not be read, rather than leaving the summary blank.
Cases containing certain emails could not be opened: An email with no subject or no message body, such as a scan sent without any text, caused the case to fail to load entirely.
Declining an email import could fail silently: If the message could not be marked in Outlook, CK still reported the decline as successful — and because the marker is what stops the email being collected again, it could come back and create a duplicate case. Failures are now reported, and nothing is saved unless the mailbox update succeeded.
A reprocessed email showed the wrong notice: An email that had been reprocessed and not linked showed the generic "not linked to case" message instead of the notice explaining it had been reprocessed. The German wording of that notice was also corrected.
ERP ticket numbers were invisible in dark mode: Gustav writes ticket numbers in a highlighted style that rendered white on white in dark mode, hiding exactly the part of the answer you needed.
Emails deleted or moved while being processed: If a message was moved or deleted in Outlook while CK was working on it, processing stopped — and could stop the rest of that batch too. These are now skipped cleanly.
Related Articles
Email Ingestion — How CK collects and processes incoming email
Inbound Email Monitoring — Keeping an eye on what has arrived and what failed
Case Status Guide — What each case status means and when to use it
ERP Tickets — How cases and D+ tickets relate to one another
Work Orders — Creating and dispatching work orders
Searching with Gustav — Finding properties, occupants and cases