A reference deployment model for Tetra eOffice
Instead of a case study, this page sets out what a real Tetra eOffice rollout looks like: the architecture, a 3–6 month roadmap, how the system maps to public-sector compliance, and one illustrative scenario. Everything here reflects the current product, not a customer project.
One system on your own infrastructure
The whole system runs on the unit’s servers or private cloud. Documents, files and logs stay there; an Internet connection is still needed for users to reach the server and for external services such as provider-based signing.
| Layer | Components | Role |
|---|---|---|
| Access | Web interface, Microsoft Teams, mobile browser | One interface for every task |
| Identity | Single sign-on gateway (Authentik, OIDC standard) | Centralized authentication; links Microsoft 365 accounts when the unit already uses them |
| Application | Business server (documented open API), BPMN 2.0 workflow engine (Flowable), background jobs and notifications | Documents, files, approval flows, deadline reminders |
| Specialized services | PAdES PDF digital-signing service, AI services (scan reading, semantic search), Metabase reporting | Signing, automated data entry, reporting |
| Data | PostgreSQL, S3-standard object store (MinIO), search index, activity logs | Storage owned by the unit |
| Operations | System monitoring (Prometheus, Grafana, Loki) | Track health, alert on incidents |
Every base component is open-source or follows an open standard, so the unit is not locked into one infrastructure vendor: moving the system to another server keeps the data intact.
Data flow
Users sign in once; incoming documents reach the business server where the AI service suggests fields and the workflow engine routes them; outgoing documents are signed and issued; all data stays in the unit’s store.
Two deployment options
| A · Fully independent | B · Using Microsoft 365 | |
|---|---|---|
| Suited to | Public-sector agencies and organizations that want to manage all accounts and data themselves | Enterprises already using Microsoft 365 |
| Sign-in | Accounts managed by the eOffice sign-in gateway | Reuses existing Microsoft 365 accounts through single sign-on; directory sync |
| Document storage | S3-standard object store on the unit’s own infrastructure | eOffice object store, with folder sync to SharePoint when needed |
| Internet connection | Required, so users can reach the eOffice server and to use external services such as provider-based signing | Required, as in option A, plus connectivity to Microsoft services for sign-in and sync |
| Artificial intelligence (AI) | Models running in-house | In-house models, or cloud AI when the unit permits |
A 3–6 month rollout, phase by phase
Duration depends on the number of workflows to configure, the depth of integration and the volume of data to migrate. Each phase ends with a deliverable the unit signs off on.
Discovery
Work with records officers, leadership and departments; collect registers, formatting templates and current approval flows; assess infrastructure and information-security requirements
Deliverable: Discovery report, process catalogue, architecture plan, detailed schedule
Install and configure workflows
Install on the unit’s infrastructure; configure the org structure, roles, permissions, registers, numbering rules, templates and approval flows
Deliverable: A staging environment running the surveyed workflows
Signing and interconnection integration
Integrate signing through the unit’s provider; Microsoft 365 sign-in where present; connect ERP or sector systems; wire document interconnection when in scope
Deliverable: Connectors tested on sample data
Data migration and training
Migrate registers and legacy documents within the agreed scope; role-based training for records officers, specialists, leaders and administrators
Deliverable: Reconciled data; role-based user guides
Pilot operation
Run in parallel with the old way; capture and resolve feedback; fine-tune workflows
Deliverable: Pilot report, resolved adjustment list
Acceptance and handover
Acceptance, cutover to production, handover of administration documents
Deliverable: Acceptance record, operations documentation
Reference cost: from about 300 million VND, depending on the feature scope and depth of integration. A specific quote follows the discovery phase.
How the system maps to public-sector requirements
The map separates what eOffice provides out of the box, what is a per-project integration, and what belongs to the unit’s infrastructure. A system does not by itself make a unit reach Level 3 — but a wrongly architected system makes Level 3 unreachable.
| Requirement | Legal basis | eOffice scope | Status |
|---|---|---|---|
| Records work: registering, numbering, routing, deadline tracking, electronic archiving | Decree 30/2020/NĐ-CP | Incoming and outgoing documents; registers; numbering rules; handling history; closure and archiving | Available |
| Confidentiality classification | TCVN 11930 | Four confidentiality levels; each role sees only up to its permitted level | Available |
| Public digital signatures | Law on E-Transactions 2023 | Signing via VNPT SmartCA, Viettel MySign, MobiFone HSM; PAdES PDF signing; counter-party signing invitations; verification lookup | Available |
| Government-only digital signatures | Decree 68/2024/NĐ-CP | Connection to the signing device or service of the government-only certification authority | Project integration |
| Document interconnection via the National Document Interoperability Axis or a ministry/province integration platform | Decision 28/2018/QĐ-TTg; QCVN 102:2016/BTTTT and Amendment 1:2022; organization identifiers under Decision 20/2020/QĐ-TTg (amended by Decision 09/2025/QĐ-TTg); Decree 47/2020/NĐ-CP | A packet adapter built to the current connection standard, configured with the unit’s identifiers | Project integration |
| Level-3 information security (a common precondition for connecting to shared platforms) | Decree 85/2016/NĐ-CP | The application layer: centralized authentication, per-user and per-group permissions, activity logs; servers placed in the network segments the unit defines | Application ready · remainder on the unit’s infrastructure |
| Encryption of data at rest | Level-3 data-security requirements | Disk and object-store encryption configured at deployment | Application ready · remainder on the unit’s infrastructure |
| Personal data processed domestically | Law on Personal Data Protection 91/2025/QH15 | All data stays on the unit’s infrastructure; AI runs in-house | Available |
Legal citations are drawn from two reviewed dossiers held in the repository: one on graded information security (Decree 85/2016), one on document interconnection (Decision 28/2018, QCVN 102, Decision 20/2020 and Decree 47/2020).
A hypothetical provincial department
A hypothetical provincial specialist department: about 200 staff, 8 divisions and subordinate units, roughly 1,200 incoming and 400 outgoing documents a month. Today it registers documents in a spreadsheet, routes paper and signs by hand. Chosen architecture: option A on the department’s own servers with an Internet connection; public signing at first, with government-only signatures and interconnection to the province platform scoped during discovery.
Incoming document flow
- A clerk scans the paper document; the system reads the scan and pre-fills the number, date, sending agency and summary per the Decree 30 format; the clerk checks and registers it.
- A department leader sees the document in their inbox, adds direction and routes it to the lead division.
- The division head assigns a specialist; the document has a deadline, and the system reminds ahead of it and escalates when overdue.
- The specialist records the outcome; the document moves to archive after the prescribed period.
Outgoing document flow
- A specialist drafts from a template and routes it through the division and department approval flow.
- A leader signs digitally on a computer or phone through the digital-signature provider.
- The clerk assigns the number automatically, issues the document and stores the electronic copy with its full handling history.
Metrics measured during the pilot
(measured on the unit’s real data, compared with before adoption)
- Time from receiving a document to registering it.
- Share of documents handled past deadline.
- Time to find a document and its handling history.
- Time from submitting for signature to issuing an outgoing document.
Try it on sample data instead of reading a case study
Demo on your scenario
A 60-minute walkthrough on sample data, following the exact incoming and outgoing document flow your unit uses today.
Pilot on your sample data
We set up a trial environment, configure one real register and one real approval flow, so your records officers and leaders can try it before deciding.
Need advice on a solution for your organization?
Leave your details and we'll get in touch to advise and demo.
Book a consultation