A message arrives in a Czech company's data box. A connector downloads it, and a shared mailbox receives a notification. Several people assume someone else is handling it. The message is technically present in the business, but nobody can show which case owns it, which evidence was retained or who is expected to respond.
A data-box integration should turn an incoming message into accountable work while preserving its original evidence. For businesses in Czechia, buying a connector is therefore also a decision about case ownership, document handling and operational recovery. A successful login is only the beginning of the acceptance test.
The 2026 portal move is a reason to review, not panic
The official service explains that data boxes moved to datovka.gov.cz, with the final client-portal redirect in August 2026. The same notice distinguishes web services from the browser portal and states that application interfaces will be available on the old and new domains concurrently at least until the end of 2027.
Do not turn the browser change into an unsupported claim that every existing connector has already stopped working. Instead, use it to inventory the actual dependencies: application endpoints, certificates, monitoring checks, notification filters, saved support links and supplier documentation. A connector may continue functioning while its operating instructions or email rules become misleading.
The official developer information points to the operating rules for the production interface and distinguishes documentation for newer public-test versions. Ask a prospective supplier to identify which specification it implements and how it follows changes. A library name without a maintained interface contract is not enough.
Model the message before building the dashboard
Keep the external message identity, relevant box identity, original content and associated delivery information linked together. Separately model the internal case, assigned owner and business status. A single case may need several messages, while one message may require review before anyone knows which case it belongs to.
Store original attachments without silently replacing them with an extracted summary. A preview, text extraction or classification is a derived aid. It should retain a link to the original and make any processing failure visible. A scanned document with little extractable text is not an empty message.
The connector must preserve the distinction between external service events and internal staff actions. “Downloaded by connector,” “assigned to finance” and “reviewed by a person” answer different questions. A dashboard should not compress them into one ambiguous read flag.
Agree what the automated operations actually do
The official application-interface page directs implementers to the ISDS operating rules and technical documentation. Use that material to review the exact operations your connector will call, the permissions they need and their effects in the external service.
This is particularly important when a team proposes to “just poll everything.” Before enabling automation, have the responsible business owner and specialist confirm any delivery or acknowledgement consequences of the chosen operations. The workflow must not invent legal deadlines from an internal download timestamp or assume that a technical event proves someone acted on the document.
Write the agreed interpretation into the operating model. Identify who approves changes to polling, access permissions or message handling. Engineers should implement a reviewed process rather than quietly decide what counts as receipt, response or closure for the business.
Assign a person and preserve a fallback queue
Start with transparent routing rules. A message from a known counterparty may suggest an account or case, but the proposed assignment should remain reviewable. Keep unrecognised senders, missing references and conflicting matches in a visible queue with an accountable team.
Define what happens when the intended owner is absent. A reassignment should preserve the history and notify the next responsible person through your approved internal channel. A shared mailbox can remain a notification mechanism, but it should not be the only record of responsibility.
If you add document classification or AI assistance later, keep the model's suggestion separate from the routing decision. Show why a match was proposed and allow correction. Sensitive attachments should not be sent to an external model merely because the tool offers a convenient extraction feature. Decide the permitted processing environment as part of the project scope.
Build a recovery path before switching off manual checks
A connector can fail between discovering a message and creating its internal case. It can also create a case successfully and lose the final acknowledgement of that work. Retrying the entire operation without a durable correlation can produce duplicate tasks and conflicting ownership.
Require an explicit processing history: discovered, content retained, linked to a case, routing completed and any remaining work. Design retries around unfinished steps. After an outage, reconcile the external message list with locally recorded identities and investigate gaps without deleting evidence of previous attempts.
Monitoring should tell the team when the last successful exchange occurred, which boxes were covered and whether new messages are waiting for assignment. A process that is running but has lost access to one box must not appear entirely healthy. The fallback procedure should identify who checks the service directly and how those manual actions are later reconciled with the connector.
Test separation between boxes, accounts and documents
An organisation may operate multiple legal entities or departments. Map each service identity to the correct internal security boundary. A person who manages one entity's cases should not gain access to another entity's attachments through a search result, export or shared file link.
Include access revocation in acceptance. When a staff member changes role, removing them from the dashboard should also remove access to stored documents and previews. Support access should be scoped and recorded. Secrets and certificates need defined ownership, secure storage and a rehearsed replacement procedure.
Decide the retention and archive requirements with the responsible records-management and legal specialists. The development scope should implement those decisions, including restore and export tests. Keeping attachments indefinitely in an undocumented folder is not a complete archive strategy.
Buy one complete intake workflow first
Choose one authorised data box and one recurring document category. Connect it to a single case-management destination. A useful pilot ends when an incoming message is preserved, correctly assigned, reviewed and linked to the documented follow-up decision.
Ask the supplier to demonstrate an unknown sender, two messages for the same case, a repeated import, an unreadable attachment and a restart after partial processing. Include a user who is allowed to see the case title but not the attachment, if that distinction exists in your business. Review the outcome with the people who will operate the queue.
Compare an existing document-management module with a custom connector on this same workflow. Individual development is justified when your case rules, multi-system handoffs or evidence requirements remain unresolved. It should not be purchased solely to replace a working screen with your company colours.
Our guide to Czech business-identity integration covers the separate issue of matching company records. The software maintenance agreement guide helps define who maintains an external-service connector after launch.
TuniCyberLabs develops custom software and operational integrations. To scope a Czech data-box workflow, describe your current connector, destination system and an anonymised message that was difficult to assign. The first deliverable can be a verified intake and ownership process rather than another disconnected inbox.