วิธีการลบบัญชีผู้ใช้ที่ไม่ได้ใช้งานใน Matrix Synapse ผ่าน Admin API

ใน Matrix Synapse มีความแตกต่างที่สำคัญระหว่างการลบบัญชีที่ไม่ใช้งานและการปิดใช้งานบัญชี API สำหรับผู้ดูแลระบบของ Synapse ที่ระบุไว้ในเอกสารนั้นไม่มีเอนด์พอยต์สำหรับการลบข้อมูลทั้งหมดอย่างถาวรซึ่งจะลบข้อมูลทั้งหมดในฐานข้อมูลที่เกี่ยวข้องกับผู้ใช้ ขั้นตอนการทำงานของผู้ดูแลระบบที่รองรับคือการระบุบัญชี ตรวจสอบบัญชี จากนั้นเรียกใช้เอนด์พอยต์สำหรับการปิดใช้งาน คุณสามารถตั้งค่าเพิ่มเติม"erase": trueเพื่อลบข้อมูลโปรไฟล์และทำเครื่องหมายผู้ใช้ว่าถูกลบแล้วได้

ดังนั้น ผลลัพธ์ที่ดีจึงไม่ใช่ “รหัสผู้ใช้หายไปจากตาราง Synapse ทุกตาราง” ผลลัพธ์ที่ดีคือ ผู้ใช้ไม่สามารถยืนยันตัวตนได้อีกต่อไป โทเค็นและอุปกรณ์ที่ใช้งานอยู่จะถูกลบออก บัญชีจะถูกนำออกจากห้องสนทนา ตัวระบุจากบุคคลที่สามจะถูกลบออก และหากนโยบายของคุณกำหนดไว้ โปรไฟล์จะถูกลบออก สื่อที่อัปโหลดและข้อความเก่าเป็นเรื่องแยกต่างหากและจะไม่ถูกลบโดยอัตโนมัติเมื่อบัญชีถูกปิดใช้งาน

คู่มือนี้ใช้เอกสารประกอบการใช้งาน Synapse Admin API ฉบับปัจจุบันที่เผยแพร่ในเดือนตุลาคม 2026 โปรดเปรียบเทียบตัวอย่างกับเอกสารประกอบการใช้งานสำหรับเวอร์ชัน Synapse ที่ทำงานอยู่บนโฮมเซิร์ฟเวอร์ของคุณเสมอ โดยเฉพาะอย่างยิ่งหากคุณใช้งานในระยะยาวหรือใช้บริการตรวจสอบสิทธิ์ Matrix Authentication Service เอกสารอ้างอิงที่เชื่อถือได้คือเอกสารประกอบการใช้งาน Synapse User Admin API , ภาพรวม Synapse Admin APIและ เอกสารประกอบการ ใช้งาน Synapse Media Admin API

คุณควรตั้งเป้าหมายไว้ที่ผลลัพธ์ใด?

ก่อนที่จะเปลี่ยนแปลงอะไร ให้กำหนดนโยบายการล้างข้อมูลก่อน “ไม่ใช้งาน” ไม่ใช่สถานะบัญชีของ Synapse แต่เป็นกฎที่คุณสร้างขึ้นจากฟิลด์ต่างๆ เช่นlast_seen_tsประเภทบัญชี สถานะการดูแลระบบ และบริบททางธุรกิจ

หากคุณไม่แน่ใจว่าบัญชีนั้นถูกทิ้งร้างหรือไม่ อย่าใช้last_seen_tsเกณฑ์เดียวในการพิจารณา บัญชีบริการ ผู้ใช้แอปพลิเคชัน ผู้ดูแลระบบฉุกเฉิน บอท บัญชีสนับสนุน และผู้ใช้ที่เชื่อมโยงกับ SSO อาจมีรูปแบบการเข้าสู่ระบบที่ผิดปกติ กระบวนการล้างข้อมูลที่น่าเชื่อถือควรมีรายการยกเว้นที่ชัดเจนและขั้นตอนการตรวจสอบ

ขั้นตอนที่ 1: แสดงรายชื่อผู้ใช้ในพื้นที่และรวบรวมข้อมูลกิจกรรม

การร้องขอผ่าน Admin API จำเป็นต้องใช้โทเค็นการเข้าถึงที่เป็นของผู้ดูแลระบบเซิร์ฟเวอร์ซึ่งแตกต่างจากการเป็นผู้ดูแลระบบห้องประชุม ควรส่งโทเค็นในAuthorization: Bearerส่วนหัว HTTP แทนที่จะใส่ไว้ใน URL หรือประวัติคำสั่งในเชลล์ หากเป็นไปได้

Synapse ระบุเอนด์พอยต์รายชื่อผู้ใช้ V3 ไว้ดังนี้:

GET /_synapse/admin/v3/users

คำขอพื้นฐานจะมีลักษณะดังนี้:

export SYNAPSE_URL="https://matrix.example.com"
export ADMIN_ACCESS_TOKEN="REDACTED"

curl -sS   -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN"   "$SYNAPSE_URL/_synapse/admin/v3/users?limit=100"

API รายชื่อผู้ใช้รองรับการแบ่งหน้า เมื่อการตอบกลับมีnext_tokenให้ร้องขอหน้าถัดไปโดยใช้ค่าดังกล่าวเป็นfromอย่าคิดว่าหน้าแรกแสดงถึงเซิร์ฟเวอร์ทั้งหมด

API นี้มีฟิลด์ที่มีประโยชน์สำหรับการตัดสินใจเกี่ยวกับการล้างข้อมูล รวมถึงว่าบัญชีนั้นเป็นผู้ดูแลระบบหรือไม่ ประเภทผู้ใช้ บัญชีนั้นถูกปิดใช้งานไปแล้วหรือยัง วันที่สร้างบัญชี และเวลาที่เข้าชมครั้งล่าสุด เอกสารระบุlast_seen_tsว่าคือ timestamp ของกิจกรรมล่าสุดของผู้ใช้ในหน่วยมิลลิวินาที นับตั้งแต่ยุค Unix

อะไรถือว่า "ไม่ใช้งาน"?

นโยบายทั่วไปคือ “ห้ามใช้งานเป็นเวลา 180 วัน” แต่ระยะเวลาที่เหมาะสมนั้นขึ้นอยู่กับสภาพแวดล้อม เซิร์ฟเวอร์ส่วนตัวขนาดเล็กอาจใช้งานได้นานถึง 90 วัน ในขณะที่มหาวิทยาลัย องค์กรตามฤดูกาล หรือบริการศิษย์เก่าอาจต้องการเวลา 365 วันขึ้นไป

ใช้การประทับเวลาตัดขอบแบบสัมบูรณ์แทนการเปรียบเทียบวันที่ที่จัดรูปแบบแล้ว ตัวอย่างเช่น งาน Python สามารถคำนวณค่าเกณฑ์ในหน่วยมิลลิวินาทีได้:

from datetime import datetime, timezone, timedelta

cutoff = datetime.now(timezone.utc) - timedelta(days=180)
cutoff_ms = int(cutoff.timestamp() * 1000)

จากนั้นให้พิจารณาว่าผู้ใช้ไม่ใช้งานก็ต่อเมื่อบัญชีนั้นใช้งานอยู่ ไม่ใช่บัญชีผู้ดูแลระบบ ไม่ได้รับการคุ้มครองโดยนโยบาย และlast_seen_tsมีอายุมากกว่าเกณฑ์ที่กำหนด

หากค่า "เห็นครั้งล่าสุด" หายไปหรือเป็นค่าว่าง ให้พิจารณาอย่างระมัดระวัง เพราะอาจหมายความว่าบัญชีนั้นไม่เคยสร้างข้อมูลกิจกรรมที่คุณคาดหวังไว้ ไม่ได้หมายความว่าปลอดภัยที่จะลบออกเสมอไป ตรวจสอบเวลาสร้างบัญชี ประเภทบัญชี การแมป SSO และความเป็นเจ้าของธุรกิจให้ละเอียดก่อนที่จะรวมบัญชีนั้นเข้าไป

ขั้นตอนที่ 2: สร้างรายชื่อผู้สมัครรับเลือกตั้งเนื่องจากไม่มีการใช้งาน ไม่ใช่รายชื่อที่จะถูกลบโดยอัตโนมัติ

คุณภาพของขั้นตอนนี้สำคัญกว่าความเร็วของการเรียกใช้ API เป้าหมายของคุณควรเป็นรายชื่อผู้สมัครที่ผ่านการตรวจสอบแล้ว ซึ่งมีเฉพาะบัญชีที่ปลอดภัยสำหรับการปิดใช้งานเท่านั้น

อย่างน้อยที่สุด ให้ยกเว้น:

• ผู้ดูแลระบบโฮมเซิร์ฟเวอร์;
• บัญชีบริการแอปพลิเคชันและบัญชีการผสานรวมที่รู้จัก;
• บอทและบัญชีสนับสนุนที่ถูกปิดใช้งานโดยเจตนา
• บัญชีฉุกเฉินหรือบัญชีที่ต้องแจ้งเหตุฉุกเฉินเมื่อเกิดเหตุการณ์ไม่คาดฝัน;
• บัญชีที่อยู่ในรายชื่อบัญชีที่ถูกระงับหรือได้รับการยกเว้นตามกฎหมาย
• ผู้ใช้ที่เพิ่งเปลี่ยนผู้ให้บริการยืนยันตัวตนหรือการแมปบัญชี
• ผู้ใช้ที่ถูกปิดใช้งานไปแล้ว เว้นแต่คุณกำลังตรวจสอบงานล้างข้อมูลที่ทำไว้ก่อนหน้านี้

ข้อมูลผู้สมัครอย่างง่ายควรประกอบด้วยรหัสผู้ใช้ Matrix last_seen_ts, เวลาที่สร้าง, สถานะผู้ดูแลระบบ, ประเภทบัญชี และเหตุผลที่ผ่านเกณฑ์การไม่ใช้งาน การเก็บหลักฐานนี้จะช่วยให้การตรวจสอบและการตัดสินใจย้อนกลับในภายหลังง่ายขึ้นมาก

คุณรู้ได้อย่างไรว่าการคัดเลือกผู้สมัครนั้นดีพอแล้ว?

สังเกตสัญญาณสามอย่างต่อไปนี้:

• ความสมบูรณ์:สคริปต์ของคุณได้ทำการแบ่งหน้าผ่านรายการผู้ใช้ในเครื่องทั้งหมดแล้ว
• ความสามารถในการอธิบาย:ผู้สมัครแต่ละคนมีเหตุผลที่ชัดเจน เช่น "ไม่พบเห็นครั้งล่าสุดเมื่อ 242 วันที่แล้ว ไม่ใช่ผู้ดูแลระบบ ไม่ใช่บัญชีบริการ"
• ความเสี่ยงต่อการแจ้งเตือนผิดพลาดต่ำ:บัญชีพิเศษและข้อยกเว้นทางธุรกิจได้รับการคัดกรองก่อนที่จะมีการโทรออกที่ก่อให้เกิดความเสียหายใดๆ

หากคุณไม่สามารถผ่านการตรวจสอบเหล่านั้นได้ ให้เปลี่ยนกระบวนการก่อนดำเนินการต่อไป ตัวอย่างเช่น เพิ่มขั้นตอนการอนุมัติจากมนุษย์ ส่งคำเตือนเกี่ยวกับการไม่ใช้งาน หรือเริ่มต้นด้วยการระงับแทนการปิดใช้งาน

ขั้นตอนที่ 3: ตรวจสอบแต่ละบัญชีก่อนปิดใช้งาน

สำหรับผู้ใช้ในพื้นที่เฉพาะรายหนึ่ง Synapse จะบันทึกข้อมูลดังต่อไปนี้:

GET /_synapse/admin/v2/users/<user_id>

ตัวอย่าง:

USER_ID="@olduser:example.com"

curl -sS   -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN"   "$SYNAPSE_URL/_synapse/admin/v2/users/$USER_ID"

การตอบสนองอาจรวมถึงสถานะการดูแลระบบของบัญชี สถานะการปิดใช้งานและการลบข้อมูล เวลาสร้างและเวลาเข้าใช้งานครั้งล่าสุด ข้อมูลประจำตัวภายนอก และตัวระบุจากบุคคลที่สาม จุดนี้เป็นจุดสำคัญที่จะต้องตรวจสอบให้แน่ใจว่าบัญชีดังกล่าวเป็นบัญชีที่คุณต้องการเปลี่ยนแปลง

ควรใช้ erase true หรือ erase false ดี?

ใช้"erase": falseเมื่อเป้าหมายในการดำเนินการคือการปิดการเข้าถึงโดยยังคงรักษาข้อมูลโปรไฟล์ไว้ ตามเอกสาร Synapse ปัจจุบัน การปิดใช้งานแบบปกติจะลบโทเค็นการเข้าถึงที่ใช้งานอยู่ แฮชรหัสผ่าน อุปกรณ์และคีย์การเข้ารหัสแบบ end-to-end ตัวแจ้งเตือน รหัสประจำตัวบุคคลที่สาม การเป็นสมาชิกห้อง ข้อมูลบัญชี คำเชิญที่รอดำเนินการ และข้อมูลความถูกต้องของบัญชีที่เกี่ยวข้อง

ใช้"erase": trueเมื่อนโยบายของคุณกำหนดให้ลบชื่อที่แสดง URL รูปประจำตัว ข้อมูลโปรไฟล์ที่กำหนดเอง และทำเครื่องหมายผู้ใช้ว่าถูกลบแล้ว การลบไม่ได้หมายความว่าข้อมูลประวัติทั้งหมดจะถูกทำลาย Synapse ระบุไว้อย่างชัดเจนว่าข้อความที่ส่งไปก่อนหน้านี้จะไม่ถูกลบโดย API นี้ และสื่อที่อัปโหลดก็จะไม่ถูกลบโดยอัตโนมัติเช่นกัน

ความแตกต่างนี้สำคัญมาก หากนโยบายของคุณกำหนดให้ลบเนื้อหามากกว่าแค่การลบโปรไฟล์ การปิดใช้งานบัญชีเพียงอย่างเดียวจึงไม่เพียงพอ

ขั้นตอนที่ 4: ทดลองเดินเครื่องเปล่า ปิดใช้งาน และตรวจสอบ

ก่อนดำเนินการเปลี่ยนแปลงใดๆ ให้บันทึกรหัสผู้ใช้สุดท้ายลงในไฟล์ข้อความธรรมดาหรือไฟล์ JSON แล้วตรวจสอบอีกครั้ง การทดสอบก่อนดำเนินการควรคงสถานะเดิมตลอดช่วงเวลาการเปลี่ยนแปลง: หากสคริปต์การสร้างรายชื่อผู้สมัครมีการเปลี่ยนแปลงในขณะที่คุณกำลังปิดใช้งานผู้ใช้ ให้หยุดและสร้างรายชื่อที่ได้รับการอนุมัติใหม่

สำหรับผู้ใช้ในพื้นที่ที่ได้รับอนุมัติแต่ละราย ให้เรียกใช้ปลายทางการปิดใช้งานที่ระบุไว้ในเอกสาร:

POST /_synapse/admin/v1/deactivate/<user_id>

ตัวอย่างที่ไม่ได้ลบข้อมูลโปรไฟล์:

curl -sS -X POST   -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN"   -H "Content-Type: application/json"   --data '{"erase": false}'   "$SYNAPSE_URL/_synapse/admin/v1/deactivate/@olduser:example.com"

ตัวอย่างการลบข้อมูลโปรไฟล์:

curl -sS -X POST   -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN"   -H "Content-Type: application/json"   --data '{"erase": true}'   "$SYNAPSE_URL/_synapse/admin/v1/deactivate/@olduser:example.com"

หลังจากนั้น ให้ตรวจสอบบัญชีอีกครั้ง:

curl -sS   -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN"   "$SYNAPSE_URL/_synapse/admin/v2/users/@olduser:example.com"

ผลลัพธ์การทำงานที่ประสบความสำเร็จควรแสดงให้เห็น"deactivated": trueหากคุณร้องขอการลบข้อมูล โปรดตรวจสอบด้วย"erased": trueอย่าใช้ "API ส่งคืน HTTP 2xx" เป็นเกณฑ์ความสำเร็จเพียงอย่างเดียว โปรดอ่านบันทึกผู้ใช้หลังจากทำการเปลี่ยนแปลงแล้ว

การปิดใช้งานจะลบอะไรออกไปบ้าง?

เอกสารประกอบการใช้งาน Synapse ฉบับปัจจุบันระบุผลกระทบหลายประการของการปิดใช้งาน ซึ่งรวมถึงการลบโทเค็นการเข้าถึงที่ใช้งานอยู่ ตัวระบุบุคคลที่สาม อุปกรณ์ คีย์การเข้ารหัสแบบ end-to-end ตัวส่งข้อมูล รหัสผ่านที่เข้ารหัส การเป็นสมาชิกห้องสนทนา คำเชิญที่รอดำเนินการ และข้อมูลบัญชี นอกจากนี้ยังลบผู้ใช้ออกจากไดเร็กทอรีผู้ใช้ด้วย

นอกจากนี้erase: trueSynapse ยังลบชื่อที่แสดง URL รูปประจำตัว ข้อมูลโปรไฟล์ที่กำหนดเอง และทำเครื่องหมายว่าบัญชีนั้นถูกลบแล้ว

Synapse ยังบันทึกรายการสำคัญบางอย่างที่ไม่ได้ถูกลบออกโดยการดำเนินการนี้ ซึ่งรวมถึงข้อความที่ส่งและรับ สื่อที่อัปโหลด การแมป SSO การประทับเวลาการสร้าง การยกเลิกข้อจำกัดอัตราการใช้งาน บันทึกผู้ใช้งานรายเดือน และข้อมูลการยินยอมบางส่วน รายการที่บันทึกไว้อาจไม่ครบถ้วนสมบูรณ์ ดังนั้นให้ถือว่าการปิดใช้งานเป็นการปิดบัญชี ไม่ใช่การลบข้อมูลทั้งหมด

คุณจำเป็นต้องลบไฟล์มีเดียที่ผู้ใช้อัปโหลดด้วยหรือไม่?

หากนโยบายการเก็บรักษาข้อมูลของคุณกำหนดให้ลบสื่อที่จัดเก็บไว้ในเครื่องซึ่งผู้ใช้ได้อัปโหลดไว้ Synapse มีเอนด์พอยต์แยกต่างหากให้ใช้งาน:

DELETE /_synapse/admin/v1/users/<user_id>/media

ตัวอย่าง:

curl -sS -X DELETE   -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN"   "$SYNAPSE_URL/_synapse/admin/v1/users/@olduser:example.com/media"

API สำหรับจัดการสื่อของผู้ใช้จะลบไฟล์มีเดียและภาพขนาดย่อที่จัดเก็บไว้ในคลังเก็บสื่อของ Synapse เอกสารระบุข้อจำกัดสองประการที่มีความสำคัญต่อการใช้งาน ประการแรก ไฟล์มีเดียที่จัดเก็บไว้ในคลังเก็บสื่อภายนอกจะไม่ได้รับผลกระทบจาก API นี้ ประการที่สอง หากคุณไม่ได้กำหนดข้อจำกัดไว้ ปลายทางจะลบไฟล์ 100 ไฟล์ต่อคำขอ ดังนั้นผู้ใช้ที่มีประวัติไฟล์มีเดียจำนวนมากอาจต้องเรียกใช้งานซ้ำหลายครั้ง

อย่าเพิ่มการลบสื่อโดยอัตโนมัติ เว้นแต่ว่านโยบายการเก็บรักษาข้อมูลของคุณจะกำหนดไว้ การลบสื่อโดยอัตโนมัตินั้นสร้างความเสียหายมากกว่าการปิดใช้งานบัญชี และอาจส่งผลกระทบต่อสื่อที่ยังคงถูกอ้างอิงอยู่ในห้องสนทนาเก่าๆ

ควรใช้ระบบกันสะเทือนแทนเมื่อใด?

Synapse ยังได้จัดทำเอกสารเกี่ยวกับ API สำหรับการระงับบัญชี การระงับบัญชีจะบล็อกกิจกรรมต่างๆ เช่น การส่งข้อความ การเข้าร่วมห้อง การส่งคำเชิญ การเปลี่ยนแปลงข้อมูลโปรไฟล์ และการปกปิดข้อมูลส่วนใหญ่ โดยมีเส้นทางการกู้คืนที่แตกต่างจากการปิดใช้งานบัญชี

การระงับบัญชี (Suspension) เหมาะกว่าเมื่อคุณต้องการระงับการใช้งานชั่วคราวเพื่อการยกเลิก เมื่อไม่แน่ชัดว่าบัญชีไม่ได้ใช้งานมานานเท่าใด หรือเมื่อการตรวจสอบการยกเลิกบัญชียังไม่เสร็จสิ้น ส่วนการปิดใช้งานบัญชี (Deactivation) เป็นตัวเลือกที่เหมาะสมกว่าเมื่อต้องการยุติการเข้าถึงและลบโทเค็น อุปกรณ์ สมาชิกห้องประชุม และข้อมูลบัญชีทั้งหมด

สำหรับการล้างข้อมูลอัตโนมัติ การกำหนดนโยบายเป็นขั้นตอนมักจะปลอดภัยกว่า:

1. ตั้งค่าสถานะบัญชีหลังจากไม่มีการใช้งานเกินระยะเวลาที่กำหนด
2. แจ้งหรือตรวจสอบ;
3. ระงับการใช้งานหากไม่แน่ใจในความเป็นเจ้าของ
4. ปิดใช้งานเฉพาะหลังจากระยะเวลาการเก็บรักษาหรือการอนุมัติผ่านพ้นไปแล้วเท่านั้น

คุณควรใช้ระบบอัตโนมัติในการล้างข้อมูลอย่างไรให้ปลอดภัย?

ควรแยกขั้นตอนการค้นหาและการปิดใช้งานออกจากกัน ขั้นตอนการค้นหาควรเป็นแบบอ่านอย่างเดียวและสร้างไฟล์ผู้สมัคร ส่วนขั้นตอนการดำเนินการควรใช้เฉพาะไฟล์ที่ได้รับการอนุมัติแล้ว และบันทึกสถานะคำขอและการตอบกลับทุกรายการ

ขั้นตอนการทำงานที่มีคุณภาพระดับการผลิตควรประกอบด้วย:

• ติดตามโทเค็นการแบ่งหน้าทั้งหมด;
• จำกัดอัตราการส่งคำขอจำนวนมาก แทนที่จะส่งคำขอหลายพันรายการพร้อมกัน
• โดยค่าเริ่มต้นจะไม่รวมผู้ดูแลระบบเซิร์ฟเวอร์และบัญชีบริการที่ระบุชื่อไว้
• บันทึกเวลาในรูปแบบ UTC;
• บันทึกเวอร์ชันนโยบายการล้างข้อมูลที่เลือกใช้สำหรับแต่ละบัญชี
• หยุดการทำงานเมื่อพบข้อผิดพลาดในการตรวจสอบสิทธิ์ การอนุญาต หรือข้อผิดพลาดของเซิร์ฟเวอร์ซ้ำๆ
• ตรวจสอบข้อมูลผู้ใช้แต่ละรายอีกครั้งหลังจากปิดใช้งานบัญชี
• อย่าเก็บโทเค็นการเข้าถึงของผู้ดูแลระบบไว้ในซอร์สโค้ดและบันทึกการทำงาน

หากการตรวจสอบหลังการเปลี่ยนแปลงไม่ตรงกับสถานะที่ร้องขอ อย่าดำเนินการต่อกับชุดข้อมูลที่เหลือโดยไม่ตรวจสอบ ให้ตรวจสอบความล้มเหลวครั้งแรกและพิจารณาว่าปัญหาเกิดจากสิทธิ์การเข้าถึง ความเข้ากันได้ของเวอร์ชัน API ปัญหาการกำหนดค่าพร็อกซี การผสานรวมบริการตรวจสอบสิทธิ์ Matrix หรือเงื่อนไขเฉพาะบัญชี

รายการตรวจสอบขั้นสุดท้าย

• ใช้โทเค็น Bearer สำหรับผู้ดูแลระบบเซิร์ฟเวอร์
• แสดงรายชื่อทุกหน้าของผู้ใช้ในระบบ ไม่ใช่แค่ 100 คนแรกเท่านั้น
• กำหนดนิยามของภาวะไม่เคลื่อนไหวด้วยเกณฑ์และข้อยกเว้นที่ระบุไว้เป็นลายลักษณ์อักษร
• ตรวจสอบบัญชีที่มีความเสี่ยงสูงทีละบัญชีก่อนดำเนินการใดๆ
• จัดทำและอนุมัติรายชื่อสำหรับการทดลองใช้งาน (dry-run list)
• ให้ใช้เอนด์พอยต์สำหรับการปิดใช้งานแทนที่จะสันนิษฐานว่า Synapse รองรับการลบบัญชีอย่างถาวร
• เลือกตัวเลือกนี้erase: trueเฉพาะเมื่อการลบโปรไฟล์เป็นส่วนหนึ่งของนโยบายเท่านั้น
• จัดการไฟล์มีเดียที่อัปโหลดแยกต่างหากเมื่อจำเป็น
• ตรวจสอบdeactivatedและทำซ้ำทุกครั้งerasedหลังการเปลี่ยนแปลง (หากจำเป็น)

วิธีการล้างข้อมูลที่น่าเชื่อถือที่สุดคือวิธีที่คุณสามารถอธิบายได้ในภายหลัง เช่น กฎการไม่ใช้งานใดที่เลือกบัญชีนั้น ข้อยกเว้นใดที่ถูกตรวจสอบ การดำเนินการ API ใดที่ถูกดำเนินการ และฟิลด์หลังการเปลี่ยนแปลงใดที่พิสูจน์สถานะที่ต้องการ มาตรฐานดังกล่าวมีประโยชน์มากกว่าการเพิ่มจำนวนบัญชีที่ประมวลผลในรอบเดียวให้มากที่สุด