การออกแบบเมทริกซ์สิทธิ์สำหรับเครื่องมือภายใน: บทบาทและขอบเขต

ปัญหาที่การออกแบบเมทริกซ์สิทธิ์จะแก้\n\nเครื่องมือภายในคือซอฟต์แวร์ที่ทีมของคุณใช้ในการขับเคลื่อนธุรกิจทุกวัน คิดถึงแผงผู้ดูแลระบบ แดชบอร์ดปฏิบัติการ คอนโซลช่วยเหลือ หน้าตรวจสอบการเงิน และแอปขนาดเล็กที่ช่วยคนอนุมัติงาน แก้ไขข้อมูล หรือโต้ตอบกับลูกค้า\n\nเครื่องมือเหล่านี้เกี่ยวข้องกับข้อมูลที่ละเอียดอ่อนและการกระทำที่มีพลัง ผู้ช่วยฝ่ายบริการอาจต้องดูโปรไฟล์ลูกค้าแต่ไม่ควรเห็นรายละเอียดการชำระเงินทั้งหมด ผู้ใช้ฝ่ายการเงินอาจส่งออกใบแจ้งหนี้แต่ไม่ควรแก้ไขการตั้งค่าบัญชี หัวหน้าฝ่ายปฏิบัติการอาจทำทั้งสองอย่างได้ แต่เฉพาะในภูมิภาคของตน\n\nสิทธิ์จะยุ่งเหยิงอย่างรวดเร็วเพราะเครื่องมือภายในเติบโตเป็นชั้น ๆ บทบาทใหม่ปรากฏ บทบาทเก่าแยกตัวออก และข้อยกเว้นแบบครั้งเดียวสะสม: “อนุญาตให้ Maria คืนเงินได้”, “บล็อกผู้รับจ้างจากการเขียนบันทึก”, “ให้หัวหน้าทีมอนุมัติได้สูงสุด $500 เท่านั้น” เมื่อกฎอยู่แค่ในหัวคน (หรือกระจัดกระจายในตั๋ว) หน้าจอและ endpoints ของ API จะเบี่ยงออกจากกัน และช่องโหว่ด้านความปลอดภัยจะเกิดขึ้น\n\nการออกแบบเมทริกซ์สิทธิ์แก้ปัญหานี้โดยการสร้างแผนที่ร่วมเดียวที่บอกว่าใครทำอะไรกับข้อมูลใด และภายใต้ข้อจำกัดแบบไหน มันกลายเป็นแหล่งข้อมูลจริงสำหรับการตัดสินใจทั้งใน UI (หน้าจอ ปุ่ม ฟิลด์ที่ปรากฏ) และฝั่งแบ็กเอนด์ (สิ่งที่เซิร์ฟเวอร์อนุญาตจริง แม้มีคนพยายามข้าม UI)\n\nมันไม่ได้มีไว้แค่สำหรับนักพัฒนา เมทริกซ์ที่ดีเป็นเอกสารการทำงานที่ฝ่ายผลิตภัณฑ์ ปฏิบัติการ และผู้สร้างตกลงร่วมกันได้ หากคุณสร้างด้วยแพลตฟอร์มแบบ no-code อย่าง AppMaster เมทริกซ์ยังคงจำเป็น: มันชี้แนะแนวทางการตั้งค่าบทบาท การนิยามทรัพยากร และการรักษาความสอดคล้องระหว่างหน้าจอที่มองเห็นได้กับ endpoints ที่ถูกสร้าง\n\nเมทริกซ์ง่าย ๆ จะช่วยให้คุณ:\n\n- ทำให้กฎชัดเจนก่อนสร้าง\n- ลดความยุ่งเหยิงจากกรณีพิเศษ\n- รักษาความสอดคล้องระหว่างสิทธิ์ UI และ API\n- ตรวจสอบการเปลี่ยนแปลงการเข้าถึงโดยไม่ต้องเดา\n\n## คำศัพท์สำคัญ: บทบาท ทรัพยากร การกระทำ ขอบเขต ข้อยกเว้น\n\nการออกแบบเมทริกซ์สิทธิ์ที่ดีเริ่มจากคำศัพท์ร่วมกัน ถ้าทีมใช้คำเหล่านี้เหมือนกัน คุณจะหลีกเลี่ยงกฎที่ยุ่งยากในภายหลัง\n\nบทบาท (role) คือกลุ่มคนตามงานที่มักต้องการการเข้าถึงแบบเดียวกัน คิดถึง Support, Finance, Ops หรือ Manager บทบาทควรอธิบายสิ่งที่คนทำในแต่ละวัน ไม่ใช่ระดับตำแหน่ง คนหนึ่งคนอาจมีมากกว่าหนึ่งบทบาทแต่ควรใช้ให้น้อย\n\nทรัพยากร (resource) คือสิ่งที่คุณปกป้อง ในเครื่องมือภายใน ทรัพยากรทั่วไปคือลูกค้า ตั๋ว ใบแจ้งหนี้ รายงาน การเชื่อมต่อ และการตั้งค่า ตั้งชื่อทรัพยากรเป็นคำนาม เพื่อช่วยตอนที่คุณแปลงกฎเป็นหน้าจอและ endpoints ของ API\n\nการกระทำ (action) คือสิ่งที่คนทำกับทรัพยากร รักษาคำกริยาให้สอดคล้องเพื่อให้เมทริกซ์อ่านง่าย การกระทำทั่วไปรวมถึง:\n\n- view\n- create\n- edit\n- delete\n- approve\n- export\n\nขอบเขต (scope) ตอบคำถามว่า “รายการไหนบ้าง?” โดยไม่ต้องสร้างบทบาทเพิ่ม ขอบเขตมักเป็นความต่างระหว่างการเข้าถึงที่ปลอดภัยกับไม่ปลอดภัย ขอบเขตทั่วไปคือ:\n\n- own (รายการที่คุณสร้างหรือถูกมอบหมาย)\n- team (กลุ่มของคุณ)\n- region (พื้นที่ของคุณ)\n- all (ทั้งหมด)\n\nข้อยกเว้น (exception) คือการยกเว้นที่ทำลายกฎปกติ ข้อยกเว้นอาจเป็นชั่วคราว (ครอบคลุมช่วงกะ), ระบุผู้ใช้ (ผู้เชี่ยวชาญต้องการการกระทำเพิ่มเติม) หรือระบุรายการ (ลูกค้าระดับ VIP ถูกล็อก) มองข้อยกเว้นเป็นหนี้ที่ควบคุมได้: ติดตามว่าใครอนุมัติ ทำไมถึงมี และเมื่อใดจะหมดอายุ\n\nตัวอย่าง: เจ้าหน้าที่ฝ่ายบริการอาจ “view tickets” ด้วยขอบเขต “team” แต่ได้ข้อยกเว้นชั่วคราวให้ “export tickets” เพื่อทบทวนเหตุการณ์ ในเครื่องมือที่สร้างด้วย AppMaster กฎแบบนี้จะจัดการได้ง่ายขึ้นถ้าคุณตั้งชื่อบทบาท ทรัพยากร การกระทำ และขอบเขตให้สอดคล้องตั้งแต่ต้น\n\n## การตัดสินใจก่อนวาดเมทริกซ์\n\nเริ่มด้วยการตกลงว่าคุณกำลังปกป้องอะไรจริง ๆ ให้ระบุพื้นที่ของเครื่องมือภายในเป็นทรัพยากร ไม่ใช่หน้าจอ หน้าจออาจแสดง “Orders”, “Refunds” และ “Customers” ในที่เดียว แต่เป็นทรัพยากรต่างกันและมีความเสี่ยงต่างกัน\n\nก่อนเขียนสิทธิ์ตัวเดียว ให้ทำให้คำกริยามาตรฐาน ความแตกต่างของคำเพียงเล็กน้อยจะสร้างกฎซ้ำซ้อน (edit vs update, remove vs delete, view vs read) เลือกชุดคำสั้น ๆ และใช้กับทุกทรัพยากร สำหรับเครื่องมือภายในส่วนใหญ่ ชุดง่าย ๆ เช่น view, create, update, delete, approve, export ก็เพียงพอ\n\nขอบเขตเป็นการตัดสินใจถัดไป และควรสอดคล้องกับแนวคิดองค์กรของคุณ ขอบเขตมากเกินไปทำให้เมทริกซ์อ่านไม่ออก น้อยเกินไปทำให้เกิดข้อยกเว้นบ่อยครั้ง ตั้งเป้าชุดเล็ก ๆ ที่เข้ากับโครงสร้างองค์กร เช่น:\n\n- own (รายการที่คุณสร้าง)\n- team (รายการของทีมคุณ)\n- location (สาขาหรือภูมิภาค)\n- all (ทั้งหมด)\n- none (ไม่มีการเข้าถึง)\n\nคุณยังต้องมีกฎชัดเจนสำหรับ “ไม่” ตัดสินใจว่าสิ่งใดถูกห้ามอย่างชัดเจนเทียบกับปฏิเสธโดยนัย ปฏิเสธโดยนัย (สิ่งที่ไม่ได้ระบุถือว่าปฏิเสธ) ปลอดภัยและเรียบง่ายกว่า การห้ามอย่างชัดเจนมีประโยชน์เมื่อคุณมีการเข้าถึงกว้างแต่ต้องการบล็อกการกระทำเฉพาะ เช่น “Finance เข้าถึงใบแจ้งหนี้ทั้งหมดได้ยกเว้นการลบ”\n\nสุดท้าย ให้ทำเครื่องหมายการกระทำที่ต้องคำนึงถึงเรื่องความสอดคล้องตั้งแต่แรก ก่อนที่มันจะจมอยู่ในกริด การส่งออก การลบ การจ่ายเงิน การเปลี่ยนบทบาท และการเข้าถึงข้อมูลส่วนบุคคลควรได้รับการพิจารณาเป็นพิเศษ มีการบันทึก และมักต้องมีขั้นตอนการอนุมัติ ตัวอย่าง: คุณอาจอนุญาตให้หัวหน้าฝ่ายบริการอัปเดตโปรไฟล์ลูกค้าได้ แต่ต้องมีการอนุมัติจากฝ่ายการเงินก่อนสร้างการจ่ายเงินหรือการส่งออก\n\nถ้าคุณสร้างใน AppMaster การตัดสินใจเหล่านี้จะแมปกับ endpoints ฝั่งแบ็กเอนด์และตรรกะ Business Process ในภายหลัง แต่เมทริกซ์ต้องชัดเจนก่อน\n\n## ขั้นตอนทีละข้อ: สร้างเมทริกซ์สิทธิ์ตั้งแต่ต้น\n\nเริ่มจากงานที่คนทำ ไม่ใช่หน้าจอที่คุณวางแผนจะสร้าง ถ้าเริ่มจากหน้าจอ คุณจะก็อปปี้ UI ของวันนี้และพลาดกฎจริง (เช่น ใครอนุมัติการคืนเงิน หรือใครแก้ไขบันทึกลูกค้าหลังถูกล็อก)\n\nวิธีง่าย ๆ ในการออกแบบเมทริกซ์คือถือมันเป็นแผนที่จากงานไปสู่การเข้าถึง แล้วแปลงเป็นแอปของคุณทีหลัง\n\n### ลำดับการสร้างที่ปฏิบัติได้\n\n1) เขียนรายการงานของธุรกิจด้วยภาษาธรรมดา ตัวอย่าง: “ออกใบคืนเงิน”, “เปลี่ยนอีเมลลูกค้า”, “ส่งออกใบแจ้งหนี้เดือนที่ผ่านมา” รักษาให้สั้นและจริง\n\n2) แปลงงานเป็นทรัพยากรและการกระทำ ทรัพยากรเป็นคำนาม (Invoice, Ticket, Customer), การกระทำเป็นคำกริยา (view, create, edit, approve, export) มอบเจ้าของให้แต่ละทรัพยากร: คนหนึ่งที่อธิบายกรณีขอบเขตและบอกว่า “ใช่ นั่นถูกต้อง”\n\n3) กำหนดบทบาทตามทีมที่มั่นคง ใช้กลุ่มเช่น Support, Finance, Operations, Team Lead หลีกเลี่ยงตำแหน่งที่เปลี่ยนบ่อย (Senior, Junior) เว้นแต่จริง ๆ แล้วเปลี่ยนการเข้าถึง\n\n4) เติมเมทริกซ์ด้วยการเข้าถึงขั้นต่ำที่แต่ละบทบาทต้องการเพื่อทำงานให้เสร็จ ถ้า Support ต้องดูใบแจ้งหนี้เพื่อช่วยลูกค้า อย่าให้สิทธิ์ “export” โดยดีฟอลต์ คุณเพิ่มการเข้าถึงได้ แต่การถอดสิทธิ์ภายหลังทำให้เกิดนิสัยที่ผิดพลาด\n\n5) เพิ่มขอบเขตเฉพาะที่จำเป็น แทนที่จะมีสิทธิ์ “edit” เดียว ให้ระบุขอบเขตเช่น “edit own”, “edit assigned”, หรือ “edit all” เพื่อให้กฎชัดเจนโดยไม่สร้างบทบาท 50 ตัว\n\nเก็บข้อยกเว้นในตารางแยก ไม่เทเป็นบันทึกย้อมภายในเมทริกซ์ ข้อยกเว้นแต่ละรายการต้องมีช่องเหตุผลชัดเจน (ความสอดคล้อง, ความเสี่ยงการฉ้อโกง, การแยกหน้าที่) และเจ้าของคนเดียวที่อนุมัติ\n\nเมื่องานนี้เสร็จ เครื่องมืออย่าง AppMaster จะทำให้ง่ายขึ้นในการแปลงเมทริกซ์เป็น endpoints ที่ป้องกันและหน้าจอแอดมินโดยไม่ต้องเดาระหว่างการสร้าง\n\n## วิธีจัดโครงสร้างเมทริกซ์ให้คงใช้ได้\n\nเมทริกซ์สิทธิ์มีประโยชน์เมื่อคนอ่านได้อย่างรวดเร็ว ถ้ามันกลายเป็นตารางเซลล์ยักษ์ ทีมจะหยุดใช้ และสิทธิ์จะเบี่ยงเบนจากที่ตั้งใจ\n\nเริ่มด้วยการแยกเมทริกซ์ตามโดเมน แทนที่จะใช้ชีตเดียวสำหรับทุกอย่าง ให้ใช้แท็บแยกตามพื้นที่ธุรกิจ เช่น Customers, Billing, Content บทบาทส่วนใหญ่จะเกี่ยวข้องกับโดเมนน้อย ๆ ดังนั้นวิธีนี้ช่วยให้การตรวจทานเร็วและลดความเปลี่ยนแปลงโดยไม่ได้ตั้งใจ\n\nใช้รูปแบบการตั้งชื่อที่สอดคล้องข้ามแท็บ รูปแบบง่าย ๆ เช่น Resource.Action.Scope ทำให้เห็นชัดว่าสิทธิ์แต่ละตัวหมายถึงอะไร และป้องกันการซ้ำที่ดูต่างกันแต่ความหมายเดียวกัน เช่น Invoice.Approve.Department อ่านเหมือนกับ Customer.Edit.Own\n\nเมื่อเจอกรณีขอบเขต ต้านความอยากสร้างบทบาทใหม่ ใส่หมายเหตุสั้น ๆ ข้างเซลล์เพื่ออธิบายข้อยกเว้นและเมื่อมันใช้ ตัวอย่าง: Support สามารถดูใบแจ้งหนี้ได้ แต่ต้องให้ลูกค้ายืนยันตัวตนก่อน หมายเหตุนั้นยังชี้ไปยังขั้นตอน UI เพิ่มเติมที่ต้องทำได้โดยไม่เปลี่ยนโมเดลบทบาท\n\nทำเครื่องหมายสิทธิ์ความเสี่ยงสูงให้เด่น เช่น การคืนเงิน การอนุมัติ การส่งออก และการลบข้อมูล ระบุเซลล์และเขียนว่าต้องตรวจสอบอะไรเพิ่มเติม เช่น การอนุมัติสองคนหรือการยืนยันเฉพาะผู้จัดการ\n\nเพื่อให้เมทริกซ์คงทนตามเวลา ให้เวอร์ชันมันเหมือนเอกสารจริง:\n\n- v1, v2, ฯลฯ พร้อมวันที่\n- เจ้าของ (คนรับผิดชอบหนึ่งคน)\n- สรุปการเปลี่ยนแปลงสั้น ๆ\n\nเมื่อเมทริกซ์เสถียร การสร้างหน้าจอและ endpoints ใน AppMaster จะง่ายขึ้น เพราะปุ่มและการกระทำของ API ทุกอย่างจะจับคู่กับชื่อสิทธิ์ที่ชัดเจน\n\n## แปลงเมทริกซ์เป็นหน้าจอและ endpoints\n\nเมทริกซ์สิทธิ์มีประโยชน์เมื่อมันกลายเป็นกฎจริงในสองที่: API และ UI เริ่มจากการถือว่าทรัพยากรแต่ละตัวในเมทริกซ์ (เช่น Tickets, Invoices, Users) เป็นกลุ่ม endpoint เก็บการกระทำให้สอดคล้องกับกริยาในเมทริกซ์: view, create, edit, approve, export, delete\n\nฝั่ง API ให้บังคับสิทธิ์ในทุกคำขอ การตรวจสอบใน UI ช่วยให้ชัดเจนแต่ไม่ใช่ความปลอดภัย ปุ่มที่ซ่อนอยู่ไม่หยุดคำขอ API โดยตรง\n\nวิธีง่าย ๆ ในการแปลงเมทริกซ์เป็นสิทธิ์ API คือการตั้งชื่อตามมาตรฐานและผูกที่จุด boundary ที่การกระทำเกิดขึ้น:\n\n- tickets:view, tickets:edit, tickets:export\n- invoices:view, invoices:approve, invoices:delete\n- users:view, users:invite\n\nแล้วใช้ชื่อสิทธิ์เดียวกันในการควบคุมการมองเห็น UI: เมนู หน้าถึง ปุ่ม และแม้แต่ฟิลด์ ตัวอย่าง: เจ้าหน้าที่ฝ่ายบริการอาจเห็นรายชื่อ Ticket และเปิดดู แต่ฟิลด์ “Refund” จะเป็นแบบอ่านอย่างเดียวจนกว่าจะมีสิทธิ์ invoices:approve\n\nระวังความแตกต่างระหว่างการเข้าถึงแบบรายการกับรายละเอียด ทีมมักต้องการ “เห็นว่ามีอะไรบ้าง” โดยไม่เห็นข้อมูลในเรกคอร์ดจริง นั่นหมายถึงคุณอาจอนุญาตผลลัพธ์รายการด้วยคอลัมน์จำกัด แต่บล็อกการเปิดดูรายละเอียดเว้นแต่ผู้ใช้มีสิทธิ์รายละเอียด (หรือผ่านการตรวจสอบขอบเขตเช่น “มอบหมายให้ฉัน”) ตัดสินใจเรื่องนี้ตั้งแต่ต้นเพื่อไม่สร้างหน้ารายการที่รั่วไหลข้อมูลละเอียดอ่อน\n\nสุดท้าย แมปการบันทึก audit เข้ากับการกระทำที่สำคัญ การส่งออก การลบ การอนุมัติ การเปลี่ยนบทบาท และการดาวน์โหลดข้อมูลควรสร้างเหตุการณ์ audit พร้อมใคร ทำอะไร เมื่อไร และเป้าหมาย หากสร้างใน AppMaster คุณสามารถสะท้อนสิ่งนี้ในตรรกะ endpoint และ Business Process เพื่อให้กฎเดียวกันทั้งเรียกการกระทำและสร้างรายการบันทึก\n\n## ความผิดพลาดและกับดักที่พบบ่อย\n\nวิธีที่เร็วที่สุดในการทำให้เมทริกซ์สิทธิ์พังคือการจำลอง UI แทนธุรกิจ หน้าจอหนึ่งอาจแสดงหลายสิ่ง สิ่งเดียวกันอาจปรากฏในหลายหน้าจอ ถ้าคุณถือว่าทุกหน้าจอเป็นทรัพยากรแยก คุณจะซ้ำกฎ พลาดกรณีขอบเขต และถกเถียงเรื่องการตั้งชื่อแทนการเข้าถึง\n\nกับดักอีกอย่างคือการเพิ่มบทบาทจนล้น ทีมมักเพิ่มบทบาท (Support Level 1, Support Level 2, Support Manager ฯลฯ) ในขณะที่ชุดบทบาทเล็ก ๆ พร้อมขอบเขตชัดเจนก็เพียงพอ ขอบเขตเช่น “own team”, “assigned region”, หรือ “accounts you manage” มักอธิบายความแตกต่างได้ดีกว่าบทบาทใหม่\n\nข้อผิดพลาดที่พบบ่อยในเครื่องมือภายในจริง ๆ ได้แก่:\n\n- นิยามแค่ “view” และ “edit” แต่ลืมการกระทำเช่น export, bulk edit, refund, impersonate, หรือ “change owner”.\n- ใช้ข้อยกเว้นเป็นแพตช์ระยะยาว การให้สิทธิ์ครั้งเดียวแบบชั่วคราวมักกลายเป็นถาวรและซ่อนโมเดลบทบาทที่ผิดพลาด\n- ซ่อนปุ่มใน UI แล้วคิดว่าปลอดภัย API ต้องปฏิเสธคำขอเช่นกัน แม้ผู้ใช้จะค้นพบ endpoint โดยตรง\n- ไม่ตัดสินใจว่าต้องเกิดอะไรเมื่อขอบเขตของใครสักคนเปลี่ยน เช่น ย้ายทีมหรือเปลี่ยนภูมิภาค สิทธิ์ควรอัปเดตอย่างคาดเดาได้ ไม่กระจัดกระจาย\n- ถือว่า “admin” คือไม่จำกัดโดยไม่มีกลไกควบคุม แม้แต่แอดมินก็อาจต้องแยก เช่น “จัดการผู้ใช้ได้” แต่ “ไม่สามารถอนุมัติการจ่ายเงิน”\n\nข้อยกเว้นต้องระวังเป็นพิเศษ มีประโยชน์สำหรับสถานการณ์ชั่วคราว แต่ต้องมีวันหมดอายุหรือทบทวน หากข้อยกเว้นเพิ่มขึ้นเรื่อย ๆ นั่นเป็นสัญญาณว่าบทบาทหรือขอบเขตไม่ได้แมปอย่างถูกต้อง\n\nตัวอย่างสั้น ๆ: ในเครื่องมือสำหรับ support และ finance Support ดูโปรไฟล์ลูกค้าและสร้างตั๋วได้ แต่ Finance ส่งออกใบแจ้งหนี้และออกคืนเงินได้ ถ้าคุณรักษาความปลอดภัยแค่หน้าจอ เจ้าหน้าที่ Support อาจเรียก endpoint การส่งออกโดยตรง ไม่ว่าคุณจะสร้างด้วยโค้ดเองหรือแพลตฟอร์มอย่าง AppMaster ที่สร้าง endpoints ฝั่งแบ็กเอนด์ กฎควรอยู่ที่เซิร์ฟเวอร์ ไม่ใช่แค่ใน UI\n\n## เช็คลิสต์ด่วนก่อนเริ่มสร้าง\n\nเมทริกซ์สิทธิ์มีประโยชน์เมื่อมันกลายเป็นกฎที่ชัดเจนและบังคับได้ ก่อนสร้างหน้าจอหรือ endpoint ตัวแรก ให้ทำเช็คลิสต์นี้เพื่อหลีกเลี่ยงการตั้งค่าที่ “เกือบปลอดภัย” ซึ่งพังเมื่อมีบทบาทหรือกรณีขอบเขตใหม่\n\n### สร้างกฎก่อน สร้าง UI\n\nเริ่มด้วยแนวคิดปฏิเสธโดยดีฟอลต์: สิ่งที่ไม่ได้อนุญาตถือว่าถูกบล็อก นี่เป็นฐานที่ปลอดภัยและป้องกันการเข้าถึงที่ไม่คาดคิดเมื่อเพิ่มฟีเจอร์ใหม่\n\nตรวจสอบว่าคุณมีแหล่งความจริงเดียวสำหรับสิทธิ์ ไม่ว่าจะเป็นเอกสาร ตารางในฐานข้อมูล หรือการตั้งค่า no-code ทุกคนในทีมควรรู้ว่ากฎปัจจุบันอยู่ที่ไหน ถ้า spreadsheet บอกอย่างหนึ่งและแอปบอกอีกอย่าง คุณจะส่งบัก\n\nเช็คลิสต์สั้น ๆ ก่อนสร้างที่ใช้ได้จริงสำหรับการออกแบบเมทริกซ์:\n\n- ปฏิเสธโดยดีฟอลต์ถูกบังคับทุกที่ (ปุ่ม UI, endpoints API, การส่งออก, งานพื้นหลัง)\n- แต่ละการกระทำมีคำนิยามขอบเขตชัดเจน (own record, team, region, all, หรือตัวอย่างย่อยที่ตั้งชื่อ)\n- ความสามารถของแอดมินแยกจากการกระทำทางธุรกิจ (การจัดการบทบาทไม่ใช่การ “อนุมัติคืนเงิน”)\n- การกระทำที่อ่อนไหวต้องการการควบคุมเข้มกว่า (ขั้นตอนอนุมัติ การบันทึก และควรมีการแจ้งเตือนสำหรับกิจกรรมผิดปกติ)\n- ข้อยกเว้นมีเจ้าของและวันหมดอายุ เพื่อไม่ให้ “การเข้าถึงชั่วคราว” กลายเป็นถาวร\n\nหลังจากนั้น ให้ตรวจตรากฎด้วยสถานการณ์จริงสั้น ๆ ตัวอย่าง: “เจ้าหน้าที่ Support ดูคำสั่งซื้อและเพิ่มโน้ตสำหรับภูมิภาคของตน แต่ไม่แก้ไขราคาและไม่ออกคืนเงิน Finance ออกคืนเงินได้เฉพาะหลังการอนุมัติจากผู้จัดการ และทุกการคืนเงินถูกบันทึก” ถ้าพูดไม่ออกภายในหนึ่งหรือสองประโยค ขอบเขตและข้อยกเว้นยังไม่ชัดพอ\n\nถ้าคุณสร้างใน AppMaster ให้มองรายการเหล่านี้เป็นข้อกำหนดทั้งสำหรับหน้าจอและตรรกะธุรกิจ ปุ่มอาจซ่อนการกระทำ แต่กฎฝั่งแบ็กเอนด์เท่านั้นที่บังคับจริง\n\n## ตัวอย่างสถานการณ์: เครื่องมือภายในสำหรับ support และ finance\n\nสมมติบริษัทขนาดกลางมีเครื่องมือภายในเดียวที่ใช้โดย Support และ Finance ฐานข้อมูลเดียวเก็บ Customers, Tickets, Refunds, Payouts และ Settings เล็ก ๆ (เช่น แม่แบบและการเชื่อมต่อ) นี่คือแอปชนิดที่การตรวจสอบแค่การล็อกอินไม่พอ\n\nบทบาทเริ่มต้นที่พวกเขาตกลงกันได้แก่:\n\n- Support Agent: ทำงานกับตั๋วในคิวหนึ่ง\n- Support Lead: ช่วยข้ามคิวและอนุมัติการกระทำบางอย่าง\n- Finance: จัดการงานที่เกี่ยวกับเงิน\n- Ops Admin: เป็นเจ้าของการควบคุมการเข้าถึงและการตั้งค่าระบบ\n\nการออกแบบเมทริกซ์ปฏิบัติเริ่มจากการเขียนการกระตุ้นต่อทรัพยากรก่อน แล้วค่อยคับด้วยขอบเขต\n\nสำหรับ Tickets, Support Agents ดูและอัปเดตสถานะตั๋วได้เฉพาะตั๋วในคิวที่มอบหมายให้พวกเขา พวกเขาสามารถเพิ่มโน้ตได้ แต่ไม่สามารถเปลี่ยนเจ้าของตั๋ว Support Leads ทำได้ทุกอย่างที่ Support Agent ทำได้ และยังย้ายตั๋วภายในภูมิภาคของตนได้\n\nสำหรับ Refunds, Finance สร้างและอนุมัติการคืนเงินได้ แต่มีขีดจำกัดจำนวนเงิน Support สามารถสร้างคำขอคืนเงินได้แต่ไม่สามารถอนุมัติได้ การอนุมัติคืนเงินเป็นการกระทำแยกต่างหากจากการสร้าง เพื่อให้มองเห็นในเมทริกซ์และไม่ถูกให้โดยไม่ตั้งใจ\n\nสำหรับ Payouts และ Settings เครื่องมือจะเข้มงวด: Finance เท่านั้นที่ดู Payouts ได้ และ Ops Admin เท่านั้นที่เปลี่ยน Settings Support ไม่เห็นหน้าจอเหล่านี้ เพื่อลดความผิดพลาด\n\nเพิ่มกฎข้อยกเว้น: Support Lead มาช่วยอีกภูมิภาคเป็นเวลา 2 สัปดาห์ แทนการให้บทบาทกว้าง ๆ อย่าง Ops Admin เมทริกซ์สามารถรวมการขยายขอบเขตชั่วคราว (Support Lead + Region B, หมดอายุในวันที่ระบุ) ข้อยกเว้นเดียวนี้ปลอดภัยกว่าการก็อปปี้สิทธิ์ระหว่างบทบาท\n\nถ้าสร้างใน AppMaster เมทริกซ์เดียวกันจะชี้ว่าเพจใดปรากฏใน UI และ endpoints ฝั่งแบ็กเอนด์อนุญาตอะไร เพื่อไม่ให้คนเข้าถึง Payouts หรือ Settings โดยเดา endpoint\n\n## วิธีทดสอบและดูแลสิทธิ์เมื่อเวลาผ่านไป\n\nสิทธิ์ล้มเหลวโดยวิธีเล็ก ๆ น่าเบื่อ: หน้าจอลืมซ่อนปุ่ม endpoint ลืมเช็ก ขอบเขตกว้างเกินไป เมทริกซ์สิทธิ์จะมีค่ามากขึ้นเมื่อคุณแปลงเป็นการทดสอบซ้ำได้และมีกระบวนการดูแลรักษาง่าย\n\nเริ่มด้วยชุดผู้ใช้ทดสอบเล็ก ๆ คุณไม่ต้องการบัญชีจำนวนมาก สร้างผู้ใช้หนึ่งบัญชีต่อบทบาท บวกหนึ่ง “ผู้ใช้ขอบ” สำหรับแต่ละข้อยกเว้นทั่วไป (เช่น “เจ้าหน้าที่ Support ที่มีสิทธิ์อนุมัติคืนเงิน”) เก็บบัญชีเหล่านี้ให้คงที่เพื่อให้ทีมใช้ซ้ำได้ทุกสปรินต์\n\nแล้วแปลงเมทริกซ์เป็นกรณีทดสอบ สำหรับแต่ละกฎ เขียนเส้นทาง “อนุญาต” หนึ่งทางและ “ปฏิเสธ” หนึ่งทาง ให้เส้นทางปฏิเสธชัดเจน (ควรเกิดอะไรขึ้น) เพื่อคนไม่มองข้าม\n\n- บทบาท: Support Agent. การกระทำ: Refund. คาดว่า: ปฏิเสธพร้อมข้อความชัดเจน ไม่มีข้อมูลเปลี่ยนแปลง\n- บทบาท: Finance. การกระทำ: Refund. คาดว่า: อนุญาต สร้างเรคอร์ดคืนเงิน บันทึกผู้กระทำและเหตุผล\n- บทบาท: Manager. การกระทำ: View tickets. ขอบเขต: team เท่านั้น. คาดว่า: ดูตั๋วทีมได้ แต่เปิดตั๋วทีมอื่นไม่ได้\n\nทดสอบกฎเดียวกันสองครั้ง: ใน UI และใน API ถ้า UI บล็อกการกระทำแต่ API ยังกระทำได้ ใครสักคนอาจข้ามหน้าจอได้ ถ้าสร้างด้วย AppMaster ให้เช็กว่าตรรกะ UI และ endpoints ฝั่งแบ็กเอนด์บังคับกฎทั้งคู่\n\nขอบเขตต้องมีข้อมูลจริงเพื่อทดสอบ สร้างเรคอร์ดทดสอบที่ต่างกันตามความเป็นเจ้าของ ทีม และภูมิภาค ยืนยันว่าคุณไม่สามารถเดา ID ของอีกขอบเขตแล้วเข้าถึงได้\n\nสุดท้าย ตัดสินใจว่าบันทึกอะไรสำหรับการกระทำที่อ่อนไหว (refunds, exports, role changes) บันทึกว่าใคร ทำอะไร เมื่อไร และจากไหน ทบทวนล็อกตามตารางเวลา และตั้งกฎแจ้งเตือนสำหรับการกระทำที่ควรหาได้ยาก เช่น การแก้สิทธิ์หรือการส่งออกเป็นกลุ่ม\n\n## ขั้นตอนถัดไป: จากเมทริกซ์สู่เครื่องมือภายในที่ใช้งานได้\n\nมองเมทริกซ์สิทธิ์เป็นแผนการสร้าง ไม่ใช่เอกสารเก็บไว้เอกสารเดียว วิธีที่เร็วที่สุดในการได้ประโยชน์คือยืนยันพื้นฐานกับคนที่เป็นเจ้าของข้อมูลและกระบวนการ\n\nเริ่มด้วยเวิร์กช็อทสั้น ๆ (30 นาทีพอ) มีตัวแทนจากแต่ละบทบาทบวก “เจ้าของทรัพยากร” (คนรับผิดชอบลูกค้า ใบแจ้งหนี้ การจ่ายเงิน ตั๋ว ฯลฯ) เดินผ่านบทบาท ทรัพยากร การกระทำ และขอบเขต แล้วจดข้อยกเว้นพิเศษ หากข้อยกเว้นดูบ่อย อาจเป็นขอบเขตที่ขาดหายไป\n\nร่างเมทริกซ์ v1 แล้วทบทวนกับเจ้าของทรัพยากร โฟกัสที่ปฏิบัติได้: “Support ดูใบแจ้งหนี้ได้ไหม?” “Finance แก้ไขรายละเอียดลูกค้าได้ไหม?” ถ้าใครลังเล จดกฎด้วยภาษาง่าย ๆ ก่อน คุณค่อยทำให้เป็นทางการทีหลัง\n\nเมื่อ v1 ตกลงกัน สร้างโดเมนหนึ่งแบบ end-to-end ก่อนขยาย เลือกชิ้นที่ทั้งเกี่ยวข้องข้อมูล ตรรกะ และ UI (เช่น: Ticketing หรือการอนุมัติ Invoice) คุณควรตอบได้ว่า: ใครเห็น ใครเปลี่ยน และเกิดอะไรเมื่อพยายาม\n\nถ้าใช้ AppMaster ให้แมปเมทริกซ์กับส่วนต่าง ๆ ของผลิตภัณฑ์ก่อนสร้างอะไร:\n\n- Data Designer: จัดทรัพยากรเป็นเอนทิตี (ตาราง) และฟิลด์คีย์ที่ส่งผลต่อขอบเขต (เช่น team_id, region_id)\n- Business Processes: บังคับกฎเมื่อการเปลี่ยนแปลงเกิดขึ้น (create, update, approve, export)\n- กฎการมองเห็น UI: ซ่อนการกระทำที่ผู้ใช้ทำไม่ได้ และแสดงข้อความอธิบายเมื่อถูกปฏิเสธ\n- Endpoints: เผยเฉพาะสิ่งที่แต่ละบทบาทต้องการ แยกการดำเนินการเฉพาะแอดมิน\n\nตัวอย่างง่าย: สร้างฟลว์ “ขอคืนเงิน” ด้วยสองบทบาท (Support สร้าง, Finance อนุมัติ) เมื่อทำงานได้สะอาดแล้ว คุณสามารถเพิ่มกรณีขอบเช่น “Support ยกเลิกได้เฉพาะภายใน 30 นาที”\n\nลองทำเครื่องมือภายในเล็ก ๆ ใน AppMaster เพื่อทดสอบบทบาทและฟลว์ตั้งแต่ต้น แล้ววนปรับจากเมทริกซ์ เป้าหมายคือจับความเข้าใจผิดก่อนที่คุณจะมี 20 หน้าจอและกองการแก้สิทธิ์