Business Workflows

The real end-to-end processes each module supports — who acts, in what order, and what the system does. Use this to script demos of specific stakeholder journeys and to write test cases.

Official correspondence Request approvals KPI measurement Collaboration hub Meetings Files & co-editing Tenant lifecycle

1 · Official correspondence (DWMail)

DWMail unifies ordinary email with formal government correspondence. Incoming official documents flow through a three-desk pipeline with manager review, approval, signing/stamping, and archival.

  Incoming ─▶ [ Receive Desk ] ─▶ [ Review Desk ] ─▶ [ Secretary Desk ] ─▶ Archive
              register + route     review / approve /   final / conditional
              (numbers, urgency)   forward-to-secretary  approval · sign · stamp
                        └── Manager review path (send-to-manager · recommend · return) ──┘

Step	Who	Action
1. Register	ReceiveDesk	Records the incoming item: direction, classification, urgency, action-deadline, incoming number; uploads evidence; completes the stage → forwards to Review (or straight to Secretary if urgent).
2. Review	ReviewDesk	Reads the stage inbox & history, reviews attachments, then completes with a recommendation: Approve · Reject · forward-to-Secretary.
3. Manager review	Office Manager	Optional escalation: send-to-manager, publish recommendation, reply-from-manager, return-to-office.
4. Finalize	SecretaryDesk	Records the final / conditional approval, assigns the outgoing number, signs & stamps (watermarked PDF), and archives.

Also in DWMail: ordinary mailboxes (personal + department shared inboxes with claim/assign), compose with DOCX letters (Collabora), follow-up flags, tasks, calendar invites, and its own mail server (SMTP receive, POP3, app-passwords).

2 · Request & approval engine (WorkFlow)

Employees raise requests from published, versioned form templates (each a DOCX edited in-browser). Each request travels a configured chain of stages and actions; the current holder approves/advances, sends back, finishes, or routes it onward.

  Requester ─▶ submit (from template + DOCX + attachments)
        │
        ▼   at each stage the current holder applies an action:
   [ Stage ] ──approve/advance──▶ [ next Stage ] ──▶ … ──▶ Finished
        │  ├─ send back ──▶ back to requester
        │  ├─ route to user / department-job / role
        │  └─ dynamic escalation up the reports-to chain
        └─ signing action ⇒ requires e-signature ⇒ stamps the DOCX

Concept	What it means
“Pending on you”	A request appears in your Inbox if it is assigned to you, or unassigned but pointed at your department-job or one of your workflow roles.
Actions	Approve/advance, send-back, finish; may require assignment, target a role/department-job, or require a signature.
SLA	Stages can have an SLA; breaches are flagged and (optionally) auto-advanced by the system.
Parallel	A stage can fan a request into parallel branches that re-join later.
Signatures	Signing actions are blocked unless the user has uploaded an e-signature; on apply, a signature block is stamped onto the DOCX.
My Work	Every pending approval is mirrored into the shell’s unified My Work inbox.

3 · KPI measurement (KPIS)

Organizations define auditable activities, each owning KPIs, each broken into measurement periods, with actual values per department captured each period.

  Activity (Family) ─▶ KPI (target · unit · direction) ─▶ Period (monthly/…) ─▶ Value (per department)
                                                                           │
                       reminders when a value is due/overdue ──▶ bell + My Work (reminder)

Auditors own an activity: define KPIs, generate periods, enter values, manage the activity’s departments.
Scoring is attainment % (value ÷ target), variance, and a direction-aware RAG (red/amber/green).
Reminders for due/overdue periods land in the bell and the unified My Work inbox.
Dashboards are drag-and-drop widget canvases; a dashboard can be shared read-only via a public link.

4 · The collaboration fabric (Hub)

The differentiator: one owner per concept, everyone else holds a reference. Every module writes into the Hub, and the shell surfaces it in one place.

One “My Work”

Every task, follow-up, approval, reminder and @mention from every module — Late / Today / Upcoming — one click from the source.

One calendar

Meetings (from chat/mail/workflow) plus a deadline overlay from My Work.

One conversation

Comment + @mention on any record; mentions land in the bell and My Work.

One search & one bell

A permission-trimmed search box across modules, and a single notification bell where every alert unfurls into a live card.

5 · Meetings

A meeting is a calendar event whose link is a Jitsi room. Schedule ahead or “meet now”; the shell embeds the room with a pre-join lobby.

Step	Action
Schedule / meet-now	From a chat room or the calendar; attendees get a bell notification + ICS invite.
Join	Open `/meet/{id}` — camera/mic lobby, then the embedded room. A reminder fires ~10 min before.
Record	The organizer can start/stop recording; the recording is captured and stored, and appears on the meeting detail for playback/download.
After	The Meetings Hub lists ongoing / upcoming / past meetings with recordings, chat transcript and participants.

6 · Files & co-editing (Drive)

Store — personal & shared folders; chunked resumable uploads; versioning & trash.
Share — grant a colleague Viewer / Downloader / Editor, or a revocable, time-limited link.
Co-edit — open Office documents in the browser (Collabora/WOPI); a Canva-style design studio for visuals.
Sync — a Windows desktop client mirrors the drive; storage is metered against the plan quota.

7 · Tenant lifecycle (operator)

The operator’s process for standing up, demoing and tearing down a customer — covered click-by-click in the Demo Walkthrough.

  Provision ─▶ Seed demo ─▶ Present ─▶ End
   tenant+owner  org+users+       tour every    Soft-delete (reversible, purge after window)
   +subscription  module content   module         └─ or ─ Purge permanently (Identity + every module)

Clean teardown. A purge removes the tenant from Identity and asks every module (mail, chat, drive, KPIs, news, hub) to wipe its own data, reporting exactly what each removed — so a demo leaves nothing behind.