ระบบการจัดการอสังหาริมทรัพย์สามารถมีข้อมูลลูกค้า, การจอง, กิจกรรมทางการเงิน, สัญญา, บันทึกการดำเนินงาน, บัญชีผู้ใช้, และข้อมูลอื่น ๆ ที่ไม่ควรเข้าถึงได้อย่างเท่าเทียมกัน โดยทุกคนหรือกระบวนการใด ๆ
ใครเป็นผู้รับผิดชอบด้านความปลอดภัยใน PMS ที่ใช้ Salesforce?
ความปลอดภัยในคลาวด์เป็นความรับผิดชอบร่วมกัน
Salesforce จัดเตรียมและดำเนินการแพลตฟอร์มคลาวด์พื้นฐานและ สถาปัตยกรรมความปลอดภัยพื้นฐานของมัน องค์กรที่ใช้แพลตฟอร์ม ยังคงกำหนดวิธีการจัดการผู้ใช้, สิทธิ์, ข้อมูล, การรวมระบบ, อุปกรณ์, กระบวนการทำงาน, และการกำหนดค่า
| พื้นที่ | การมีส่วนร่วมของแพลตฟอร์ม | ความรับผิดชอบของผู้ดำเนินการ |
|---|---|---|
| โครงสร้างพื้นฐานของแพลตฟอร์ม | Salesforce ดำเนินการและรักษาความปลอดภัยแพลตฟอร์มคลาวด์พื้นฐาน | ประเมินว่าแพลตฟอร์มและโมเดลบริการตรงตาม ความต้องการขององค์กรหรือไม่ |
| การเข้าถึงผู้ใช้ | อัตลักษณ์, การพิสูจน์ตัวตน, บทบาท, สิทธิ์, และความสามารถในการ ควบคุมการเข้าถึงที่เกี่ยวข้อง | ตัดสินใจว่าใครควรเข้าถึงและกำหนดสิทธิ์ อย่างเหมาะสม |
| ข้อมูล | การควบคุมแพลตฟอร์มสำหรับการจัดเก็บ, การเข้าถึง, และการปกป้อง ข้อมูล | ตัดสินใจว่าข้อมูลใดที่ถูกเก็บรักษา, แบ่งปัน, และเปิดเผย ต่อผู้ใช้หรือการรวมระบบแต่ละราย |
| แอปพลิเคชันและกระบวนการทำงาน | เครื่องมือสำหรับสิทธิ์, การทำงานอัตโนมัติ, การกำหนดค่า, และ การกำกับดูแล | ออกแบบและทดสอบกระบวนการทำงานเพื่อให้การดำเนินการที่ละเอียดอ่อน ถูกจัดการตามนโยบายขององค์กร |
| การปฏิบัติตามกฎระเบียบ | ความสามารถด้านความปลอดภัย, การตรวจสอบ, การกำหนดค่า, และการกำกับดูแล ที่สามารถสนับสนุนความต้องการในการปฏิบัติตามกฎระเบียบ | กำหนดกฎหมาย, นโยบาย, สัญญา, การควบคุม, เอกสาร, และขั้นตอนที่เกี่ยวข้อง |
ชั้นความปลอดภัยใดที่สำคัญในด้านการจัดการอสังหาริมทรัพย์?
ตรวจสอบว่าใครกำลังพยายามเข้าถึงสภาพแวดล้อมการดำเนินงาน
กำหนดว่าเรคคอร์ด, ฟิลด์, ฟังก์ชัน, และการดำเนินการใดที่ ผู้ใช้คนนั้นได้รับอนุญาตให้เข้าถึง
ใช้การควบคุมที่เหมาะสมกับข้อมูลที่ละเอียดอ่อน, เอกสาร, การรวมระบบ, และกระบวนการทำงาน
ตรวจสอบการเปลี่ยนแปลง, ตรวจสอบการเข้าถึง, รักษาข้อมูลการตรวจสอบที่เหมาะสม, และจัดการความปลอดภัยตลอดเวลา
PMS ควรควบคุมการเข้าถึงผู้ใช้ได้อย่างไร?
การพิสูจน์ตัวตนตอบคำถามแรก: ใครคือผู้ใช้? การอนุญาตตอบคำถามที่สอง: ผู้ใช้คนนั้นควรได้รับอนุญาตให้ทำอะไร?
Salesforce รองรับการพิสูจน์ตัวตนหลายปัจจัยและการควบคุมการเข้าถึงที่สามารถกำหนดค่าได้ ซึ่งอนุญาตให้ผู้ดูแลระบบจัดโครงสร้างการเข้าถึงตามความรับผิดชอบของผู้ใช้
ในด้านการจัดการอสังหาริมทรัพย์ ทีมต่าง ๆ อาจต้องการระดับการเข้าถึงที่แตกต่างกันมาก
- พนักงานต้อนรับและการจอง
- ทีมการเงินและบัญชี
- การทำความสะอาดและการดำเนินงาน
- บุคลากรบำรุงรักษา
- ทีมขายหรือการจัดการบัญชี
- ผู้จัดการอสังหาริมทรัพย์และพอร์ตโฟลิโอ
- ผู้ดูแลระบบระบบ
- ผู้ใช้ภายนอกหรือชั่วคราวตามที่ต้องการ
โมเดลความปลอดภัยจึงควรปฏิบัติตามหลักการในการให้ ผู้ใช้เข้าถึงที่จำเป็นในการทำงานโดยไม่เปิดเผยข้อมูลที่ไม่เกี่ยวข้อง เพียงเพราะมันมีอยู่ในระบบเดียวกัน
การจัดการสิทธิ์ที่ละเอียดอ่อนมีลักษณะอย่างไร?
ความปลอดภัยจะมีความเป็นจริงมากขึ้นเมื่อกฎการเข้าถึงสะท้อนถึง โมเดลการดำเนินงานแทนที่จะพึ่งพาประเภทผู้ใช้ที่กว้างเกินไปเพียงไม่กี่ประเภท
| ตัวอย่างบทบาท | อาจต้องการเข้าถึง | อาจไม่ต้องการเข้าถึง |
|---|---|---|
| พนักงานต้อนรับ | การจอง, ข้อมูลการมาถึง, รายละเอียดแขกที่ได้รับการอนุมัติ, สถานะห้อง | รายงานทางการเงินเต็มรูปแบบหรือการบริหารระบบ |
| การทำความสะอาด | ห้องที่ได้รับมอบหมาย, สถานะการทำความสะอาด, การตรวจสอบ, หมายเหตุการดำเนินงาน | ข้อมูลทางการเงินของลูกค้าที่ไม่เกี่ยวข้อง |
| การบำรุงรักษา | คำสั่งงาน, สินทรัพย์, ห้อง, สถานที่, รายละเอียดงาน | เรคคอร์ดการจองหรือการเงินที่ไม่เกี่ยวข้อง |
| การเงิน | ใบแจ้งหนี้, การชำระเงิน, ยอดคงเหลือ, ธุรกรรม, การปรับยอด | ข้อมูลการดำเนินงานที่ไม่จำเป็นสำหรับกระบวนการทำงานทางการเงิน |
| ผู้ดูแลระบบ | การกำหนดค่าระบบที่เหมาะสมกับความรับผิดชอบด้านการบริหาร | การเข้าถึงควรได้รับการควบคุม, ตรวจสอบ, และจำกัดเมื่อเหมาะสม |
ควรปกป้องข้อมูลอสังหาริมทรัพย์ที่ละเอียดอ่อนอย่างไร?
สภาพแวดล้อมการจัดการอสังหาริมทรัพย์สามารถมีหลายประเภทของ ข้อมูลที่ละเอียดอ่อน แต่ประเภทเหล่านั้นไม่ควรได้รับการจัดการในลักษณะเดียวกันโดยอัตโนมัติ
- ข้อมูลอัตลักษณ์ของลูกค้าหรือผู้อยู่อาศัย
- รายละเอียดการติดต่อ
- เรคคอร์ดการจองและการเข้าพัก
- ข้อมูลการเรียกเก็บเงินและธุรกรรม
- สัญญาและเอกสาร
- บันทึกการดำเนินงานและการเข้าถึง
- ข้อมูลพนักงาน
- ข้อมูลที่มีการควบคุมหรือข้อมูลที่เป็นความลับอื่น ๆ
การปกป้องข้อมูลควรพิจารณาความละเอียดอ่อนของข้อมูล, วิธีการใช้งาน, ใครต้องการเข้าถึง, มันเคลื่อนที่ไปที่ไหน, มันควรจะถูกเก็บรักษาไว้นานแค่ไหน, และการควบคุมความปลอดภัยใดที่เหมาะสม
Booking Ninjas ใช้ Salesforce เป็นแพลตฟอร์มพื้นฐาน, ทำให้บันทึกการดำเนินงานสามารถใช้ความปลอดภัยที่กว้างขึ้นของ Salesforce, สิทธิ์, การกำกับดูแล, และสถาปัตยกรรมข้อมูล
Salesforce Shield อยู่ที่ไหน?
องค์กรที่มีความต้องการด้านความปลอดภัย, การตรวจสอบ, หรือการปกป้องข้อมูลเพิ่มเติม อาจประเมินความสามารถของ Salesforce Shield
Shield อาจรวมถึงความสามารถเช่น การเข้ารหัสแพลตฟอร์ม, การตรวจสอบเหตุการณ์, เส้นทางการตรวจสอบฟิลด์, และเครื่องมือด้านความปลอดภัยอื่น ๆ ขึ้นอยู่กับผลิตภัณฑ์ Salesforce, รุ่น, และใบอนุญาตที่เกี่ยวข้อง
ความสามารถเหล่านี้ไม่ควรได้รับการอธิบายว่าเปิดใช้งานโดยอัตโนมัติ ในทุกสภาพแวดล้อมของ Salesforce หรือ Booking Ninjas
Booking Ninjas ยังมี Salesforce Shield เส้นทางความสามารถสำหรับองค์กรที่มีความต้องการด้านความปลอดภัยที่เรียกร้อง ให้มีการควบคุมเพิ่มเติมเหล่านี้
ทำไมการตรวจสอบและการตรวจสอบจึงสำคัญ?
การป้องกันการเข้าถึงที่ไม่ได้รับอนุญาตเป็นเพียงส่วนหนึ่งของความปลอดภัย. องค์กรยังต้องการการมองเห็นที่เหมาะสมเกี่ยวกับการเปลี่ยนแปลง, กิจกรรม, สิทธิ์, และข้อยกเว้น
ขึ้นอยู่กับการกำหนดค่าแพลตฟอร์มและความสามารถที่ได้รับใบอนุญาต, สิ่งนี้อาจรวมถึงข้อมูลเกี่ยวกับ:
- การเปลี่ยนแปลงในเรคคอร์ดที่สำคัญ
- กิจกรรมของผู้ใช้และผู้ดูแลระบบ
- การเปลี่ยนแปลงสิทธิ์
- รูปแบบการเข้าถึงข้อมูล
- นโยบายหรือข้อยกเว้นกระบวนการทำงาน
- เหตุการณ์ที่เกี่ยวข้องกับความปลอดภัย
ข้อมูลการตรวจสอบสามารถสนับสนุนการตรวจสอบ, การกำกับดูแลภายใน, การตรวจสอบการเข้าถึง, การควบคุมการดำเนินงาน, และกระบวนการปฏิบัติตามกฎระเบียบบางอย่าง
การมีอยู่ของบันทึกการตรวจสอบไม่ได้แทนที่ความจำเป็นในการตัดสินใจ ว่าควรตรวจสอบอะไร, ใครควรตรวจสอบ, และควรมีการตอบสนองอย่างไรเมื่อพบปัญหา
PMS ที่ใช้ Salesforce ทำให้องค์กรปฏิบัติตามกฎระเบียบหรือไม่?
ไม่ การปฏิบัติตามกฎระเบียบขึ้นอยู่กับมากกว่าซอฟต์แวร์ แพลตฟอร์ม.
ผู้ดำเนินการอสังหาริมทรัพย์อาจต้องพิจารณาถึงความเป็นส่วนตัว การชำระเงิน, การจ้างงาน การเงิน การเข้าถึง ที่อยู่อาศัย การบริการ หรือ ข้อกำหนดเฉพาะภาคส่วนขึ้นอยู่กับสถานที่และรูปแบบธุรกิจของตน.
เทคโนโลยีสามารถให้การควบคุมที่สนับสนุนข้อกำหนดเหล่านั้น แต่ องค์กรยังต้องกำหนดว่าข้อผูกพันใดบ้างที่ใช้บังคับ และนโยบาย ขั้นตอน สัญญา ผู้ใช้ การรวมระบบ กฎการเก็บรักษา และแนวทางปฏิบัติในการดำเนินงานควรออกแบบอย่างไร.
| ข้อกังวลด้านการปฏิบัติตาม | เทคโนโลยีสามารถสนับสนุน | องค์กรต้องกำหนด |
|---|---|---|
| ความเป็นส่วนตัว | การควบคุมการเข้าถึง การจัดการบันทึก เวิร์กโฟลว์ การตรวจสอบ, การจัดการข้อมูล. | ฐานทางกฎหมาย การแจ้งเตือน ข้อกำหนดการยินยอม การเก็บรักษา, สิทธิของบุคคล และเขตอำนาจศาล. |
| การกำกับดูแลการเข้าถึง | บทบาท สิทธิ์ การตรวจสอบ การติดตาม เวิร์กโฟลว์การอนุมัติ . | ใครควรมีสิทธิ์เข้าถึง ทำไม นานแค่ไหน และการเข้าถึงจะ ถูกตรวจสอบอย่างไร. |
| การเก็บรักษาบันทึก | บันทึกที่มีโครงสร้าง ประวัติ เวิร์กโฟลว์ และกระบวนการ การเก็บรักษาที่กำหนดค่าได้. | บันทึกใดบ้างที่ต้องเก็บรักษาหรือถูกลบและเป็นระยะเวลาใด. |
| การชำระเงิน | การเชื่อมต่อกับเวิร์กโฟลว์การชำระเงินและผู้ให้บริการการชำระเงินที่เหมาะสม. | สถาปัตยกรรมการชำระเงิน ความรับผิดชอบของผู้ให้บริการ ขอบเขต และ ข้อกำหนดด้านความปลอดภัยในการชำระเงินที่ใช้บังคับ. |
| การกำกับดูแลภายใน | นโยบาย การอนุมัติ บันทึกการตรวจสอบ แดชบอร์ด และ เวิร์กโฟลว์ที่มีโครงสร้าง. | นโยบายใดบ้างที่ใช้บังคับ ใครเป็นเจ้าของ และจัดการข้อยกเว้นอย่างไร. |
ข้อกำหนดการปฏิบัติตามจะกลายเป็นเวิร์กโฟลว์การดำเนินงานได้อย่างไร?
นโยบายจะมีประโยชน์มากขึ้นเมื่อข้อกำหนดของมันสามารถสะท้อนใน งานที่ผู้คนทำจริงๆ.
ขึ้นอยู่กับกรณีการใช้งาน องค์กรอาจต้องการเวิร์กโฟลว์สำหรับ การอนุมัติ การตรวจสอบเป็นระยะ การรับรอง การเพิ่มระดับ, เอกสาร การเปลี่ยนแปลงการเข้าถึง หรือกิจกรรมการกำกับดูแลอื่นๆ.
Booking Ninjas' การจัดการนโยบาย ให้สภาพแวดล้อมที่เป็น Salesforce-native สำหรับการสร้าง การติดตาม, การตรวจสอบ และการรายงานเกี่ยวกับนโยบายขององค์กรและ เวิร์กโฟลว์การกำกับดูแลที่เกี่ยวข้อง.
สิ่งนี้สามารถช่วยเชื่อมโยงบันทึกนโยบายกับกระบวนการดำเนินงาน แต่ องค์กรยังคงมีความรับผิดชอบในการกำหนดว่านโยบายเองนั้น ตรงตามข้อกำหนดทางกฎหมาย กฎระเบียบ สัญญา หรือภายในหรือไม่.
แนวคิดการไม่ไว้วางใจอยู่ที่ไหน?
โมเดลความปลอดภัยที่มีประโยชน์ไม่ถือว่าผู้ใช้ควรมี สิทธิ์เข้าถึงอย่างกว้างขวางเพียงเพราะพวกเขาเข้าสู่ระบบได้สำเร็จ.
อัตลักษณ์ บทบาท เงื่อนไข สิทธิ์ ความไวของข้อมูล และ การกระทำที่พยายามทำสามารถมีความสำคัญเมื่อกำหนดการเข้าถึง.
Booking Ninjas' ความปลอดภัยแบบ Zero Trust ความสามารถขยายแนวทางการกำกับดูแลนี้เกี่ยวกับอัตลักษณ์, การเข้าถึง การตรวจสอบ และนโยบายด้านความปลอดภัย.
การรวมระบบเปลี่ยนขอบเขตความปลอดภัยได้อย่างไร?
การดำเนินงานของอสังหาริมทรัพย์มักจะไม่อยู่ในแอปพลิเคชันเดียว. องค์กรอาจเชื่อมต่อผู้ให้บริการการชำระเงิน ซอฟต์แวร์บัญชี, ระบบควบคุมการเข้าถึง แพลตฟอร์มการจัดจำหน่าย แอปพลิเคชันการสื่อสาร, ระบบ ERP ผู้ให้บริการอัตลักษณ์ หรือบริการอื่นๆ.
การรวมระบบแต่ละอย่างนำคำถามเกี่ยวกับ:
- ข้อมูลใดบ้างที่ออกจากแต่ละระบบ
- ระบบใดเป็นเจ้าของบันทึกที่เกิดขึ้น
- การตรวจสอบถูกจัดการอย่างไร
- สิทธิ์ใดบ้างที่การรวมระบบได้รับ
- ข้อมูลประจำตัวและความลับถูกจัดการอย่างไร
- เกิดอะไรขึ้นเมื่อการเชื่อมต่อล้มเหลว
- การกระทำใดบ้างที่สามารถทำได้โดยอัตโนมัติ
- กิจกรรมใดบ้างที่ควรบันทึกหรือทบทวน
Booking Ninjas สนับสนุนการเชื่อมต่อภายนอกผ่าน การรวมระบบ ชั้น. โมเดลความปลอดภัยควรพิจารณาทั้ง Booking Ninjas และ แอปพลิเคชันภายนอกที่มีส่วนร่วมในแต่ละการไหลของข้อมูล.
ความปลอดภัยควรเปลี่ยนแปลงอย่างไรเมื่อพอร์ตโฟลิโออสังหาริมทรัพย์เติบโต?
การเติบโตเพิ่มมากกว่าผู้ใช้ องค์กรที่ใหญ่ขึ้นอาจนำเสนอ อสังหาริมทรัพย์ แผนก หน่วยงานทางกฎหมาย ผู้ดูแลระบบ, การรวมระบบ ผู้ขาย เขตอำนาจข้อมูล และนโยบายการดำเนินงานเพิ่มเติม.
ดังนั้นโมเดลความปลอดภัยจึงต้องขยายตัวในเชิงโครงสร้าง.
ตัวอย่างเช่น องค์กรอาจต้องแยกแยะระหว่างการเข้าถึง :
- อสังหาริมทรัพย์หนึ่งแห่งและพอร์ตโฟลิโอทั้งหมด
- การดำเนินงานในท้องถิ่นและการจัดการของบริษัท
- บันทึกการดำเนินงานและการเงิน
- การบริหารจัดการมาตรฐานและสิทธิพิเศษ
- ผู้ใช้ภายในและพันธมิตรภายนอก
- ข้อมูลระดับภูมิภาคหรือหน่วยธุรกิจ
สถาปัตยกรรม Salesforce-native ให้แพลตฟอร์มที่กำหนดค่าได้สำหรับ การจัดโครงสร้างความสัมพันธ์ สิทธิ์ และเวิร์กโฟลว์เหล่านี้. ข้อกำหนดเพิ่มเติมยังต้องได้รับการออกแบบและทดสอบเมื่อองค์กร ขยายตัว.
คุณควรประเมินอะไรบ้างก่อนเลือก PMS ที่ปลอดภัย?
- ระบุข้อมูลที่ละเอียดอ่อน. ทำความเข้าใจลูกค้า การเงิน การดำเนินงาน พนักงาน, สัญญา และข้อมูลอื่นๆ ที่ระบบจะมีอยู่.
- กำหนดบทบาทของผู้ใช้. กำหนดว่าทีมใดต้องการเข้าถึงบันทึกและฟังก์ชันใดบ้าง.
- กำหนดข้อกำหนดการปฏิบัติตามของคุณ. ระบุข้อผูกพันทางกฎหมาย กฎระเบียบ สัญญา และภายในที่เกี่ยวข้อง แทนที่จะสมมติว่าซอฟต์แวร์กำหนดข้อกำหนดเหล่านั้น.
- ตรวจสอบโมเดลความปลอดภัยของแพลตฟอร์ม. ทำความเข้าใจการตรวจสอบ สิทธิ์ การกำกับดูแล การติดตาม, ตัวเลือกการเข้ารหัส ความสามารถในการตรวจสอบ และการควบคุม การบริหาร.
- ตรวจสอบการรวมระบบ. รวมระบบภายนอกและการไหลของข้อมูลในการประเมินความปลอดภัย.
- วางแผนการกำกับดูแลอย่างต่อเนื่อง. กำหนดการตรวจสอบการเข้าถึง ความเป็นเจ้าของการกำหนดค่า ขั้นตอน เหตุการณ์ การตรวจสอบนโยบาย การฝึกอบรมพนักงาน และการติดตามหลัง การเปิดตัว.
Booking Ninjas ใช้ Salesforce สำหรับความปลอดภัยและการกำกับดูแลอย่างไร?
Booking Ninjas เป็น แพลตฟอร์ม Salesforce-native สำหรับการจองและการดำเนินงาน . แทนที่จะรักษาการดำเนินงานของอสังหาริมทรัพย์บนชั้นแอปพลิเคชันที่ไม่เกี่ยวข้อง, Booking Ninjas ใช้ Salesforce เป็นฐานแพลตฟอร์มที่กว้างขึ้น.
สิ่งนี้ช่วยให้การจอง ลูกค้า กิจกรรมทางการเงิน เวิร์กโฟลว์, บันทึกการดำเนินงาน รายงาน และกระบวนการที่กำหนดค่าอื่นๆ สามารถ ดำเนินการภายในสภาพแวดล้อมที่กว้างขึ้นเดียวกันกับอัตลักษณ์ของ Salesforce, สิทธิ์ การกำกับดูแล อัตโนมัติ และการควบคุมด้านความปลอดภัย.
ดังนั้น ฐานของ Salesforce จึงเป็นส่วนหนึ่งของสถาปัตยกรรมความปลอดภัยแทนที่จะเป็นเพียง การรวม CRM ภายนอก.
เชื่อมโยงการจองและการดำเนินงานกับสิทธิ์ของ Salesforce, การกำกับดูแล อัตโนมัติ การรายงาน และความปลอดภัยของแพลตฟอร์ม.
สำรวจ Salesforce →เพิ่มการเข้ารหัส การติดตาม การตรวจสอบ และการป้องกันข้อมูลที่ใช้บังคับ ความสามารถที่จำเป็นซึ่ง Salesforce ใบอนุญาตและการกำหนดค่ารองรับ.
สำรวจ Salesforce Shield →เชื่อมโยงการสร้างนโยบาย การตรวจสอบ การรับรอง การกำกับดูแล, และการรายงานกับเวิร์กโฟลว์การดำเนินงาน.
สำรวจการจัดการนโยบาย →จัดโครงสร้างการเข้าถึงและการตรวจสอบรอบๆ อัตลักษณ์ สิทธิ์, การตรวจสอบ และการกำกับดูแล.
สำรวจความปลอดภัยแบบ Zero Trust →เชื่อมโยงระบบภายนอกในขณะที่กำหนดข้อมูล, การตรวจสอบ สิทธิ์ และเวิร์กโฟลว์ที่เกี่ยวข้อง.
สำรวจการรวมระบบ →ใช้โมเดลการดำเนินงานแบบ Salesforce-native กับการจอง, แขก การชำระเงิน เวิร์กโฟลว์อสังหาริมทรัพย์ และการรายงาน.
สำรวจการบริการ →คำถามที่พบบ่อย
Salesforce-native PMS โดยอัตโนมัติปลอดภัยหรือไม่?
ไม่มีแพลตฟอร์มใดที่ทำให้องค์กรปลอดภัยโดยอัตโนมัติ Salesforce ให้รากฐานความปลอดภัยของคลาวด์ระดับองค์กรและ การควบคุมความปลอดภัยที่สามารถกำหนดค่าได้ ขณะที่องค์กรยังคง รับผิดชอบในด้านต่าง ๆ เช่น ผู้ใช้ สิทธิ์ ข้อมูล, การกำหนดค่า การรวมระบบ อุปกรณ์ และแนวปฏิบัติด้านความปลอดภัย การดำเนินงาน
Salesforce-native PMS โดยอัตโนมัติทำให้ธุรกิจเป็นไปตาม GDPR หรือ CCPA หรือไม่?
ไม่ เทคโนโลยีสามารถให้การควบคุมที่สนับสนุนความเป็นส่วนตัวและ โปรแกรมการปฏิบัติตามกฎหมาย แต่การปฏิบัติตามขึ้นอยู่กับข้อกำหนดทางกฎหมายที่เกี่ยวข้องขององค์กร, แนวทางการจัดการข้อมูล การกำหนดค่า, นโยบาย ขั้นตอน สัญญา กฎการเก็บรักษา พฤติกรรมของผู้ใช้, และการกำกับดูแลอย่างต่อเนื่อง
Salesforce รองรับการตรวจสอบหลายปัจจัยหรือไม่?
ใช่ Salesforce รองรับการตรวจสอบหลายปัจจัยเป็นส่วนหนึ่งของ โมเดลความปลอดภัยด้านอัตลักษณ์และการเข้าถึง องค์กรควร กำหนดค่าโครงสร้างพื้นฐานการตรวจสอบและการบริหารจัดการตามผู้ใช้และความต้องการด้านความปลอดภัย
Salesforce Shield คืออะไร?
Salesforce Shield คือชุดความสามารถด้านความปลอดภัยเพิ่มเติมของ Salesforce ที่อาจรวมถึงการเข้ารหัสแพลตฟอร์ม การตรวจสอบเหตุการณ์, การติดตามการตรวจสอบฟิลด์ และเครื่องมือด้านความปลอดภัยที่เกี่ยวข้อง ความพร้อมใช้งานขึ้นอยู่กับผลิตภัณฑ์ Salesforce รุ่น, การอนุญาต และการกำหนดค่าที่เกี่ยวข้อง
ผู้ใช้การจัดการทรัพย์สินที่แตกต่างกันสามารถมีสิทธิ์ที่แตกต่างกันได้หรือไม่?
ใช่ สภาพแวดล้อมที่เป็น Salesforce-native สามารถใช้บทบาทและ สิทธิ์ที่กำหนดค่าได้เพื่อควบคุมการเข้าถึงตามความรับผิดชอบ เช่น การจอง การดำเนินงาน การเงิน การจัดการ หรือการบริหารระบบ โมเดลสิทธิ์ที่แน่นอนขึ้นอยู่กับการกำหนดค่าขององค์กร
Booking Ninjas สร้างขึ้นบน Salesforce หรือไม่?
ใช่ Booking Ninjas เป็นแพลตฟอร์มที่เป็น Salesforce-native สำหรับการจอง และการดำเนินงาน ช่วยให้บันทึกการดำเนินงานและการทำงานสามารถใช้ รากฐานแพลตฟอร์ม Salesforce ที่กว้างขึ้นสำหรับอัตลักษณ์, สิทธิ์ การกำกับดูแล การรายงาน การทำงานอัตโนมัติ และความปลอดภัย
สร้างความปลอดภัยในสถาปัตยกรรมการดำเนินงาน
เชื่อมโยงการจอง ข้อมูลลูกค้า บันทึกทางการเงิน สิทธิ์, การทำงาน การรวมระบบ และการกำกับดูแลภายใน สภาพแวดล้อมการดำเนินงานที่เป็น Salesforce-native



.jpg)






