EDMS demonstration without marketing fog: scenarios for live testing
On 20 May 2026, the Cabinet of Ministers approved an experimental project for handling documents containing information designated for official use through electronic document management systems. The project involves testing the full lifecycle of a document, electronic trust services, and secure exchange between systems.
This brings a practical question to the fore: how to verify that an EDMS executes the required scenarios in reality, rather than just in a vendor's presentation. Below is a demonstration scenario using the customer's own documents, routes, and integrations.
What to prepare for an EDMS demonstration
A high-quality demo starts not with a menu overview, but with a brief technical specification from the customer. The working group selects one typical document — for example, an internal memo, a contract, or a response to an inquiry — and describes its path from creation to completion of execution and transfer to storage. The data must be anonymised: the demonstration environment must not receive real personal data, official secrets, or active signing keys.
Roles should be defined before the meeting. The registry office is responsible for metadata, registration, and deadline control; the process owner for the route and exceptions; the IT team for integrations, logs, and deployment; and the security specialist for access, authentication, signatures, and backups. The vendor receives the scenario in advance, but not a pre-recorded execution: the actual settings and the result of each step must be visible during the live demo.
Resolution No. 642 concerns an experimental project for documents containing information designated for official use, so it should not be turned into a universal technical specification for every organisation. At the same time, the set of tests it defines provides a useful benchmark for evaluating an EDMS in the public sector and environments with heightened security requirements.
- An anonymised document with a real set of metadata and attachments.
- An approval workflow with roles, deadlines, delegation, and at least one exception.
- A list of fields that the EDMS must exchange with another system.
- The expected result: a signed document, an action log, notifications, and a package for storage.
- Evaluation criteria that are identical for all compared systems.
- An agreed method for recording evidence: screen recording, logs, or exporting the result.
One document: testing the full lifecycle
Ask to create a document from a blank template, fill in the card, add a file, register it, and launch the route. Next, another user should receive the task, add comments, return the document for revision, re-approve, and sign it. Complete the scenario by sending or delivering it to the recipient, recording receipt, closing the control task, and generating data for archival storage or export.
The most valuable insights come from error situations rather than standard paths. Change the assignee during the route, miss a deadline, try to register an incomplete document, or resend the same integration request. The system must display a clear status, preserve the previous version, and retain sufficient data in the log to reconstruct the sequence of decisions.
After each stage, record more than just what the user saw. Verify the event time, document identifier, author of the action, previous and new values, the reason for the change, and the notification method. If the vendor can only implement part of the scenario after custom configuration, this is not an automatic rejection of the system, but such work must have an estimate of time, cost, and impact on future updates.
- Are all versions of the document and the links between them preserved?
- What happens to tasks during delegation or changes in the departmental structure?
- How does the system behave when the signing or integration service is unavailable?
- What data is included in the audit log and who can view it?
- In what format are the document, card, signatures, links, and action history exported?
- Can the same scenario be repeated after a system update and the results compared?
Routes and integrations: what the administrator changes
To test flexibility, ask the customer's administrator to add an approval stage, a parallel branch, a condition based on document type, and a temporary substitute. Observe whether this is done within the configuration or requires changes to the program code. Separately, clarify how the new version of the route will affect documents already in progress, and whether the previous configuration can be safely restored.
Integration should be demonstrated using one simple exchange: retrieving a counterparty or employee from an external directory, creating a document, and returning its status. Verify the authentication method, API description, field dictionary, handling of duplicate requests, error queue, exchange log, and contract versioning. The mere presence of an API does not prove that an integration is ready for production use.
Ask to categorise capabilities into standard, configurable, and those requiring development. This provides a more realistic picture of the total cost of ownership than a general promise of a "flexible platform" and allows vendors to be compared on equal terms.
Metadata, signatures, and security: what to show live
For organisational and administrative documents, verify the generation of metadata and templates according to DSTU 4163:2020, and for institutions subject to Resolution No. 55, the rules of electronic records management and interagency exchange. Non-compliance with a specific formatting rule does not automatically render a document legally void: the consequences depend on the document type, mandatory metadata, and applicable legislation. Therefore, the demo should record the specific requirement and proof of its execution, rather than requesting an abstract certificate of "full compliance".
For electronic signatures, prepare test certificates and demonstrate signing, verification, timestamping, rejection of an unacceptable or invalid certificate, and storage of verification results. The signing policy must take into account the current Law "On Electronic Identification and Electronic Trust Services", the document type, the signer's role, and the rules of the specific organisation. A universal requirement to apply QES and Advanced Electronic Signatures equally to all documents would be incorrect.
If the system is being evaluated for scenarios covered by the experimental project under Resolution No. 642, separately verify the system's security authorisation, qualified electronic trust services, two-factor authentication, secure interaction, and backup. Some of these properties cannot be proven with a single click in the interface: the vendor must provide an architectural diagram, valid documents, and a recovery procedure, while the customer must verify them within their project.
- Metadata: the template and card generate the required data without manual correction of each document.
- Signatures: the signature type, signer, time, and verification result are visible.
- Access: roles prevent users from seeing or modifying unauthorised data.
- Audit: critical actions and configuration changes leave a reproducible trail.
- Exchange: delivery errors are not lost, and repeating a request does not create uncontrolled duplicates.
- Recovery: what is copied, how often, and how the viability of the backup is verified are defined.
How to record the result and compare systems
The outcome of the demo should be a protocol rather than a set of impressions. For each criterion, indicate the status as "confirmed", "requires configuration", or "not confirmed", and add links to the screen recording, log, document, or technical description. For open questions, record the responsible person, response deadline, work estimate, and method of accepting the result.
| Criterion | Evidence during the demo | What is recorded |
|---|---|---|
| Lifecycle | The document completed the scenario from creation to completion | Skipped stages and exceptions |
| Route | The administrator changed a rule without editing code | Configuration limits and impact of updates |
| Integration | A controlled exchange with a test system took place | API, errors, retries, and log |
| Signature and access | Positive and negative scenarios were executed | Policies, verification evidence, and roles |
| Continuity | The backup and recovery procedure was demonstrated | Target parameters and responsible persons |
Make the final decision after receiving a written response to any discrepancies between the scenario and the demonstrated result. This allows the team to separate a ready capability from a future promise and see what costs will remain after signing the contract.
Frequently Asked Questions
What data can be shared with a vendor for an EDMS demonstration?
Use an anonymised document with real metadata, attachment structure, and routing rules. Do not transfer personal data, official secrets, production accounts, or active signing keys to an unverified demonstration environment.
How to verify if a route is indeed configured without programming?
Ask the customer's administrator to add a stage, a condition, a parallel branch, and delegation during the demo. Record where configuration is sufficient and where code, separate work, or process restarts are required.
What does Cabinet of Ministers Resolution No. 642 change in the EDMS testing scenario?
For participants in the experimental project, it makes not only document processing but also secure system interaction, electronic trust services, two-factor authentication, system security authorisation, and backup subject to verification.
Sources
- Resolution of the Cabinet of Ministers of Ukraine No. 642 of 20.05.2026
- Resolution of the Cabinet of Ministers of Ukraine No. 55 of 17.01.2018
- Law of Ukraine "On Electronic Documents and Electronic Document Management"
- Law of Ukraine "On Electronic Identification and Electronic Trust Services"
- DSTU 4163:2020 "Requirements for Document Formatting"
- Rules for the Secure Use of QES in Digital Interaction
