Workflow Management Layer — Service Concept (Detailed)

Core hierarchy (locked): Workflow → many Statuses → many Actions
Principle: Build screens once; govern visibility and progression by configuration.

---

1. Executive Summary

The Workflow Management Layer (WML) is a standardized control and visibility layer that governs how operational items (e.g., PR/PO/DO/WO/Inspection Orders) move through their lifecycle across the organization.

It ensures:

• Clarity of stage: every item is always in exactly one Status.
• Clarity of responsibility: each status defines who can observe vs who can act.
• Controlled progression: status changes occur only through explicit Actions, optionally gated by approvals, and always recorded in an audit trail.
• Reusable UX: build the main screens once, then configure what columns/sections/buttons appear per Workflow and per Status.
• Daily management readiness: department-specific DMS Boards show real-time items grouped by status (execution view, not BI charts).

---

2. Problem Statement & Outcomes

2.1 Current enterprise pain points (typical)

• Each department tracks the same operational items in different spreadsheets or siloed apps.
• Status updates are delayed; teams discover changes too late.
• Screens become “one-size-fits-all,” overloaded with fields and buttons that most users should not touch.
• Approvals are not traceable; it’s hard to prove who approved what and when.
• Control tower monitors are built repeatedly per department and per workflow.

2.2 Target outcomes

• Single page development for worklists and item pages, reused across workflows.
• Configuration-driven governance for who sees what and who can act when.
• Real-time work execution visibility via department boards.
• Audit-grade traceability: action logs, approval logs, status history, reason capture.

---

3. Decision Register (Validated)

Area	Decision	Choice	Implication / Standard
Terminology	Activity = Status	✅	Use Status everywhere (UI, docs, API).
Product naming	Client-facing label	✅ Workflow Management Layer	Positioned as cross-solution layer (MES/CMMS/QMS/WMS/DMS).
Workflow scope	1 Workflow = 1 Entity type	✅	Avoid mega-workflows; clear governance boundaries.
Internal vs ERP	Single workflow with Source attribute	✅	Items carry source=Internal/ERP; same governance applies.
Workflow metadata	Code/Name/Owner/Category/Related Dept	✅	Related Dept list is documentation-only unless promoted later.
Item identity	Internal ID + optional ETL_ID	✅	Internal ID is canonical; ETL_ID is traceability only.
Status ownership	Multiple owners possible	✅	Ownership is informational; act/observe rules remain explicit via actors.
Status templates	No mandatory status set	✅	Freeform per workflow; requires governance templates to avoid chaos.
Terminal statuses	Terminal statuses may still have actions	✅ (High risk)	Must document guardrails to prevent post-closure data corruption.
Action branching	1 action → 1 target status	✅	Predictable transition map; simpler audits and UI.
Evidence	Optional	✅	Keep lightweight; mandate reason for Cancel/Reject.
Approvals	Approval is an Action gate	✅	Approvals are attached to actions; printable/exportable.
Timeout escalation	Future milestone	✅	Document as roadmap; design objects now to avoid refactor.
Tabbing Management	Columns-based curated worklist	✅	Tabs are list presets (columns + filters + sort).
UI governance	Workflow controls sections + buttons	✅	“Develop once”; status shapes the page.
Control Tower	DMS Boards (items by status)	✅	Execution view, not KPI charts.
SLA / Rules	On-transition + continuous aging	✅	Supports aging and breach highlighting.
Cancel/Reject	Mandatory reason	✅	Hard enforcement at action submission.
Backflow	Allowed via explicit actions	✅	Backflow = formal transitions (Send Back/Rework).
Hold	Formal status + Resume action	✅	Hold is stateful, not a label.
Cross-workflow triggers	Supported	✅	Parent-child + peer links; orchestration is supported.
Split/Merge	Phase 2	✅	Document as roadmap; optional in v1.
Related Dept list usage	Documentation only	✅	Prevent hidden routing logic unless explicitly promoted later.

---

4. Core Concepts (Definition Level)

4.1 Workflow

A Workflow is a template defining how a single entity type is governed:

• What Statuses exist
• What Actions are allowed per status
• Who can observe / act / approve
• How screens behave (which columns/sections/buttons appear)
• Whether the system watches status changes for real-time boards
• Whether actions can trigger linked work in other workflows

Mental model: Workflow = the rulebook for one item type.

4.2 Status

A Status is a lifecycle stage inside a workflow. It defines:

• The stage meaning (Draft/Released/On Hold/etc.)
• Who can observe vs act
• Which UI components are visible
• Which actions are available
• Whether approvals or acknowledgements are logged

Mental model: Status = where work currently lives.

4.3 Action

An Action is an explicit, user-triggered operation that:

• Moves an item from one status to exactly one target status
• Optionally requires approvals
• Optionally captures additional input via a form
• Writes an auditable event log
• Optionally triggers downstream work (cross-workflow)
• Optionally evaluates rules/SLA (on transition)

Mental model: Action = the official button that advances reality.

---

5. Conceptual Objects (What must exist)

These are implementation-agnostic business objects.

Object	Purpose	Key Attributes (Conceptual)
Workflow Definition	Stores workflow template	Code, Name, EntityType, Owner Dept, Category, Related Dept list, Source Policy
Schema Binding	Connect workflow to data	Datasource, Table/Collection, PK field, Status field path, Reference mappings
Status Definition	Defines stages	Code, Name, Sequence, Access model, Visible components, Allowed actions
Action Definition	Defines transitions	Code, Name, FromStatus, ToStatus, Eligibility, Approval policy, Optional form
Actor	Role participant	Role name, Eligibility conditions (policy)
Ability / Component	UI governance	Component code, type (Action/View/Manage/Form), name
Workflow Item	Runtime record	Internal ID, Optional ETL_ID, Source, CurrentStatus, Handler(s), Key fields
Action Log	Audit	Action, Actor, Approvers, Timestamps, Input summary, StatusFrom/To
Tabbing Management View	Worklists preset	Tab name, Columns, Filters, Sort, Allowed roles
DMS Board	Dept execution board	Board name, Included statuses, Filters, Display fields
Rule/SLA Policy	Measures conditions	Rule name, Type, Thresholds, Outcomes (flag/escalation)
Link (Cross-workflow)	Relates items	Link type (Parent/Child/Peer), Related item IDs

---

6. WML Capabilities (Three Main Functions)

6.1 Capability A — Tabbing Management (Columns-based curated worklists)

Purpose
Enable one Worklists page to serve many departments by configuration.

What Tabbing Management controls

• Visible columns (subset of a large table)
• Default filters and sorting
• Who can access the tab (by Actor/Role eligibility)
• Optional status scoping (tab appears only for certain statuses)

Operational impact

• Developers build the Worklists UI once.
• Each department gets a curated view (columns + filter) without new development.

---

6.2 Capability B — DMS Boards (Real-time “TV dashboard”)

Purpose
Provide department-specific, real-time execution visibility:

• Items grouped by status (queues)
• What needs action now
• What is blocked
• What is overdue / breached

Concept
A DMS Board is not KPI charts. It is a work queue by status for daily operations.

Real-time update concept

• Status changes are broadcast as events.
• DMS Boards subscribe to department/entity streams.
• A fast read model (e.g., in-memory store) serves board lists instantly.

Recommended channel naming (concept)

• Dept-centric: wml/v1/{site}/{dept}/{entity}
• Status-centric: wml/v1/{site}/{entity}/{status}

---

6.3 Capability C — Workflow Studio (Workflow + Status + Action configuration)

Purpose
A single authoring plane where admins configure:

• Workflow template
• Statuses and Actions
• Approvals and Forms
• UI component visibility
• Tabbing Management and DMS Boards
• Rules and SLA

Workflow Studio blueprint steps

1. Create workflow definition (metadata)
2. Bind schema (table/collection, status field)
3. Define actors (roles + eligibility)
4. Register components (Component Registry & Ability Governance)
5. Define statuses (meaning + access + visibility)
6. Define actions per status (transitions)
7. Define approvals per action (optional)
8. Define forms per action (optional)
9. Configure Tabbing Management (worklists presets)
10. Configure DMS Boards (department queue boards)
11. Define rules/SLA (on-transition + aging)

---

7. Status Designer (Queues, not labels)

Each Status must answer:

• What does this stage mean operationally?
• Who can observe?
• Who can act?
• What UI sections are visible?
• What actions are available?
• Is it a hold stage? a rework stage? a terminal stage?

Standardization note: status naming is freeform, but operational meaning must be documented.

---

8. Action & Approval Designer (Progress governance)

8.1 Action rules (standard)

• One action must map to exactly one target status.
• Eligibility must be explicit (actors + conditions).
• Cancel/Reject must require a mandatory reason.

8.2 Approval model (action gates)

Approvals live on Actions, not on Statuses.

Supported approval types:

• All
• Any One
• Majority
• Sequential
• Threshold (N)

Approval logs must support:

• audit view
• print/export

---

9. Runtime Experience (End Users)

9.1 Worklists Page (driven by Tabbing Management)

• User opens a workflow worklist.
• Selects a tab.
• Sees only relevant columns with preset filters.

9.2 Item Detail Page (Status-driven UI)

• Current status displayed clearly.
• Sections/components shown/hidden based on status.
• Only allowed actions appear.

9.3 Action Panel Execution (Controlled transition)

1. Eligibility check
2. Approval gate (if required)
3. Form capture (if required)
4. Execute downstream triggers (cross-workflow) first (if configured; apply Blocking/Overwrite rule)
5. Execute action → patch item fields (if any) and move to target status
6. Record auditable event log (action + approvals + payload summary)
7. Evaluate rules/SLA on-transition
8. Publish update to DMS Boards

9.4 History & audit

Users can view:

• status history
• action history
• approvals and timestamps
• reason text for cancel/reject

---

10. Governance Rules & Guardrails

10.1 Transition integrity

• Status changes only via action.
• Each item has exactly one current status.

10.2 Terminal statuses with actions (high risk)

If terminal statuses still allow actions, guardrails should be documented:

• Mark them as Post-Closure Actions
• Limit to Reopen / Administrative reclassification / Non-destructive correction notes
• Require reason when post-closure actions run (recommended)

10.3 Cancel/Reject requires reason

• Mandatory reason for Cancel/Reject.
• Evidence optional (unless future compliance requires it).

10.4 Hold/Resume

• Hold is a formal status.
• Entering hold should capture reason (recommended).
• Resume returns to working status.

---

11. Rules & SLA (On-transition + Continuous aging)

11.1 When rules run

• On-transition: evaluate when action executes.
• Continuous aging: track time while item stays in status.

11.2 What rules can measure

• Time-based (aging > threshold)
• Quantity-based (qty comparisons)
• User/role-based (mismatch checks)
• Logical combinations (OR/AND)

11.3 Outcomes

• Flag/tag item
• Highlight on DMS Boards
• Optional: create issue/ticket in external tracking (capability)

---

12. Cross-Workflow Triggers & Linkages

12.1 Why it exists

Real operations are interconnected; one action can require work in another workflow.

12.2 Link types

• Parent–Child
• Peer–Peer

12.3 Trigger concepts

• Create linked item in another workflow
• Trigger linked action
• Split/Merge (Phase 2 roadmap)

---

13. Identity & Source Policy

• Primary identifier: Internal ID
• Optional ETL identifier: ETL_ID
• source=Internal or source=ERP

---

14. Example Blueprint — Delivery Order (DO)

Example only; statuses are freeform by policy.

14.1 Statuses

Status	Meaning	Notes
DO-OPEN	Created, not validated
DO-RELEASED	Approved for execution
DO-INPROG	Execution ongoing
DO-HOLD	Blocked	Reason recommended
DO-CLOSED	Completed	Terminal; guardrails if actions allowed

14.2 Actions

From	Action	To	Approval	Reason Required
DO-OPEN	Release	DO-RELEASED	Optional	No
DO-OPEN	Reject	DO-HOLD	Optional	Yes
DO-RELEASED	Start Execution	DO-INPROG	No	No
DO-INPROG	Put On Hold	DO-HOLD	No	Recommended
DO-HOLD	Resume	DO-INPROG	No	No
DO-INPROG	Close	DO-CLOSED	Optional	No

---

15. Example Blueprint — Maintenance Work Request (MWR)

15.1 Statuses

Status	Meaning
MWR-OPEN	Request created
MWR-REVIEW	Review/triage
MWR-APPROVED	Approved for planning
MWR-HOLD	On hold
MWR-CLOSED	Closed

15.2 Actions

From	Action	To	Approval	Reason Required
MWR-OPEN	Submit	MWR-REVIEW	No	No
MWR-REVIEW	Approve	MWR-APPROVED	Optional	No
MWR-REVIEW	Reject	MWR-CLOSED (or HOLD)	Optional	Yes
MWR-APPROVED	Put On Hold	MWR-HOLD	No	Recommended
MWR-HOLD	Resume	MWR-APPROVED	No	No
MWR-APPROVED	Close	MWR-CLOSED	Optional	No

---

16. Roadmap Items (Documented)

Area	Improvement
Approvals	Timeout + escalation routing
Boards	Advanced prioritization presets
Cross-workflow	Split/Merge operations (Phase 2)
Rules	Expand rule catalog and governance templates

---

17. UI Pages & Navigation Map (for UI/UX)

This section standardizes page names and clarifies where each end-user behavior is configured.

17.1 Workflow Studio (Configurator Pages)

• Workflow Studio → Overview
  • Workflow metadata, source policy.
• Workflow Studio → Schema Binding
  • Datasource/table/collection mapping, PK, status field path, references, status-watch toggle.
• Workflow Studio → Actor Model & Eligibility Rules
  • Actor/Role definitions, eligibility policy, role simulation (who matches what).
• Workflow Studio → Component Registry & Ability Governance
  • Component catalog (codes + types: Action/View/Manage/Form), usage report.
• Workflow Studio → Status Designer
  • Status meaning, access mode (observe/act), visible components, status-level SLA.
• Workflow Studio → Action Designer
  • Transition (from/to), actor eligibility, approvals, form, cross-workflow triggers, on-transition rules/SLA.
• Workflow Studio → Tabbing Management
  • Tab Views (columns + filters + sort + allowed actors).
• Workflow Studio → DMS Boards
  • Dept boards, included statuses/queues, filters, display fields, channel/topic mapping.
• Workflow Studio → Rules & SLA
  • Rule catalog, thresholds, outcomes (flags/highlight/optional ticket).
• Workflow Studio → Preview (Role Simulation) (recommended)
  • Preview Worklists, Item Detail visibility, and Action availability as a chosen Actor.

17.2 Runtime (End-User Pages)

• Work → Worklists → [Workflow]
  • Worklists page uses Tabbing Management to render role-specific columns/filters.
• Work → Worklists → [Workflow] → Open Item
  • Item Detail page renders sections and editable areas by Status Designer.
• Item Detail → Action Panel
  • Action availability/behavior is governed by Action Designer.
• Work → DMS Boards → [Dept Board]
  • Real-time execution board grouped by status queues.
• Item Detail → History & Audit
  • Status history, action logs, approvals, reasons.

---

18. Glossary (Quick Reference)

• Workflow: A template governing one entity type (statuses, actions, roles, UI behavior).
• Status: The current lifecycle stage of an item; defines access, UI visibility, and available actions.
• Action: A user-triggered operation that transitions an item from one status to one target status.
• Actor: A role definition with eligibility conditions for observing/acting/approving.
• Approval: A gate attached to an action; logs approvers and timestamps.
• Tabbing Management: A configured worklist preset (columns + filters + sorting + role access).
• DMS Board: A real-time department execution view of items grouped by status.
• Schema Binding: The mapping of a workflow to a database table/collection and status field.
• Rule/SLA Policy: A set of conditions and time/threshold measures that flag breaches and aging.
• Cross-workflow trigger: A configured rule where one action creates or progresses work in another workflow.
• Terminal Status: An end state (e.g., Closed) that typically stops progression; allowing actions here is high-risk.

---

Workflow Management Layer — Konsep Layanan (Detail)

Hierarki inti (dikunci): Workflow → banyak Status → banyak Action
Prinsip: Bangun layar sekali; atur visibilitas dan progres kerja lewat konfigurasi.

---

1. Ringkasan Eksekutif

Workflow Management Layer (WML) adalah lapisan standar untuk kontrol dan visibilitas yang mengatur bagaimana item operasional (misalnya PR/PO/DO/WO/Inspection Orders) bergerak sepanjang siklus hidupnya di seluruh organisasi.

WML memastikan:

• Kejelasan tahap: setiap item selalu berada tepat di satu Status.
• Kejelasan tanggung jawab: setiap status mendefinisikan siapa yang boleh observe (mengamati/lihat saja) vs siapa yang boleh act (melakukan aksi).
• Progres terkontrol: perubahan status hanya terjadi melalui Action yang eksplisit, dapat dipasang approval gate, dan selalu terekam di audit trail.
• UX yang dapat digunakan ulang: bangun layar utama sekali, lalu konfigurasi kolom/section/button yang tampil per Workflow dan per Status.
• Siap daily management: DMS Boards per departemen menampilkan item real-time yang dikelompokkan berdasarkan status (execution view, bukan chart BI/KPI).

---

2. Pernyataan Masalah & Outcome

2.1 Pain points perusahaan saat ini (umum)

• Setiap departemen melacak item operasional yang sama di spreadsheet berbeda atau aplikasi yang terpisah (silo).
• Update status terlambat; tim baru mengetahui perubahan ketika sudah terlambat.
• Layar menjadi “one-size-fits-all,” penuh kolom dan tombol yang seharusnya tidak disentuh oleh sebagian besar user.
• Approval tidak mudah ditelusuri; sulit membuktikan siapa approve apa dan kapan.
• Monitor/control tower dibuat berulang untuk tiap departemen dan tiap workflow.

2.2 Outcome target

• Pengembangan satu kali untuk Worklists dan halaman item, lalu dipakai ulang lintas workflow.
• Governance berbasis konfigurasi untuk mengatur siapa melihat apa dan siapa bisa melakukan aksi kapan.
• Visibilitas eksekusi real-time lewat board departemen.
• Traceability audit-grade: action logs, approval logs, status history, reason capture.

---

3. Decision Register (Tervalidasi)

Area	Keputusan	Pilihan	Implikasi / Standar
Terminologi	Activity = Status	✅	Gunakan Status di seluruh sistem (UI, dok, API).
Penamaan produk	Label client-facing	✅ Workflow Management Layer	Diposisikan sebagai layer lintas solusi (MES/CMMS/QMS/WMS/DMS).
Scope workflow	1 Workflow = 1 Entity type	✅	Hindari mega-workflow; boundary governance jelas.
Internal vs ERP	Satu workflow dengan atribut Source	✅	Item membawa source=Internal/ERP; governance sama.
Metadata workflow	Code/Name/Owner/Category/Related Dept	✅	Related Dept list hanya dokumentasi kecuali dipromosikan nanti.
Identitas item	Internal ID + opsional ETL_ID	✅	Internal ID adalah canonical; ETL_ID hanya traceability.
Ownership status	Multiple owners dimungkinkan	✅	Ownership informatif; aturan observe/act tetap eksplisit via actor.
Template status	Tidak ada set status wajib	✅	Bebas per workflow; perlu template governance agar tidak chaos.
Terminal status	Terminal masih boleh punya action	✅ (Risiko tinggi)	Harus ada guardrails untuk mencegah korupsi data setelah closed.
Branching action	1 action → 1 target status	✅	Transition map prediktif; audit dan UI lebih sederhana.
Evidence	Opsional	✅	Ringankan; reason wajib untuk Cancel/Reject.
Approvals	Approval adalah gate pada Action	✅	Approval menempel pada action; siap print/export.
Timeout escalation	Milestone masa depan	✅	Masukkan roadmap; desain objek dari sekarang agar tak refactor.
Tabbing Management	Worklist kurasi berbasis kolom	✅	Tab adalah preset list (columns + filters + sort).
UI governance	Workflow mengatur sections + buttons	✅	“Develop once”; status membentuk halaman.
Control Tower	DMS Boards (item by status)	✅	Execution view, bukan KPI chart.
SLA/Rules	On-transition + continuous aging	✅	Mendukung aging dan highlight breach.
Cancel/Reject	Reason wajib	✅	Hard enforcement saat submit action.
Backflow	Boleh via action eksplisit	✅	Backflow = transisi formal (Send Back/Rework).
Hold	Status formal + Resume action	✅	Hold bersifat stateful, bukan label.
Cross-workflow triggers	Didukung	✅	Parent-child + peer links; orchestration didukung.
Split/Merge	Phase 2	✅	Masuk roadmap; opsional v1.
Related Dept list usage	Dokumentasi saja	✅	Cegah routing tersembunyi kecuali dipromosikan jadi rule resmi.

---

4. Konsep Inti (Level Definisi)

4.1 Workflow

Workflow adalah template yang mendefinisikan governance untuk satu jenis entity:

• Status apa saja yang ada
• Action apa yang diizinkan per status
• Siapa yang boleh observe/act/approve
• Perilaku layar (kolom/section/button yang tampil)
• Apakah sistem melakukan watch perubahan status untuk board real-time
• Apakah action dapat memicu pekerjaan terkait di workflow lain

Mental model: Workflow = rulebook untuk satu jenis item.

4.2 Status

Status adalah tahap lifecycle dalam workflow. Status mendefinisikan:

• Makna tahap (Draft/Released/On Hold/dll.)
• Siapa yang boleh observe vs act
• Komponen UI mana yang terlihat
• Action mana yang tersedia
• Apakah approval/acknowledgement dicatat

Mental model: Status = tempat kerja saat ini berada.

4.3 Action

Action adalah operasi eksplisit yang dipicu user dan bersifat auditable:

• Memindahkan item dari satu status ke tepat satu target status
• Opsional membutuhkan approvals
• Opsional mengambil input tambahan lewat form
• Menulis event log yang bisa diaudit
• Opsional memicu pekerjaan downstream (cross-workflow):
  • batasan: hanya dapat mentrigger action dari workflow yang berelasi dengan workflow ini
• Opsional mengevaluasi rules/SLA (saat transisi)

Mental model: Action = tombol resmi yang mengubah realitas.

---

5. Objek Konseptual (Wajib Ada)

Ini adalah objek bisnis yang implementation-agnostic.

Objek	Tujuan	Atribut Kunci (Konseptual)
Workflow Definition	Menyimpan template workflow	Code, Name, EntityType, Owner Dept, Category, Related Dept list, Source Policy
Schema Binding	Menghubungkan workflow ke data	Datasource, Table/Collection, PK field, Status field path, Reference mappings
Status Definition	Mendefinisikan stage	Code, Name, Sequence, Access model, Visible components, Allowed actions
Action Definition	Mendefinisikan transisi	Code, Name, FromStatus, ToStatus, Eligibility, Approval policy, Optional form
Actor	Partisipan role	Role name, Eligibility conditions (policy)
Ability / Component	Governance UI	Component code, type (Action/View/Manage/Form), name
Workflow Item	Record runtime	Internal ID, Optional ETL_ID, Source, CurrentStatus, Handler(s), Key fields
Action Log	Audit	Action, Actor, Approvers, Timestamps, Input summary, StatusFrom/To
Tabbing Management View	Preset Worklists	Tab name, Columns, Filters, Sort, Allowed roles
DMS Board	Board eksekusi dept	Board name, Included statuses, Filters, Display fields
Rule/SLA Policy	Mengukur kondisi	Rule name, Type, Thresholds, Outcomes (flag/escalation)
Link (Cross-workflow)	Relasi antar item	Link type (Parent/Child/Peer), Related item IDs

---

6. Kapabilitas WML (Tiga Fungsi Utama)

6.1 Kapabilitas A — Tabbing Management (Worklists kurasi berbasis kolom)

Tujuan
Memungkinkan satu halaman Worklists melayani banyak departemen lewat konfigurasi.

Yang dikontrol oleh Tabbing Management

• Kolom yang terlihat (subset dari tabel besar)
• Filter dan sorting default
• Siapa yang boleh akses tab (berdasarkan eligibility Actor/Role)
• Opsional: status scoping (tab hanya muncul di status tertentu)

Dampak operasional

• Developer membangun Worklists UI sekali.
• Tiap departemen mendapat tampilan kurasi (kolom + filter) tanpa development baru.

---

6.2 Kapabilitas B — DMS Boards (Realtime “TV dashboard”)

Tujuan
Memberikan visibilitas eksekusi real-time per departemen:

• Item dikelompokkan per status (queues)
• Mana yang butuh action sekarang
• Mana yang blocked
• Mana yang overdue/breached

Konsep
DMS Board bukan KPI chart. Ini adalah work queue by status untuk operasi harian.

Konsep update real-time

• Perubahan status dibroadcast sebagai event.
• DMS Boards subscribe ke stream departemen/entity.
• Read model cepat (mis. in-memory store) menyajikan list board secara instan.

Rekomendasi penamaan channel (konseptual)

• Dept-centric: wml/v1/{site}/{dept}/{entity}
• Status-centric: wml/v1/{site}/{entity}/{status}

---

6.3 Kapabilitas C — Workflow Studio (Konfigurasi Workflow + Status + Action)

Tujuan
Satu authoring plane tempat admin mengkonfigurasi:

• Workflow template
• Statuses dan Actions
• Approvals dan Forms
• UI component visibility
• Tabbing Management dan DMS Boards
• Rules dan SLA

Workflow Studio — blueprint langkah

1. Create workflow definition (metadata)
2. Bind schema (table/collection, status field)
3. Define actors (roles + eligibility)
4. Register components (Component Registry & Ability Governance)
5. Define statuses (meaning + access + visibility)
6. Define actions per status (transitions)
7. Define approvals per action (opsional)
8. Define forms per action (opsional)
9. Configure Tabbing Management (preset worklists)
10. Configure DMS Boards (dept queue boards)
11. Define rules/SLA (on-transition + aging)

---

7. Status Designer (Queue, bukan sekadar label)

Setiap Status harus menjawab:

• Apa makna operasional tahap ini?
• Siapa yang boleh observe?
• Siapa yang boleh act?
• Section UI apa yang visible?
• Action apa yang available?
• Apakah ini hold stage? rework stage? terminal stage?

Catatan standardisasi: penamaan status bebas, tapi makna operasional wajib didokumentasikan.

---

8. Action & Approval Designer (Governance progres)

8.1 Aturan action (standar)

• Satu action harus map ke tepat satu target status.
• Eligibility harus eksplisit (actors + conditions).
• Cancel/Reject wajib punya reason.

8.2 Model approval (action gates)

Approval hidup di Actions, bukan di Status.

Tipe approval yang didukung:

• All
• Any One
• Majority
• Sequential
• Threshold (N)

Approval log harus mendukung:

• audit view
• print/export

---

9. Runtime Experience (End Users)

9.1 Worklists Page (driven by Tabbing Management)

• User membuka worklist workflow.
• Memilih tab.
• Melihat kolom relevan dengan preset filter.

9.2 Item Detail Page (UI berbasis status)

• Status saat ini terlihat jelas.
• Section/komponen tampil/sembunyi sesuai status.
• Hanya action yang diizinkan yang muncul.

9.3 Action Panel Execution (Transisi terkendali)

1. Eligibility check
2. Approval gate (jika perlu)
3. Form capture (jika perlu)
4. Eksekusi downstream triggers (cross-workflow) terlebih dahulu (jika dikonfigurasi; terapkan Blocking/Overwrite)
5. Eksekusi action → patch field item (jika ada) dan pindah ke target status
6. Rekam event log yang auditable (action + approvals + ringkasan payload)
7. Evaluasi rules/SLA on-transition
8. Publish update ke DMS Boards

9.4 History & audit

User dapat melihat:

• status history
• action history
• approvals dan timestamp
• reason untuk cancel/reject

---

10. Governance Rules & Guardrails

10.1 Integritas transisi

• Status berubah hanya via action.
• Setiap item punya tepat satu current status.

10.2 Terminal status masih punya action (risiko tinggi)

Jika terminal status masih mengizinkan action, guardrails perlu didokumentasikan:

• Tandai sebagai Post-Closure Actions
• Batasi ke Reopen / Administrative reclassification / Correction note non-destruktif
• Reason wajib saat post-closure action berjalan (disarankan)

10.3 Cancel/Reject wajib reason

• Reason wajib untuk Cancel/Reject.
• Evidence opsional (kecuali compliance meminta).

10.4 Hold/Resume

• Hold adalah status formal.
• Masuk Hold sebaiknya capture reason.
• Resume mengembalikan ke working status.

---

11. Rules & SLA (On-transition + Continuous aging)

11.1 Kapan rules berjalan

• On-transition: dievaluasi saat action dieksekusi.
• Continuous aging: waktu berjalan selama item berada di status.

11.2 Yang dapat diukur oleh rules

• Time-based (aging > threshold)
• Quantity-based (perbandingan qty)
• User/role-based (mismatch)
• Logical combinations (OR/AND)

11.3 Outcome

• Flag/tag item
• Highlight di DMS Boards
• Opsional: create issue/ticket ke external tracking

---

12. Cross-Workflow Triggers & Linkages

12.1 Kenapa ada

Operasi nyata saling terhubung; satu action dapat membutuhkan pekerjaan di workflow lain.

12.2 Tipe link

• Parent–Child
• Peer–Peer

12.3 Konsep trigger

• Create linked item di workflow lain
• Trigger linked action
• Split/Merge (roadmap Phase 2)

---

13. Identity & Source Policy

• Primary identifier: Internal ID
• Opsional ETL identifier: ETL_ID
• source=Internal atau source=ERP

---

14. Contoh Blueprint — Delivery Order (DO)

Contoh; status bebas sesuai kebijakan.

14.1 Status

Status	Makna	Catatan
DO-OPEN	Dibuat, belum valid
DO-RELEASED	Disetujui untuk eksekusi
DO-INPROG	Sedang dieksekusi
DO-HOLD	Terblokir	Reason disarankan
DO-CLOSED	Selesai	Terminal; guardrails jika action diizinkan

14.2 Actions

Dari	Action	Ke	Approval	Reason Required
DO-OPEN	Release	DO-RELEASED	Opsional	Tidak
DO-OPEN	Reject	DO-HOLD	Opsional	Ya
DO-RELEASED	Start Execution	DO-INPROG	Tidak	Tidak
DO-INPROG	Put On Hold	DO-HOLD	Tidak	Disarankan
DO-HOLD	Resume	DO-INPROG	Tidak	Tidak
DO-INPROG	Close	DO-CLOSED	Opsional	Tidak

---

15. Contoh Blueprint — Maintenance Work Request (MWR)

15.1 Status

Status	Makna
MWR-OPEN	Request dibuat
MWR-REVIEW	Review/triage
MWR-APPROVED	Disetujui untuk planning
MWR-HOLD	Ditahan
MWR-CLOSED	Ditutup

15.2 Actions

Dari	Action	Ke	Approval	Reason Required
MWR-OPEN	Submit	MWR-REVIEW	Tidak	Tidak
MWR-REVIEW	Approve	MWR-APPROVED	Opsional	Tidak
MWR-REVIEW	Reject	MWR-CLOSED (atau HOLD)	Opsional	Ya
MWR-APPROVED	Put On Hold	MWR-HOLD	Tidak	Disarankan
MWR-HOLD	Resume	MWR-APPROVED	Tidak	Tidak
MWR-APPROVED	Close	MWR-CLOSED	Opsional	Tidak

---

16. Roadmap Items (Terdokumentasi)

Area	Improvement
Approvals	Timeout + escalation routing
Boards	Advanced prioritization presets
Cross-workflow	Split/Merge operations (Phase 2)
Rules	Expand rule catalog dan governance templates

---

17. Peta Halaman UI & Navigasi (untuk UI/UX)

Bagian ini menstandarkan nama halaman dan menjelaskan di mana konfigurasi dilakukan.

17.1 Workflow Studio (Configurator Pages)

• Workflow Studio → Overview
  • Metadata workflow, source policy.
• Workflow Studio → Schema Binding
  • Mapping datasource/table/collection, PK, status field path, references, status-watch toggle.
• Workflow Studio → Actor Model & Eligibility Rules
  • Definisi actor/role, eligibility policy, role simulation.
• Workflow Studio → Component Registry & Ability Governance
  • Katalog komponen (code + type: Action/View/Manage/Form), usage report.
• Workflow Studio → Status Designer
  • Makna status, access mode (observe/act), visible components, SLA per status.
• Workflow Studio → Action Designer
  • Transition (from/to), eligibility actor, approvals, form, cross-workflow, rules/SLA on-transition.
• Workflow Studio → Tabbing Management
  • Preset tab (kolom + filter + sort + allowed actors).
• Workflow Studio → DMS Boards
  • Dept boards, status queues, filters, display fields, channel/topic mapping.
• Workflow Studio → Rules & SLA
  • Rule catalog, thresholds, outcomes (flags/highlight/optional ticket).
• Workflow Studio → Preview (Role Simulation) (recommended)
  • Preview Worklists, Item Detail, Action availability sebagai actor tertentu.

17.2 Runtime (End-User Pages)

• Work → Worklists → [Workflow]
  • Worklists dirender oleh Tabbing Management (kolom/filter sesuai role).
• Work → Worklists → [Workflow] → Open Item
  • Item Detail dirender oleh Status Designer.
• Item Detail → Action Panel
  • Action behavior digovern oleh Action Designer.
• Work → DMS Boards → [Dept Board]
  • Board real-time per departemen (queue by status).
• Item Detail → History & Audit
  • Status history, action logs, approvals, reasons.

---

18. Glosarium (Quick Reference)

• Workflow: Template untuk mengatur satu jenis entity (status, action, roles, perilaku UI).
• Status: Tahap lifecycle item; menentukan akses, UI visibility, dan action yang tersedia.
• Action: Operasi yang memindahkan item dari satu status ke satu target status.
• Actor: Definisi role dengan kondisi eligibility untuk observe/act/approve.
• Approval: Gate pada action; log approver + timestamp.
• Tabbing Management: Preset worklist (columns + filters + sorting + akses role).
• DMS Board: Tampilan eksekusi real-time per departemen; item dikelompokkan per status.
• Schema Binding: Mapping workflow ke table/collection dan field status.
• Rule/SLA Policy: Aturan threshold/aging yang menghasilkan breach/flag.
• Cross-workflow trigger: Rule yang membuat atau memprogres pekerjaan di workflow lain.
• Terminal Status: Status akhir (mis. Closed); membolehkan action di sini berisiko tinggi.