Work Permit — Requirements Analysis Report

Date: 2026-03-06 Source: Internal meeting response (tester feedback on Requirements Clarification) Prepared by: Development Team Status: Analysis in progress. F1–F8 answered (2026-03-09). F9–F15 (Section 6 type-specific details) still pending tester response. Section 5.3 (Evaluation Form) pending senior colleague confirmation.

How to read this document

Each section follows this structure:

Original question — what we asked
Tester response — the original Thai answer (verbatim)
Dev team interpretation — what we understand this means
Current code state — what we already built
Required changes — what needs to change
Follow-up questions — anything still unclear

Diagrams provided by the tester are referenced as image1.png through image7.png from the internal meeting document.

Section 1: The Daily Permit Cycle

1.1 Does someone fill out a new paper permit form every day?

Tester response:

"ใช่"

Interpretation: Confirmed — yes, a new permit is created every day.

Current code: Our architecture already models this — each Work Permit is a separate task/workflow instance. Once closed, it cannot be reopened. A new WP task is created the next day.

Required changes: None. Our daily cycle model is validated.

1.2 Or do they use the same permit for multiple days?

Tester response:

"ไม่ ต้องเปิดใหม่และปิดทุกวัน กรณีขยายเวลาเป็น PTW เดิม เอกสารแนบตามเดิมแต่เพิ่มเติมได้"

Interpretation: No — must open new and close every day. For within-day time extension, it stays on the same PTW. Attached documents remain the same but can be added to.

Current code: Matches. Our extension model adds extension cards to the existing PTW (Part 4), which is exactly this behavior.

Required changes: None.

1.3 If a job takes 5 days, how many paper permit forms are created?

Tester response:

"5"

Interpretation: Confirmed — 5 separate permits for 5 days.

Current code: Matches. Each day the contractor creates a new Work Permit Request task in the system.

Required changes: None.

1.4 What time does a permit start and end?

Tester response:

"อิสระแต่ Default เริ่มเวลางาน ตัวอย่างเช่น บางทีอาจจะขอ 9.00-12.00 ก็ได้"

Interpretation: Flexible, with a default set to work start time. For example, a contractor might request 9:00-12:00 if they only need the morning.

Current code: We have startDateTime and endDateTime fields in the permit form. The system's Work Hours setting (from System Settings) can provide the default.

Required changes:

Consider auto-populating start/end time from system work hours setting as defaults
This is a nice-to-have, not blocking

1.5 What happens during lunch break — does the permit pause?

Tester response:

"ไม่"

Interpretation: No — the permit does not pause during lunch. Work time is continuous.

Current code: No pause concept exists in our system. Correct as-is.

Required changes: None.

1.6 If work is not finished by end of day, what happens to the permit?

Tester response:

"ต้องปิด PTW ทุกวัน แต่ยังไม่ปิดงาน วันถัดไปมาขอ PTW ใหม่"

Interpretation: Must close PTW every day but not close the job (project). The next day, a new PTW is requested.

This confirms the critical distinction:

Daily PTW Close = closing today's work permit (Part 5 completion)
Close Job = project-level closure (Issue #509) — completely separate

Tester also provided a flow diagram (image4.png) showing:

PTW (active) → Daily Close PTW → Decision: Job Close PTW?
  - No → Loop back (next day: new PTW)
  - Yes → Work Complete

Current code: Our RequestClose state currently serves as the daily PTW close. The project-level "Close Job" (Issue #509) is not yet implemented.

Required changes:

The current RequestClose → Approved flow is correct for daily PTW close
Close Job is a separate feature at the project level — see Section 4 for full details

Section 1 Summary

Item	Status
Daily permit cycle	Fully confirmed, matches our code
1 PTW per day	Confirmed
Extension = same PTW	Confirmed
Daily close vs job close	Confirmed as separate concepts
Code changes needed	None for Section 1

Section 2: Who Signs the Permit (Authorization)

2.1 Who is the "Requestor"?

Tester response:

"ผู้รับเหมา เป็นคนกรอกคำขอ PTW ต้องอนุมัติ 3 ฝ่าย เจ้าของงาน จป. เจ้าของพื้นที่"

"สีแดง: ผู้ร้องขอ สีเขียว: ผู้อนุมัติ รวมถึงการขยายเวลา"

Interpretation:

Requestor = Contractor (ผู้รับเหมา) — fills out the PTW request
Must be approved by 3 parties: Work Owner (เจ้าของงาน), Safety Officer (จป.), Area Owner (เจ้าของพื้นที่)
In the tester's diagram (image2.png): Red = requestor, Green = approvers, including for time extensions

Current code: Matches. Our workflow assigns the permit to the Contractor for filling, then sends to SO + WO + WAO for co-review.

Required changes: None for the requestor role.

2.2 Who is the "Controller"?

Tester response:

"ผู้ควบคุมมีหน้าที่อะไร? ตามหลักทั้ง 3 ฝ่าย เจ้าของงาน จป. เจ้าของพื้นที่"

Interpretation: The tester asks back: "What is the Controller's duty?" They don't use the term "Controller" as a single role. Instead, all 3 parties (WO, SO, WAO) collectively serve the controlling function.

Our answer to the tester: The "Controller" term comes from the paper form (RW-F06-01). In our digital system, we don't have a separate "Controller" role. The 3 approvers (WO, SO, WAO) collectively perform this function through the co-review process. We will remove the "Controller" label from the system.

Required changes:

Remove any reference to "Controller" in UI and documentation
The paper form's 3 roles map to our system as:
- ผู้ขอ (Requestor) → Contractor
- ผู้ควบคุม (Controller) → Not a single person; split across WO + SO + WAO
- ผู้อนุญาต (Permit Issuer) → Same 3 parties via co-review signatures

2.3 Who is the "Permit Issuer"?

Tester response:

"อนุญาต PTW จะมี เจ้าของงาน จป. และเจ้าของพื้นที่ ต้องมีลายเซ็นทั้ง 3 ใบ PTW ถึงจะอนุมัติ เจ้าของพื้นที่จะมี check box ให้ระบุว่า 'Log Out Tag Out' ก่อนจึงจะอนุมัติได้"

Interpretation:

PTW approval requires all 3 signatures: WO, SO, Area Owner
Area Owner has a special "Lock Out Tag Out" (LOTO) checkbox that must be checked before they can approve
Until all 3 have signed, the PTW cannot be approved

Current code:

Co-review with 3 approvers: Already implemented (_approvals.Count >= 3)
LOTO checkbox: Not implemented — this is a new requirement

New Requirement: LOTO Checkbox

The Area Owner (เจ้าของพื้นที่) must check a "Lock Out Tag Out" checkbox before they can approve the PTW. This is a mandatory pre-condition for the Area Owner's approval only.

Implementation options:

Add LOTO checkbox to the PTW form (Part 3) — Area Owner checks it before signing
Add LOTO checkbox to the approval confirmation dialog — appears only for Area Owner role
Add LOTO as a field on the co-review approval action

Option 2 is recommended — it keeps the form clean and puts the LOTO check at the decision point.

Required changes:

Add LOTO checkbox pre-condition for Area Owner approval
Issue: New (related to #506)

2.4 Are there really 3 time phases (morning/afternoon/evening)?

Tester response:

"เซ็นครั้งเดียว ไม่ระบุ เช้า/บ่าย/เย็น ให้ระบุช่วงเวลา"

Interpretation: Sign once only. Do NOT use morning/afternoon/evening phases. Instead, specify a time range (e.g., 9:00-17:00).

Major Change Required: Remove 3-Phase Authorization

Current code (ptw-authorization.component.ts):

3 collapsible phases labeled "รอบที่ 1 (เช้า / Morning)", "รอบที่ 2 (บ่าย / Afternoon)", "รอบที่ 3 (ค่ำ / Evening)"
Each phase has: date, start time, end time, 4 signatures
Total: 3 phases x 4 signatures = 12 signature slots

Required:

1 time range (date + start time + end time) + 4 signatures
Total: 4 signature slots only
Remove the entire phase/accordion structure from Part 3

Required changes:

Rewrite ptw-authorization.component.ts — remove phase loop, simplify to single date/time range + 4 signatures
Update WorkPermitAuthorizationPhase model — simplify or replace
Issue: #506

2.5 If phases exist, do the same 3 people sign each phase?

Tester response:

"3 ฝ่ายทุกครั้ง เช่น การขยายเวลา"

Interpretation: All 3 parties sign every time — including for extensions. Since phases don't exist (see 2.4), this confirms: all 3 parties approve for every action (initial approval, extension, closure).

Current code:

Initial co-review: SO + WO + WAO (3 of 3) — Correct
Extension review: SO + WO only (2 of 2) — Wrong, must include WAO
Request close: SO + WO + WAO (3 of 3) — Correct

Required changes:

Add Area Owner (WAO) to extension review — see Section 3.3
Issue: #508

2.6 How many total signatures should one permit have?

Tester response:

"ควรมีลายเซ็น ทั้ง 3 ตำแหน่งผู้อนุมัติ เจ้าของงาน, จป., เจ้าของพื้นที่ และ 1 ผู้ขอ(ผู้รับเหมา) รวมกันเป็น 4"

Interpretation: 4 total signatures per authorization:

ผู้ขอ / Requestor → Contractor
เจ้าของงาน → Work Owner
จป. → Safety Officer
เจ้าของพื้นที่ → Area Owner

Current code signature labels:

Slot	Current Label	Required Label
1	Contractor (ผู้รับเหมา)	ผู้ขอ (Requestor / Contractor)
2	Supervisor (ผู้ควบคุมงาน)	เจ้าของงาน (Work Owner)
3	จป. (Safety Officer)	จป. (Safety Officer) — same
4	เจ้าของพื้นที่ (Area Owner)	เจ้าของพื้นที่ (Area Owner) — same

Signature Label Change

Slot 2 "Supervisor" must be renamed to "Work Owner" (เจ้าของงาน).

In the tester's model, there is no "Supervisor" role. The 3 approvers are Work Owner, Safety Officer, and Area Owner. The current code uses "Supervisor" (ผู้ควบคุมงาน) in Part 3, Part 4, and Part 5 signatures — all must be updated.

Affected files:

ptw-authorization.component.ts — signature field supervisorSignature
ptw-extension.component.ts — signature field supervisorSignature
ptw-completion.component.ts — signature field supervisorSignature
work-permit-form.model.ts — WorkPermitAuthorizationPhase, WorkPermitExtension, WorkPermitCompletionInspection

Required changes:

Rename "Supervisor" → "Work Owner" across all signature labels
Keep the field names as-is in the model (avoid breaking changes) but update display labels
Issue: #506

Section 2 Summary

Item	Status	Issue
3-phase authorization	Remove — sign once, specify time range	#506
12 signatures → 4	Simplify to 1 set of 4 signatures	#506
Supervisor → Work Owner	Rename label in Parts 3, 4, 5	#506
LOTO checkbox	New — Area Owner pre-condition	New
Controller term	Remove — not used in their organization	—
Code changes needed	Major refactor of Part 3	—

Section 3: Extension vs Surrender/Re-issue

3.1 Are "extension" and "surrender/re-issue" the same thing?

Tester response:

"surrender/re-issue คืออะไร??"

"การออกบัตรจะอยู่ในกระบวนการในส่วนของอบรม"

"การต่ออายุ มี 2 อย่าง"

"ขยายเวลา PTW ในวัน — ขยายเวลาเป็น PTW เดิม เอกสารแนบตามเดิมแต่เพิ่มเติมได้"

"ต่ออายุโครงการ"

2.1 "กรณีโครงการยังไม่หมดอายุ ขอ PTW ได้ตามปกติ"

2.2 "กรณีโครงการหมดอายุ ให้แจ้งผู้รับเหมาในหน้าขอ PTW ให้เลือกต่ออายุและระบุวัน (ไม่เกี่ยวกับวันที่ของจัดซื้อ)"

2.2.1 "เจ้าของงาน เห็นข้อมูลจากผู้รับเหมาสามารถปรับ เพิ่ม ลด จำนวนวันได้"

2.2.2 "จป./เจ้าของพื้นที่ เห็นการร้องขอและรับทราบตามขบวนการ"

2.2.3 "จัดซื้อ ไม่เกี่ยวข้องกับขบวนการนี้ในระบบ แต่จะเห็นเวลาทำงานจริงของโครงการ"

2.2.4 "ข้อมูลระดับโครงการ จะแสดงว่าเกินกำหนดเวลา"

Interpretation:

The tester does not recognize the term "surrender/re-issue" — they asked "What is this??". This paper form concept does not apply to their operation. We should remove it from our documentation and gap analysis.

The tester identifies two distinct types of extension:

Type 1: Within-Day Time Extension (ขยายเวลา PTW ในวัน)

Same PTW, same attached documents (can add more)
Example: permit was for 9:00-12:00, extend to 15:00
This is what our current Extension (Part 4) does — correct as-is

Type 2: Project Duration Extension (ต่ออายุโครงการ)

New Feature: Project Duration Extension

This is a completely new concept not in our codebase. It handles the case when the project itself has expired but work continues.

Workflow:

If project not expired → contractor can request daily PTW normally
If project expired → system notifies contractor on the PTW request page
Contractor selects "extend project" and specifies additional days
Work Owner reviews: can adjust (increase/decrease) the number of days
SO / Area Owner: acknowledge the request per standard process
Purchasing: NOT involved in this process, but can see actual working time
Project-level data shows a "past deadline" indicator

Key rule: The extension days are NOT related to purchasing dates (จัดซื้อ). This is operational, not contractual.

Current code: No project duration extension exists. The project end date is set during Project Registration and never changes.

Required changes:

Remove "surrender/re-issue" from documentation and gap analysis
New feature: Project duration extension (see follow-up questions below)

Follow-up questions: ~~(Answered — see F1–F3)~~

~~Does the project duration extension happen within the Work Permit workflow, or is it a separate operation on Project Registration?~~ → On PTW request page
~~When WO adjusts days, does this change the EndedAtUtc on the Project entity?~~ → Yes
~~Should there be a visual indicator on the project card?~~ → Yes, show overdue indicator

3.2 Or are they different processes?

Tester response:

"ตามข้อ 3.1"

Interpretation: See 3.1 above. The two types of extension are different processes.

3.3 Who must approve an extension?

Tester response:

"ขยายเวลาการทำงานผู้อนุมัติมี 3 ฝ่าย เจ้าของงาน+จป+เจ้าของพื้นที่"

Interpretation: Extension approvers are 3 parties: Work Owner + Safety Officer + Area Owner.

Code Change Required: Extension Review Roles

Current code (WorkPermitRequestWorkflow.cs lines 282-284):

RequestExtension: AssigneeRoleIds = [SafetyOfficer, WorkOwner]  // 2 parties
ApproveExtension: VisibleToRoleIds = [WorkOwner, SafetyOfficer]  // 2 parties
ApproveExtensionAsync: threshold >= 2

Required:

RequestExtension: AssigneeRoleIds = [SafetyOfficer, WorkOwner, WorkspaceOwner]  // 3 parties
ApproveExtension: VisibleToRoleIds = [WorkOwner, SafetyOfficer, WorkspaceOwner]  // 3 parties
ApproveExtensionAsync: threshold >= 3

Required changes:

Add WorkspaceOwner to extension review roles
Change approval threshold from 2 to 3
Issue: #508

3.4 Is there a maximum number of extensions per day?

Tester response:

"ไม่ ยกตัวอย่างเช่น ขอ 12.00 ขอขยายเพิ่ม 13.00 ต่อมาขอเพิ่มอีก 15.00น."

Interpretation: No limit on extensions. Example: request at 12:00, extend to 13:00, then extend again to 15:00.

Current code: Our extension model uses an array (extensions[]) with an "Add Extension" button — supports unlimited extensions.

Required changes: None. Already correct.

3.5 When extended, does the contractor need to fill any new forms?

Tester response:

"1. ขยายเวลาเป็น PTW เดิม เอกสารแนบตามเดิมแต่เพิ่มเติมได้"

Interpretation: Extension stays on the same PTW. Attached documents remain as-is but can be added to. No new forms needed.

Current code: Our Part 4 extension cards add to the existing PTW form. Documents can be attached via the attachment system.

Required changes: None.

Section 3 Summary

Item	Status	Issue
Surrender/re-issue concept	Remove — not used	—
Within-day extension	Confirmed, matches current code	—
Extension review: add WAO	Code change — 2→3 approvers, threshold 2→3	#508
Unlimited extensions	Confirmed, matches current code	—
Project duration extension	New feature — needs design	New
Code changes needed	Add WAO to extension review + new feature	—

Section 4: Closing a Job (Project-Level)

4.1 Who initiates "Close Job"?

Tester response:

"ผู้รับเหมาส่งคำขอ 'ปิดงาน' ผู้ที่จะอนุมัติการปิดงาน มี 3 ฝ่าย"

"4.1.1 เจ้าของงานมี check box บอกว่า 'ได้รับเอกสารโครงการครบถ้วน' จึงจะปิดงานได้"

"4.1.2 จป./เจ้าพื้นที่ สามารถกดปิดงาน/ส่งกลับแก้ไข"

Interpretation:

Contractor initiates "Close Job" (ขอปิดงาน)
3 parties approve the closure: WO, SO, Area Owner
Work Owner has a special pre-condition: checkbox "ได้รับเอกสารโครงการครบถ้วน" (Received all project documents completely) — must check before approving
SO / Area Owner can approve close or send back for correction (ส่งกลับแก้ไข)

Current code: The existing RequestClose flow in the workflow handles daily PTW closure, not project-level closure. Close Job (#509) is not yet implemented.

Required changes:

Implement project-level Close Job as a separate feature from daily PTW close
Add WO "documents received" checkbox as a pre-condition
SO/WAO can approve or send back

Follow-up questions: ~~(Answered — see F4–F6)~~

~~Is "Close Job" a menu button on the project, or a new workflow task?~~ → Both (PTW toolbar + task creation menu)
~~Does the contractor need to fill any form data?~~ → Referenced from MoM 20260227

4.2 What must be true before a job can be closed?

Tester response:

"ใบอนุญาตทำงานรายวันทั้งหมดถูกปิดแล้วไม่ PTW เปิดค้าง รายละเอียดตามข้อ 4.1.1"

Interpretation: All daily work permits must be closed — no open PTW remaining. Plus the WO document receipt checkbox from 4.1.1.

Current code: No validation exists to check for open PTWs at the project level.

Required changes:

Add backend validation: query all Work Permit tasks for the project, verify none are in active state (FillInPermitRequest, CoReview, WorkInProgress, ExtensionReview, RequestClose)
Block Close Job if any PTW is still open

4.3 Is there a final site inspection before closing the job?

Tester response:

"อยู่นอกระบบ"

Interpretation: Final site inspection happens outside the system. We don't need to build it.

Required changes: None.

4.4 Who gives the final sign-off to close the job?

Tester response:

"3 ฝ่ายตามข้อที่ผ่านมา"

Interpretation: Same 3 parties: WO + SO + Area Owner, consistent with all other approval steps.

Required changes: Close Job approval follows the same co-review pattern (AllRequired, 3 of 3).

4.5 After the job is closed, can it be reopened?

Tester response:

"ให้ system admin role back การปิดงานได้โดยยกเลิกข้อมูลการปิดงานที่ผ่านมา"

Interpretation: System admin can roll back the job closure by canceling previous closure data. Normal users cannot reopen.

Current code: No admin rollback capability exists for any workflow.

Required changes:

Implement admin rollback for Close Job (can be deferred to after core Close Job feature)
This is a P3 item

Section 4 — Tester Flow Diagram Analysis

The tester provided annotated flow diagrams (image4.png, image5.png, image7.png) that show the full lifecycle:

Daily cycle:
  Fill PTW → Review (3 parties) → PTW Active → Daily Close PTW
                                                      ↓
                                               Job Close PTW?
                                              No ↙        ↘ Yes
                                     (next day: new PTW)   Work Complete
                                                              ↓
                                                    ขอปิดงาน/ใบส่งมอบงาน
                                                    (Close Job / Delivery)
                                                              ↓
                                                        ตรวจสอบ/ตรวจรับ
                                                    (Review / Acceptance)
                                                              ↓
                                                     อนุมัติทั้ง 3 ส่วน?
                                                    (All 3 parties approve?)
                                                   No ↙            ↘ Yes
                                              (send back)        Approved

Additional elements from the diagrams:

"Print PTW ติดที่หน้างานพร้อม QR Code" — First work day: print PTW and post at work site with QR code
"รปภ. ตรวจบัตรก่อนเข้าพื้นที่" — Security checks cards before entering area (outside system)
"ประเมิน Safety หน้างาน / Safety Talk (if any)" — Safety evaluation at work site / Safety Talk (outside system)
"เข้าทำงานวันถัดไป ปรับเปลี่ยน PTW, JSA ตามรายละเอียดงานรายวัน / ระบุคนเข้างานจาก list" — Next day: contractor can modify PTW and JSA per daily work details, select workers from the registered list (same process as first day)
Doc IDs: Day 1 uses limited set; subsequent days can use all permit types [07, 08, 09, 10, 11, 12, 13, 14, 15]
"ขอขยายเวลาวันทำงานเพิ่ม" — Request additional working days (project-level extension)
"Work Report / As built drawing (if any)" — After close job, work report and as-built drawings may be submitted

Section 4 Summary

Item	Status	Issue
Close Job (project-level)	New feature to build	#509
Contractor initiates	Confirmed	—
3-party co-review	Matches existing pattern	—
WO "documents received" checkbox	New pre-condition	#509
All PTWs must be closed first	New validation rule	#509
Final inspection	Outside system — no build needed	—
Admin rollback	New admin feature (P3)	New
QR code on printed PTW	New (P3, nice-to-have)	New
Code changes needed	New Close Job feature + validations	—

Section 5: Evaluation After Work

5.1 Does evaluation happen after each daily permit or once when the whole job is closed?

Tester response:

"ครั้งเดียวเมื่อปิดงานทั้งหมด"

Interpretation: Once only, when the entire job is closed (project-level). Not after each daily permit.

Current code: Evaluation phase not built. This confirms it comes after Close Job.

5.2 Who evaluates?

Tester response:

"3 ฝ่าย เจ้าของงาน จป. เจ้าของพื้นที่"

Interpretation: All 3 parties: Work Owner, Safety Officer, Area Owner.

From the tester's flow diagram (image6.png), there are two separate evaluation tracks:

ประเมิน Contractor ด้านการทำงาน (Evaluate contractor — work performance)
ประเมิน Contractor ด้าน Safety (Evaluate contractor — safety)

These appear to be separate evaluation forms or sections, with Doc ID: 16 referenced.

5.3 Is the Vendor Evaluation Form II the actual form we should build?

Tester response:

"รอสอบถามพี่อ้อยพี่หมู"

Interpretation: Waiting to confirm with senior colleagues ("พี่อ้อย" and "พี่หมู"). The evaluation form is NOT confirmed yet.

Action: Follow up with the tester when they have an answer from their colleagues.

5.4 What happens with the evaluation score?

Tester response:

"เก็บไว้เพื่ออ้างอิงภายหลังตามรายผู้รับเหมา"

Interpretation: Stored for future reference per contractor. No automated impact on contractor selection — purely for record-keeping and audit.

5.5 Can this wait until after the core permit flow is working?

Tester response:

"ได้"

Interpretation: Yes — evaluation can wait. Focus on core permit flow first.

Section 5 Summary

Item	Status
When: once at job close	Confirmed
Who: 3 parties	Confirmed
Two tracks (work + safety)	Confirmed from diagram
Actual form	Pending — waiting for senior colleague input
Score usage	Record-keeping only
Priority	Deferred — can wait until core flow works
Code changes needed	None now

Section 6: Differences Between Permit Types

Updated 2026-03-09 — Section 6 answered by tester via xlsx file (#522 comment)

The tester provided a completed matrix showing which features differ per permit type:

Feature	General	Height	Hot Work	Confined	Chemical	High Volt	Radiation	Excavation (> 2m)
General approve process?	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Different approval process?	No	No	No	No	Yes	No	Yes	No
Extra forms needed?	No	Yes	No	Yes	Yes	Yes	Yes	No
Worker entry/exit time log?	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Fire watch / Confined watcher during work?	No	No	Yes	Yes	No	No	No	Yes
Gas testing / Gas detector / Oxygen alert required?	No	No	Yes	Yes	No	No	No	Yes
Different close-out checklist?	No	No	Yes	Yes	Yes	Yes	Yes	Yes
Additional PPE beyond standard?	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes

Key Findings

1. Worker Entry/Exit Time Log — ALL 8 Types

Previously thought to be Confined Space only (Gap #2). The tester confirmed all permit types require a worker entry/exit time log.

This means a new form field is needed — likely in Part 1 (worker table) or as a separate section. Each worker row would need entry time and exit time columns. See follow-up question F15 below.

2. Different Close-Out Checklist — 6 of 8 Types

All types except General Work and Work at Height have different close-out checklists. This means Part 5 inspection categories should be configurable per permit type, not hardcoded.

Template Setting Opportunity

The existing Template Setting feature currently manages checklist (Part 2) and PPE (Part 1) items. It could be extended to also manage close-out checklist (Part 5) items per permit type.

3. Different Approval Process — Chemical + Radiation

Two permit types have a different approval process. This needs follow-up — what exactly is different?

Follow-up questions:

#	Question
F9	Chemical / Radiation — approval process ต่างจาก General อย่างไร? มีผู้อนุมัติเพิ่ม? หรือขั้นตอนต่างกัน?

4. Extra Forms Needed — 5 Types

Height, Confined Space, Chemical, High Voltage, and Radiation need extra forms beyond the standard 5-part permit.

Follow-up questions:

#	Question
F10	แต่ละประเภทที่ต้องมี extra forms — ฟอร์มเพิ่มเติมมีอะไรบ้าง? (เช่น gas test record, crane checklist, radiation survey)
F11	ฟอร์มเพิ่มเติมเหล่านี้ ต้องอยู่ใน PTW เดียวกัน? หรือเป็นเอกสารแนบแยก?

5. Fire Watch / Confined Watcher — Hot Work, Confined, Excavation

These 3 types require a fire watch or confined space watcher during work.

Follow-up questions:

#	Question
F12	Fire watch / Confined watcher — ต้องบันทึกข้อมูลอะไรบ้าง? (ชื่อ, เวลาเริ่ม-สิ้นสุด, ผลตรวจ?)

6. Gas Testing / Gas Detector / Oxygen Alert — Hot Work, Confined, Excavation

These 3 types require gas testing, gas detector, or oxygen alert.

Follow-up questions:

#	Question
F13	Gas testing — ต้องบันทึกข้อมูลอะไรบ้าง? (ชนิดแก๊ส, ค่าที่วัดได้, เกณฑ์ผ่าน/ไม่ผ่าน?)
F14	ต้องมีการวัดก่อนเริ่มงาน (pre-entry)? ระหว่างงาน (continuous)? หรือทั้งสอง?

7. Worker Entry/Exit Time Log — Follow-up

Follow-up questions:

#	Question
F15	Worker entry/exit time log — ต้องบันทึกข้อมูลอะไรบ้าง? (ชื่อ, เวลาเข้า, เวลาออก, อื่นๆ?) อยู่ในส่วนไหนของฟอร์ม? (Part 1 worker table หรือแยกเป็น section ใหม่?)

8. Additional PPE — 7 of 8 Types

All types except General Work need additional PPE. This is already handled by the Template Setting feature — each permit type can configure its own PPE list.

Section 6 Summary

Item	Status	Impact
General approve process (all types Yes)	✅ Confirmed	No impact — all types share the same base process
Worker entry/exit log (all types)	⌛ Needs follow-up (F15)	Part 1 or new section
Close-out checklist (6 types differ)	▶️ Make configurable	Part 5 — extend Template Setting
Different approval (Chemical, Radiation)	⌛ Needs follow-up (F9)	Workflow engine
Extra forms (5 types)	⌛ Needs follow-up (F10–F11)	New form sections
Fire watch / Confined watcher (3 types)	⌛ Needs follow-up (F12)	New form field
Gas testing / Gas detector / Oxygen alert (3 types)	⌛ Needs follow-up (F13–F14)	New form field
Additional PPE (7 types)	🔧 Template Setting	Already supported

Complete Change Summary

Immediate Implementation (P1) — Clear Requirements

#	Change	Issue	Effort	Details
1	Remove 3-phase authorization — simplify Part 3 to 1 time range + 4 signatures	#506	Medium	Remove morning/afternoon/evening phases. Single date + start/end time + 4 signature grid
2	Rename "Supervisor" → "Work Owner" in all signature labels (Parts 3, 4, 5)	#506	Small	Display label change only. Keep model field names to avoid breaking changes
3	Add WAO to extension review — change from 2-party to 3-party approval	#508	Small	Backend: add WorkspaceOwner role + change threshold from 2→3
4	LOTO checkbox for Area Owner before PTW approval	New	Medium	All permit types, hard-block (Area Owner cannot approve without checking LOTO)

Next Implementation (P2) — Clarified (2026-03-09)

#	Change	Issue	Effort	Details
5	Close Job (project-level) — two entry points: PTW toolbar button ("ขอปิด Work + ขอปิดงาน") and task creation menu ("ขอปิดงาน")	#509	Large	PTW toolbar for last-day close; task menu when all PTWs already closed
6	WO "Documents Received" checkbox — pre-condition for Close Job	#509	Small	Blocking checkbox (hard requirement)
7	All-PTW-closed validation — prerequisite for Close Job via task menu	#509	Medium	Task menu entry only available when no PTW is open
8	Project Duration Extension — on PTW request page when project expired	New	Large	Contractor specifies days; WO can adjust; shows overdue indicator

Permit Type Variations (P2/P3) — Answered (2026-03-09)

#	Change	Types Affected	Effort	Follow-up
9	Worker entry/exit time log — new form field for ALL types	All 8	Medium	Follow-up F15
10	Configurable close-out checklist — Part 5 differs per type	6 of 8 (not General, Height)	Medium	Extend Template Setting
11	Fire watch / Confined watcher — new form fields	Hot Work, Confined, Excavation (> 2m)	Small	Follow-up F12
12	Gas testing / Gas detector / Oxygen alert — new form fields	Hot Work, Confined, Excavation (> 2m)	Medium	Follow-up F13–F14
13	Different approval process — workflow changes	Chemical, Radiation	Medium	Follow-up F9
14	Extra forms — additional sections per type	Height, Confined, Chemical, High Voltage, Radiation	Large	Follow-up F10–F11
15	Additional PPE — per type	7 of 8 (not General)	🔧	Already in Template Setting

Deferred (P3 / Future)

#	Change	Status
16	Admin rollback of Close Job	Confirmed needed, can wait
17	QR code on printed PTW	Nice-to-have from diagram
18	Evaluation phase (2 tracks)	Deferred per tester agreement
19	Vendor Evaluation Form	Pending senior colleague confirmation

Removed / Not Needed

#	Item	Reason
1	Surrender/re-issue concept	Tester: "คืออะไร??" — not a concept they use
2	"Controller" role/label	Not used in their organization
3	Final site inspection	"อยู่นอกระบบ" — outside the system
4	Lunch break pause	"ไม่" — not needed

Follow-Up Questions & Answers

Updated 2026-03-09 — F1–F8 answered by tester (#522 comment, #524 acknowledgement). F9–F15 (Section 6 type-specific details) still pending.

F1–F3: Project Duration Extension (from 3.1)

#	Question	Answer
F1	การต่ออายุโครงการ — ผู้รับเหมากดที่ไหน?	ในหน้าขอ PTW — when project is expired, show option to extend and specify days on the PTW request page
F2	ระบบจะเปลี่ยนวันสิ้นสุดโครงการด้วยหรือไม่?	Yes — add this section on the PTW request page to update project end date
F3	ควรมี indicator "เกินกำหนดเวลา" หรือไม่?	Yes — if past purchasing deadline, show overdue indicator

Tester's original answer:

"กรณีโครงการหมดอายุ ให้แจ้งผู้รับเหมาในหน้าขอ PTW ให้เลือกต่ออายุและระบุวัน (ไม่เกี่ยวกับวันที่ของจัดซื้อ)" "ให้เพิ่มส่วนนี้ในหน้าขอ PTW" "ถ้าเลยกำหนดของจัดซื้อให้แสดงด้วย"

Implementation notes:

Trigger point is the PTW request page — when the project is expired, the system notifies the contractor and allows them to request a project extension with specified number of days
Project end date should be updated upon approval
Overdue indicator should display when past the purchasing deadline

F4–F6: Close Job (from 4.1)

#	Question	Answer
F4	"ขอปิดงาน" — ปุ่มเมนูหรือ task ใหม่?	Both — see two entry points below
F5	ผู้รับเหมาต้องกรอกอะไร?	Referenced from MoM 20260227 (see images below)
F6	Work Report บังคับไหม?	Referenced from MoM 20260227

Tester's original answer:

"อ้างอิงคำตอบจาก MinuteOfMeeting 20260227"

The tester provided two annotated screenshots from the actual Safety App showing the intended UX:

After contractor submits PTW and it is returned approved, the PTW toolbar shows three action buttons:

Button	Thai Label	Description
Request Extension	ขอขยายเวลา	Within-day time extension (existing feature)
Close Work	ขอปิด Work	Daily PTW close only
Close Work + Close Job	ขอปิด Work + ขอปิดงาน	Daily PTW close AND project-level close job together

Approval flows:

ขอปิด Work (daily close): 3-party review → approve / send back for correction (ส่งกลับแก้ไข)
ขอปิด Work + ขอปิดงาน (close + close job): 3-party review → options: approve close work, approve all (อนุมัติทั้งหมด), send back for correction

Key Insight from Image 1

The tester annotated the PTW review toolbar (red arrow pointing to the command area) showing that extension, close work, and close job buttons should appear in the same toolbar area where current workflow commands are displayed. This means Close Job is integrated into the PTW workflow — not a separate workflow.

"ผู้รับเหมา: เพิ่มเมนู ขอปิดงาน ในเมนู สร้างงานจะขึ้น pop-up งาน เฉพาะงานที่ไม่มี PWT ค้าง"

The contractor can also initiate Close Job from the task creation menu ("+ สร้างงาน" button). This creates a popup showing the task — only available when no PTW is open for that project.

Key Insight from Image 2

The tester annotated the task creation popup (red arrow pointing to a new "ขอปิดงาน" menu item) showing it should appear alongside existing task types (การขอใบอนุญาตทำงาน, รายการเครื่องมือ, จัดเตรียม JSA, etc.). The label "เพิ่มเมนู ขอปิดงาน" confirms this is a new task type to add.

Summary — Two ways to close a job:

Scenario	Entry Point	Pre-condition
Last working day (closing today's PTW + closing the job)	PTW toolbar: "ขอปิด Work + ขอปิดงาน" button	PTW is in WorkInProgress state
After all PTWs are already closed	Task creation menu: "ขอปิดงาน"	No open PTWs for the project

F7–F8: LOTO Checkbox (from 2.3)

#	Question	Answer
F7	LOTO ต้องมีทุกประเภทใบอนุญาต?	Yes — required for all permit types
F8	ถ้าไม่ติ๊ก LOTO กดอนุมัติได้ไหม?	Hard-block — cannot approve without checking LOTO

Tester's original answer:

"Yes, Hard-block"

Implementation notes:

LOTO checkbox must appear for every PTW type (General, Hot Work, Confined Space, etc.)
Area Owner cannot submit approval until LOTO is checked — this is a hard-block, not a warning
Recommended approach: add LOTO checkbox to the approval confirmation dialog, visible only for Area Owner role, with the approve button disabled until checked

Updated Roadmap

Updated 2026-03-09 — F1–F8 answered. Phases A–C unblocked. F9–F15 (Section 6) still pending — blocks Phase D.

Phase	Items	Status	Blocked By
Done	#510, #505, #503, #507	✅	—
Phase A (P1)	#506 Part 3 simplification, signature label rename, #508 extension WAO	▶️ Ready	—
Phase B (P1)	LOTO checkbox for Area Owner — all permit types, hard-block	▶️ Ready	—
Phase C (P2)	#509 Close Job (two entry points: PTW toolbar + task menu), project duration extension (on PTW request page)	▶️ Ready	—
Phase D (Future)	Evaluation, permit type variations, QR code, admin rollback	🚧 Blocked	Section 5.3 pending senior colleague, F9–F15 pending tester response

Section 1: The Daily Permit Cycle​

1.1 Does someone fill out a new paper permit form every day?​

1.2 Or do they use the same permit for multiple days?​

1.3 If a job takes 5 days, how many paper permit forms are created?​

1.4 What time does a permit start and end?​

1.5 What happens during lunch break — does the permit pause?​

1.6 If work is not finished by end of day, what happens to the permit?​

Section 1 Summary​

Section 2: Who Signs the Permit (Authorization)​

2.1 Who is the "Requestor"?​

2.2 Who is the "Controller"?​

2.3 Who is the "Permit Issuer"?​

2.4 Are there really 3 time phases (morning/afternoon/evening)?​

2.5 If phases exist, do the same 3 people sign each phase?​

2.6 How many total signatures should one permit have?​

Section 2 Summary​

Section 3: Extension vs Surrender/Re-issue​

3.1 Are "extension" and "surrender/re-issue" the same thing?​

Type 1: Within-Day Time Extension (ขยายเวลา PTW ในวัน)​

Type 2: Project Duration Extension (ต่ออายุโครงการ)​

3.2 Or are they different processes?​

3.3 Who must approve an extension?​

3.4 Is there a maximum number of extensions per day?​

3.5 When extended, does the contractor need to fill any new forms?​

Section 3 Summary​

Section 4: Closing a Job (Project-Level)​

4.1 Who initiates "Close Job"?​

4.2 What must be true before a job can be closed?​

4.3 Is there a final site inspection before closing the job?​

4.4 Who gives the final sign-off to close the job?​

4.5 After the job is closed, can it be reopened?​

Section 4 — Tester Flow Diagram Analysis​

Section 4 Summary​

Section 5: Evaluation After Work​

5.1 Does evaluation happen after each daily permit or once when the whole job is closed?​

5.2 Who evaluates?​

5.3 Is the Vendor Evaluation Form II the actual form we should build?​

5.4 What happens with the evaluation score?​

5.5 Can this wait until after the core permit flow is working?​

Section 5 Summary​

Section 6: Differences Between Permit Types​

Key Findings​

1. Worker Entry/Exit Time Log — ALL 8 Types​

2. Different Close-Out Checklist — 6 of 8 Types​

3. Different Approval Process — Chemical + Radiation​

4. Extra Forms Needed — 5 Types​

5. Fire Watch / Confined Watcher — Hot Work, Confined, Excavation​

6. Gas Testing / Gas Detector / Oxygen Alert — Hot Work, Confined, Excavation​

7. Worker Entry/Exit Time Log — Follow-up​

8. Additional PPE — 7 of 8 Types​

Section 6 Summary​

Complete Change Summary​

Immediate Implementation (P1) — Clear Requirements​

Next Implementation (P2) — Clarified (2026-03-09)​

Permit Type Variations (P2/P3) — Answered (2026-03-09)​

Deferred (P3 / Future)​

Removed / Not Needed​

Follow-Up Questions & Answers​

F1–F3: Project Duration Extension (from 3.1)​

F4–F6: Close Job (from 4.1)​

Entry Point 1: PTW Toolbar Buttons (MoM item 7)​

Entry Point 2: Task Creation Menu (MoM item 8)​

F7–F8: LOTO Checkbox (from 2.3)​

Updated Roadmap​

Section 1: The Daily Permit Cycle

1.1 Does someone fill out a new paper permit form every day?

1.2 Or do they use the same permit for multiple days?

1.3 If a job takes 5 days, how many paper permit forms are created?

1.4 What time does a permit start and end?

1.5 What happens during lunch break — does the permit pause?

1.6 If work is not finished by end of day, what happens to the permit?

Section 1 Summary

Section 2: Who Signs the Permit (Authorization)

2.1 Who is the "Requestor"?

2.2 Who is the "Controller"?

2.3 Who is the "Permit Issuer"?

2.4 Are there really 3 time phases (morning/afternoon/evening)?

2.5 If phases exist, do the same 3 people sign each phase?

2.6 How many total signatures should one permit have?

Section 2 Summary

Section 3: Extension vs Surrender/Re-issue

3.1 Are "extension" and "surrender/re-issue" the same thing?

Type 1: Within-Day Time Extension (ขยายเวลา PTW ในวัน)

Type 2: Project Duration Extension (ต่ออายุโครงการ)

3.2 Or are they different processes?

3.3 Who must approve an extension?

3.4 Is there a maximum number of extensions per day?

3.5 When extended, does the contractor need to fill any new forms?

Section 3 Summary

Section 4: Closing a Job (Project-Level)

4.1 Who initiates "Close Job"?

4.2 What must be true before a job can be closed?

4.3 Is there a final site inspection before closing the job?

4.4 Who gives the final sign-off to close the job?

4.5 After the job is closed, can it be reopened?

Section 4 — Tester Flow Diagram Analysis

Section 4 Summary

Section 5: Evaluation After Work

5.1 Does evaluation happen after each daily permit or once when the whole job is closed?

5.2 Who evaluates?

5.3 Is the Vendor Evaluation Form II the actual form we should build?

5.4 What happens with the evaluation score?

5.5 Can this wait until after the core permit flow is working?

Section 5 Summary

Section 6: Differences Between Permit Types

Key Findings

1. Worker Entry/Exit Time Log — ALL 8 Types

2. Different Close-Out Checklist — 6 of 8 Types

3. Different Approval Process — Chemical + Radiation

4. Extra Forms Needed — 5 Types

5. Fire Watch / Confined Watcher — Hot Work, Confined, Excavation

6. Gas Testing / Gas Detector / Oxygen Alert — Hot Work, Confined, Excavation

7. Worker Entry/Exit Time Log — Follow-up

8. Additional PPE — 7 of 8 Types

Section 6 Summary

Complete Change Summary

Immediate Implementation (P1) — Clear Requirements

Next Implementation (P2) — Clarified (2026-03-09)

Permit Type Variations (P2/P3) — Answered (2026-03-09)

Deferred (P3 / Future)

Removed / Not Needed

Follow-Up Questions & Answers

F1–F3: Project Duration Extension (from 3.1)

F4–F6: Close Job (from 4.1)

Entry Point 1: PTW Toolbar Buttons (MoM item 7)

Entry Point 2: Task Creation Menu (MoM item 8)

F7–F8: LOTO Checkbox (from 2.3)

Updated Roadmap