“Help me find descriptions of how document workflows are implemented in existing Electronic Document Management Systems (EDMS), preferably those used by government organizations… Document routing… Document tagging… Backend implementation… Frontend implementation… Please focus on real, existing EDMS implementations and provide concrete examples.”
This dossier triangulates 248 collected source rows — 13 cited public-sector deployments, 120 inspectable technical mechanisms from Mayan EDMS, Alfresco and OpenKM, 40 EU Ares/HAN ecosystem sources and 75 Government of Canada GCdocs discovery rows. Of the 45 system-by-layer cells in the matrix below, 24 are directly documented, 8 are inferred only from product architecture, and 13 could not be evidenced.
Each cell states only what its cited source shows; a vendor's generic capability is never counted as proof that a given deployment enabled it.
Synthesized only from directly supported mechanisms; each stage cites the systems that document it.
The Commission's records ecosystem, reused by joint undertakings and agencies. Audit and workflow data name the people and departments behind signing, transmission, file responsibility and archive transfer.
Ares reference numbers typed into SFC2014 are validated immediately and attachments import automatically — a real, documented integration boundary between two Commission systems.
Documents get workflow instances from templates holding states, transitions, conditions, transition fields/actions and a final-state flag. Transitioned events commit before state actions run; state changes can update indexes and workflow state is usable in index templates.
Tags have labels and colors with bulk-attach APIs; the UI ships workflow runtime links, state lists, a preview diagram generator, transition forms and tag widgets.
Everything is a node with a unique ID and typed properties; types and aspects classify content. Changes fire events, and folder rules start or cancel workflows, add aspects, set properties, version, email or run scripts.
REST v1, Java Foundation APIs, OpenCMIS and an audit stream expose workflow actions; roles run Consumer → Coordinator; Process Services is Spring/JPA with an HTML5/AngularJS frontend.
Andhra Pradesh and Himachal Pradesh both document the same lifecycle: diarisation of inward receipts, creation of files, movement of receipts and files, and archival of records — the file, not just the document, is the routed unit.
UP's DRS assigns a tracking number and builds a trail from the originating office through every routed office; items tagged “To receive” auto-attach to a designated user, and a terminal tag ends the route. DPWH's DoTS is an electronic routing slip enforcing first-in-first-out processing.
Metadata lives in property groups with named fields (project code, customer, revision…). Setting a property group is an event: automation scripts generate IDs, rename documents from a metadata mask, restrict which groups a node may carry, and restyle folders. Workflow forms define approve/deny transitions.
Keep workflow definitions (states, transitions, conditions, final-state flag) separate from per-document instances; expose “valid transitions from here” as an API; commit the transition event before running state actions. Seen in Mayan EDMS.
Fire events on every content change and let folder-level rules start/cancel workflows, set properties or run scripts. Seen in Alfresco rules and OpenKM automation events.
Route on metadata completeness (Chesterfield County), rename and file from a metadata mask (OpenKM), or launch workflows when a document's type changes (Mayan). Tags can be operational controls, not just labels: UP DRS's “To receive” and terminal tags drive delivery and termination.
Give every document a tracking number and an office-by-office trail (UP DRS); log who signed, transmitted, held and archived each file as audit/workflow data (HAN); stream workflow actions into an audit API (Alfresco).
A document entering a signature or assignment workflow is visible only to its creator and the workflow actors, layered on roles/profiles and access rights. Documented for Ares/HAN.
A register number (Ares reference) that a second system can validate and pull attachments from turns the EDMS into the system of record for other applications. Documented for Ares ↔ SFC2014.
| System | Organization | Documented routing behavior | Source |
|---|
Explicit gap: no government-system screenshots or interface documentation surfaced anywhere in the collected sources; UI-level evidence exists only for Mayan EDMS, Alfresco Process Services and OpenKM. GCdocs rows beyond the official Canada.ca sources are treated as a documentation trail only.
Method: targeted live-web research across government manuals, privacy and records notices, user guides, product documentation, API references, Git repositories/issues/release notes and case studies; several thousand search results scanned, 248 shaped rows kept (13 deployments, 120 technical mechanisms, 40 EU Ares/HAN sources, 75 GCdocs discovery rows). Matrix cells score direct documentation vs architecture-only inference vs absence; blank source fields were never inferred. Release-note noise and system-identification-only rows were cut for space.