ตั้งค่า Snowflake MCP สำหรับ Notion

ในเอกสารช่วยเหลือนี้

ดูวิธีเชื่อมต่อ Snowflake กับเอเจนต์ที่กำหนดเองหรือ Notion Agent เพื่อถามเกี่ยวกับข้อมูลบริษัทใน Notion

ข้ามไปยังคำถามที่พบบ่อย

ฟีเจอร์บางอย่างยังอยู่ในช่วงอัลฟ่า

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

หากต้องการขอสิทธิ์เข้าถึง โปรดติดต่อทีมดูแลลูกค้า Notion ของคุณหรือ สมัครเข้าร่วมโปรแกรมการเข้าถึงก่อนใครสำหรับเอเจนต์ข้อมูล →

เอเจนต์ที่กำหนดเอง และ Notion Agent เชื่อมต่อกับ Snowflake ผ่านเซิร์ฟเวอร์ MCP (Model Context Protocol) ที่ Snowflake ให้บริการได้ เมื่อตั้งค่าเสร็จแล้ว ก็ถามเอเจนต์เกี่ยวกับข้อมูลในคลังข้อมูล Snowflake และรับคำตอบได้โดยตรงใน Notion

การตั้งค่าจะแบ่งเป็นขั้นตอน และมีผู้รับผิดชอบในแต่ละส่วนดังนี้:

  • ผู้ดูแลระบบ Snowflake ตั้งค่าบทบาท คลังข้อมูล และเซิร์ฟเวอร์ MCP ที่มีการจัดการโดย Snowflake

  • เจ้าของหรือผู้ดูแลระบบพื้นที่ทำงาน Notion กำหนดค่าการเชื่อมต่อ Snowflake MCP สำหรับพื้นที่ทำงาน

  • สมาชิกในพื้นที่ทำงาน สามารถเชื่อมต่อกับ Snowflake MCP ผ่านเอเจนต์ที่กำหนดเองโดยใช้ข้อมูลประจำตัว Snowflake ของตนเอง หรือเชื่อมต่อ Snowflake เข้ากับ Notion Agent โดยตรง ขั้นตอนที่ 1–10 ของบทความนี้เหมือนกันสำหรับทั้งสองวิธี โดยจะแยกเป็นคนละวิธีในขั้นตอนที่ 11 ตามเอเจนต์ที่คุณต้องการเชื่อมต่อ

  • เครื่องมือที่พร้อมใช้งานอาจแตกต่างกันไปตามภูมิภาคคลาวด์ Snowflake ของคุณ

  • เซิร์ฟเวอร์ MCP ที่ Snowflake จัดการไม่พร้อมใช้งานในจีนแผ่นดินใหญ่หรือภูมิภาคคลาวด์สำหรับหน่วยงานรัฐบาล

  • พื้นที่ทำงาน Notion ของคุณต้องใช้แพ็คเกจ Business หรือแพ็คเกจ Enterprise

  • ใช้ Notion บนเว็บหรือเดสก์ท็อป ฟีเจอร์นี้ไม่พร้อมใช้งานบนมือถือ

  • บริษัทของคุณต้องมีบัญชี Snowflake

  • ในการสร้าง เอเจนต์ที่กำหนดเอง คุณต้องได้รับอนุญาตให้สร้างเอเจนต์ในพื้นที่ทำงานของคุณ

การตั้งค่าที่แชร์ร่วมกันไม่ได้ทำให้ทุกคนเข้าถึงข้อมูลเดียวกันได้

พื้นที่ทำงานจะจัดเก็บรายละเอียดการเชื่อมต่อ ซึ่งรวมถึงรหัสไคลเอ็นต์และรหัสลับ OAuth รายละเอียดเหล่านี้ใช้สำหรับกำหนดค่าการเชื่อมต่อ ไม่ใช่ข้อมูลเข้าสู่ระบบที่ใช้ร่วมกัน แต่ละคนจะเข้าสู่ระบบ Snowflake ด้วยบัญชีของตนเอง ไม่ว่าจะใช้เอเจนต์ที่กำหนดเองหรือ Notion Agent ของตนเอง เอเจนต์จะเข้าถึงได้เฉพาะข้อมูลที่บัญชีนั้นมีสิทธิ์เข้าถึงเท่านั้น

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

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

รวบรวมค่าเหล่านี้ก่อน

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

เก็บรหัสลับไคลเอ็นต์ OAuth ไว้เป็นความลับ

อย่าเพิ่มรหัสลับนี้ลงใน Slack ตั๋วงาน ระบบควบคุมซอร์สโค้ด หรือประวัติคำสั่งในเทอร์มินัล ให้แชร์ผ่านช่องทางที่ปลอดภัยซึ่งได้รับการอนุมัติแล้วเท่านั้น

ฟิลด์

ค่า

เจ้าของ

ตัวระบุบัญชี Snowflake

<organization-account>

ผู้ดูแลระบบ Snowflake

ฐานข้อมูล MCP

<database_name>

ผู้ดูแลระบบ Snowflake

สคีมา MCP

<schema_name>

ผู้ดูแลระบบ Snowflake

เซิร์ฟเวอร์ MCP

<mcp_server_name>

ผู้ดูแลระบบ Snowflake

คลังข้อมูล

<warehouse_name>

ผู้ดูแลระบบ Snowflake

บทบาทการเข้าถึง

<mcp_access_role>

ผู้ดูแลระบบ Snowflake

URL เซิร์ฟเวอร์

https://<account_host>/api/v2/databases/<database_name>/schemas/<schema_name>/mcp-servers/<mcp_server_name>

ผู้ดูแลระบบ Snowflake

ขอบเขตบทบาทหลัก

session:role:<mcp_access_role>

ผู้ดูแลระบบ Snowflake

URI การเปลี่ยนเส้นทาง

คัดลอก URI ที่ Notion สร้างขึ้น

ผู้ดูแลพื้นที่ทำงาน Notion

รหัสไคลเอ็นต์ OAuth

ดึงข้อมูลจาก Snowflake

ผู้ดูแลระบบ Snowflake

รหัสลับไคลเอ็นต์ OAuth

ส่งผ่านช่องทางส่งข้อมูลลับที่อนุมัติแล้ว

ผู้ดูแลระบบ Snowflake

ชื่อโฮสต์ของบัญชีใช้ยัติภังค์ ไม่ใช่ขีดล่าง ตรวจสอบให้แน่ใจว่าชื่อออบเจกต์แต่ละชื่อใน URL ของเซิร์ฟเวอร์ตรงกับชื่อออบเจกต์ที่เกี่ยวข้องใน Snowflake

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

บทบาทที่จำกัดโดยไม่มีบทบาทรอง (แนะนำ) โมเดลนี้เข้าใจและตรวจสอบได้ง่ายกว่า ตั้งค่า OAUTH_USE_SECONDARY_ROLES = NONE ระบุ ALLOWED_ROLES_LIST และใช้ขอบเขต Notion session:role:<mcp_access_role>

บทบาทรองเริ่มต้นของผู้ใช้ (ไม่บังคับ) ใช้รูปแบบนี้เฉพาะเมื่อเซิร์ฟเวอร์ต้องใช้สิทธิ์ที่สืบทอดจาก DEFAULT_SECONDARY_ROLES ของผู้ใช้แต่ละรายใน Snowflake ตั้งค่า OAUTH_USE_SECONDARY_ROLES = IMPLICIT ไม่ต้องระบุ ALLOWED_ROLES_LIST และระบุขอบเขตบทบาทหลักให้ชัดเจน Snowflake ไม่อนุญาตให้ใช้บทบาทรอง IMPLICIT ร่วมกับ ALLOWED_ROLES_LIST จึงไม่ต้องระบุรายการบทบาทที่อนุญาตเมื่อใช้รูปแบบนี้

ขั้นตอนที่ 2: สร้างหรือเลือกบทบาทและคลังข้อมูล

ใช้บทบาทเฉพาะที่มีสิทธิ์น้อยที่สุดสำหรับเซิร์ฟเวอร์ MCP ทุกครั้งที่เป็นไปได้

มอบบทบาทนี้ผ่านกระบวนการจัดการข้อมูลประจำตัวตามปกติ หากใช้ Okta หรือ SCIM จัดการว่าผู้ใช้คนใดได้รับบทบาท Snowflake ก็อย่าเพิ่มผู้ใช้เองนอกกระบวนการนั้น

สร้างหรือเลือกฐานข้อมูลและสคีมาที่ทีมซึ่งจะเรียกใช้เซิร์ฟเวอร์เป็นเจ้าของ

สำหรับคำถามทางธุรกิจที่ต้องอยู่ภายใต้การกำกับดูแล ให้สมาชิกใช้ Cortex Agent เป็นเครื่องมือได้ โดยรวมมุมมองเชิงความหมาย คิวรีที่ตรวจสอบแล้ว Search และการประสานงานไว้ในที่เดียว ไม่จำเป็นต้องใช้ Cortex Agent แต่หากจะสร้าง ให้ใช้ข้อมูลจำเพาะด้านล่าง และหากจะแทนที่เอเจนต์เดิม ให้ตรวจสอบว่าเอเจนต์ใหม่ตรงตามข้อมูลจำเพาะที่อนุมัติแล้ว

execution_environment ต้องอยู่ซ้อนภายในทรัพยากรเครื่องมือ Analyst เท่านั้น

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

ประเภทเครื่องมือ MCP ของ Snowflake อื่นๆ ที่รองรับ ได้แก่ CORTEX_ANALYST_MESSAGE, CORTEX_SEARCH_SERVICE_QUERY, GENERIC และ SYSTEM_EXECUTE_SQL

หากคุณต้องการเข้าถึง SQL โดยตรง ให้ใช้เซิร์ฟเวอร์ MCP แยกต่างหากที่มีบทบาทซึ่งกำหนดสิทธิ์ไว้เท่าที่จำเป็น และตรวจสอบให้แน่ใจว่าบทบาทนั้นมีสิทธิ์อ่านอย่างเดียว

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

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

สิทธิ์ USAGE บนเซิร์ฟเวอร์ MCP ช่วยให้บทบาทเชื่อมต่อกับเซิร์ฟเวอร์และดูว่ามีเครื่องมืออะไรบ้าง แต่ไม่ได้ให้สิทธิ์เข้าถึงคลังข้อมูล เอเจนต์ มุมมองเชิงความหมาย บริการ Search โพรซีเดอร์ที่จัดเก็บไว้ หรือข้อมูลเบื้องหลัง ต้องให้สิทธิ์บทบาทเข้าถึงทรัพยากรแต่ละอย่างที่เครื่องมือของเซิร์ฟเวอร์ต้องใช้ด้วย

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

ก่อนตั้งค่า OAuth ให้ตรวจสอบเซิร์ฟเวอร์ MCP และสิทธิ์ที่ได้รับ:

กำหนดค่าสคีมา MCP ให้ระบุบทบาทที่สมาชิกควรร้องขออย่างชัดเจน:

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

ก่อนเรียกใช้ SQL นี้ ให้ประสานงานกับผู้ดูแลพื้นที่ทำงาน Notion โดยขอให้กรอก URL เซิร์ฟเวอร์ Snowflake ในแบบฟอร์มตั้งค่า MCP ของพื้นที่ทำงาน แล้วเปิด กำหนดค่าการยืนยันตัวตนด้วยตนเอง และ ใช้ไคลเอ็นต์ OAuth ที่แชร์ในพื้นที่ทำงาน จากนั้น Notion จะสร้าง URI การเปลี่ยนเส้นทาง ให้คัดลอก URI นี้ส่งให้ผู้ดูแลระบบ Snowflake เมื่อ Snowflake สร้างรหัสไคลเอ็นต์และรหัสลับแล้ว ผู้ดูแลพื้นที่ทำงานก็ตั้งค่าการเชื่อมต่อให้เสร็จได้

ใช้ URI การเปลี่ยนเส้นทางตามที่ Notion ระบุไว้ทุกประการ ห้ามเพิ่มเครื่องหมายทับต่อท้ายหรือพารามิเตอร์คิวรี และห้ามเปลี่ยนโฮสต์

การตั้งค่า IS_AGENTIC = TRUE จะทำเครื่องหมายเซสชันที่สร้างผ่านการรวมระบบนี้ว่าเป็นเซสชันของเอเจนต์ จากนั้นฟังก์ชัน IS_AGENT_ACTIVATED() ของ Snowflake จะส่งคืนค่า TRUE ทำให้ Snowflake ใช้การตรวจสอบและการกำกับดูแลเฉพาะเอเจนต์ได้ หากใช้รูปแบบบทบาทรองที่เป็นทางเลือก ให้ตั้งค่า OAUTH_USE_SECONDARY_ROLES = IMPLICIT และไม่ต้องระบุ ALLOWED_ROLES_LIST

อายุของโทเค็นรีเฟรช 7776000 วินาที เท่ากับ 90 วัน ก่อนใช้ ให้ตรวจสอบว่าค่านี้สอดคล้องกับนโยบายการอนุญาตใหม่และการหมุนเวียนโทเค็นขององค์กร สำหรับการเปลี่ยนแปลงทั่วไป ให้เลี่ยงการใช้ CREATE OR REPLACE SECURITY INTEGRATION เพราะการแทนที่การรวมระบบอาจทำให้การเชื่อมต่อที่มีอยู่หยุดชะงัก

หากต้องการตรวจสอบการรวมระบบโดยไม่แสดงรหัสลับ ให้เรียกใช้:

ยืนยันว่าการรวมระบบเปิดใช้งานอยู่ URI การเปลี่ยนเส้นทางตรงกันทุกประการ บทบาทได้รับอนุญาตและไม่ถูกบล็อก โทเค็นรีเฟรชและ PKCE เปิดใช้งานอยู่ และปลายทางการอนุญาตกับปลายทางโทเค็นต่างก็ใช้โฮสต์บัญชีสาธารณะของ Snowflake

ขั้นตอนนี้จำเป็นเฉพาะเมื่อองค์กรกำหนดให้ใช้นโยบายเครือข่าย ขอให้ผู้รับผิดชอบด้านความปลอดภัยหรือเครือข่ายอนุมัติช่วงที่อยู่ขาออกปัจจุบันของ Notion

การรวมระบบ OAuth ต้องอนุญาตเส้นทางของ Notion ทั้งสองเส้นทาง:

  1. เส้นทาง API ที่จัดการการเรียกกลับ OAuth และการแลกเปลี่ยนรหัสการอนุญาต

  2. เส้นทางรันไทม์ของพื้นที่ทำงานที่ตรวจสอบการเชื่อมต่อ เรียกใช้เครื่องมือ และรีเฟรชโทเค็น

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

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

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

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

การเชื่อมต่อ MCP ที่กำหนดค่าไว้ในพื้นที่ทำงานเป็นฟีเจอร์ที่ขณะนี้อยู่ในช่วงอัลฟ่า

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

เมื่อ Snowflake พร้อมแล้ว เจ้าของหรือผู้ดูแลพื้นที่ทำงานจะเพิ่มเซิร์ฟเวอร์ให้พื้นที่ทำงานเพียงครั้งเดียว จากนั้นสมาชิกจะค้นหาเซิร์ฟเวอร์ได้โดยไม่ต้องเห็นข้อมูลลับของไคลเอ็นต์ OAuth ไม่ว่าจะเชื่อมต่อ Snowflake MCP กับเอเจนต์ที่กำหนดเองหรือ Notion Agent ของตนเองก็ตาม

  1. ไปที่ การตั้งค่า สำหรับพื้นที่ทำงาน

  2. เลือก การเชื่อมต่อ → MCP ที่แชร์ในพื้นที่ทำงาน

  3. เลือก MCP พื้นที่ทำงานใหม่

กรอกข้อมูลในฟิลด์เหล่านี้ จากนั้นเลือก เพิ่มเซิร์ฟเวอร์ MCP:

ฟิลด์

สิ่งที่ต้องป้อน

ชื่อ

ชื่อที่ชัดเจนซึ่งสมาชิกมองเห็นได้ เช่น Company Snowflake Data Agent

คำอธิบาย

โน้ตสั้นๆ เกี่ยวกับข้อมูลและวิธีที่ควรนำข้อมูลไปใช้

URL เซิร์ฟเวอร์

URL สาธารณะของ Snowflake MCP ตามที่ระบุไว้ในเวิร์กชีตทุกประการ

กำหนดค่าการยืนยันตัวตนด้วยตนเอง

เปิดใช้งาน Notion จะตรวจพบรายละเอียด OAuth ของ Snowflake

ใช้ไคลเอ็นต์ OAuth ที่แชร์ในพื้นที่ทำงาน

เปิดใช้งาน

URI การเปลี่ยนเส้นทาง

สร้างโดย Notion ตรวจสอบว่า URI นี้ตรงกับที่ส่งให้ผู้ดูแลระบบ Snowflake

รหัสไคลเอ็นต์

รหัสไคลเอ็นต์จากการรวมระบบ OAuth ของ Snowflake

ข้อมูลลับของไคลเอ็นต์

ข้อมูลลับที่ตรงกันซึ่งได้รับผ่านช่องทางรับส่งข้อมูลลับที่ได้รับอนุมัติ

ขอบเขต OAuth

เลือกขอบเขต session:role:<mcp_access_role> ให้ตรงตามที่กำหนด เลือก ขอบเขตทั้งหมด ได้ก็ต่อเมื่อ Snowflake ระบุเฉพาะขอบเขตที่อนุมัติแล้วนี้ โดยไม่มีขอบเขตที่กว้างกว่านั้น

หลังจากบันทึกแล้ว ให้ยืนยันว่าแถวใหม่ปรากฏขึ้นภายใต้ Shared with this workspace และ Workspace OAuth client แสดงสถานะ Configured

การตั้งค่านี้ช่วยอะไรบ้าง:

  • ช่วยให้สมาชิกค้นหาเซิร์ฟเวอร์ที่ได้รับอนุมัติได้

  • จัดเก็บข้อมูลลับของไคลเอ็นต์ OAuth เพียงครั้งเดียวในที่จัดเก็บการเชื่อมต่อแบบเข้ารหัสของ Notion

  • ตรวจสอบให้แน่ใจว่าสมาชิกลงชื่อเข้าใช้ด้วย URL ของเซิร์ฟเวอร์ ไคลเอ็นต์ และขอบเขตที่คุณอนุมัติ

  • ไม่สร้างเซสชัน Snowflake ที่แชร์หรือข้ามการควบคุมการเข้าถึงของ Snowflake

  • ไม่เชื่อมต่อสมาชิกทุกคนโดยอัตโนมัติ แต่ละคนต้องลงชื่อเข้าใช้แยกต่างหาก

หากลบการตั้งค่านี้ สมาชิกใหม่จะค้นหาเซิร์ฟเวอร์ไม่พบ แต่การเชื่อมต่อเดิมอาจยังปรากฏอยู่ จึงควรเพิกถอนสิทธิ์ใน Snowflake และลบการเชื่อมต่อเดิมไปพร้อมกัน

เมื่อผู้ดูแลเตรียมการเชื่อมต่อ Snowflake MCP พร้อมแล้ว ก็เลือกใช้งานได้ 2 วิธี หากตั้งค่าให้ทีม ให้เริ่มที่ 11A หากต้องการถามคำถามของตัวเอง ให้ข้ามไปที่ 11B จะใช้ทั้ง 2 วิธีก็ได้ เพราะเป็นการเชื่อมต่อแยกกัน

ขั้นตอนที่ 11A: ตั้งค่าเอเจนต์ที่กำหนดเองแบบมีผู้ดูแลสำหรับทีม

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

การยืนยันตัวตนแบบรายบุคคลในเอเจนต์ที่กำหนดเองขณะนี้อยู่ในช่วงอัลฟ่า

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

เชื่อมต่อ Snowflake เข้ากับเอเจนต์ที่กำหนดเอง

  1. เปิดเอเจนต์ที่กำหนดเอง หรือ สร้างเอเจนต์ใหม่

  2. ไปที่ การตั้งค่า → เครื่องมือและการเข้าถึง

  3. เลือก เพิ่มการเชื่อมต่อ จากนั้นเลือกเซิร์ฟเวอร์ Snowflake ที่มีป้ายกำกับว่า Workspace Managed อย่าเลือก Custom MCP server หรือป้อน URL ของเซิร์ฟเวอร์ด้วยตนเอง

  4. ลงชื่อเข้าใช้ Snowflake ในเบราว์เซอร์ของคุณ ระบบอาจแสดงการลงชื่อเข้าใช้ Okta หรือ SSO ตามปกติขององค์กรของคุณ

  5. ตรวจสอบและอนุมัติบทบาท Snowflake ที่ร้องขอ

  6. เลือกเครื่องมือที่เอเจนต์ใช้ได้ โดยตั้งค่าให้เครื่องมือที่แก้ไขข้อมูลได้และ CORTEX_AGENT_RUN ต้องขออนุมัติไปก่อนจนกว่าจะทดสอบเรียบร้อย

  7. เลือก เชื่อมต่อ และยืนยันว่าการเชื่อมต่อแสดงเป็น เชื่อมต่อแล้ว

เพิ่มข้อมูลพื้นฐานให้เอเจนต์

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

แชร์เอเจนต์

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

การยืนยันตัวตนแบบรายบุคคลจะมีผลเมื่อมีคนแชทกับเอเจนต์โดยตรง

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

ขั้นตอนที่ 11B: เชื่อมต่อ Snowflake เข้ากับ Notion Agent ของคุณเอง

หากคุณต้องการถามคำถามของคุณเองในการแชทของคุณเอง ให้เชื่อมต่อ Snowflake เข้ากับ Notion Agent ของคุณ คุณลงชื่อเข้าใช้ด้วยบัญชี Snowflake ของคุณเอง ดังนั้นเอเจนต์ของคุณจะเข้าถึงได้เฉพาะสิ่งที่คุณได้รับอนุญาตให้เห็นเท่านั้น

  1. ไปที่ การตั้งค่า → Notion AI

  2. ภายใต้ เซิร์ฟเวอร์ MCP ให้เลือก เพิ่มเซิร์ฟเวอร์ MCP

  3. เลือกเซิร์ฟเวอร์ Snowflake ที่มีป้ายกำกับว่า Workspace Managed อย่าเลือก Custom MCP server หรือป้อน URL ของเซิร์ฟเวอร์ด้วยตนเอง

  4. เลือก เชื่อมต่อ

  5. ลงชื่อเข้าใช้ Snowflake ในเบราว์เซอร์ของคุณ ระบบอาจแสดงการลงชื่อเข้าใช้ Okta หรือ SSO ตามปกติขององค์กรของคุณ

  6. ตรวจสอบและอนุมัติบทบาท Snowflake ที่ร้องขอ

  7. เมื่อเบราว์เซอร์ของคุณถามว่าจะเปิด Notion หรือไม่ ให้เลือก เปิด Notion

  8. ตรวจสอบว่าสถานะเซิร์ฟเวอร์เป็น เชื่อมต่อแล้ว ไม่ใช่ ต้องยืนยันตัวตน

หลังจากที่คุณเชื่อมต่อแล้ว Snowflake จะปรากฏใน แหล่งข้อมูลทั้งหมด → เซิร์ฟเวอร์ MCP ในแชท

ไม่ว่าวิธีไหน ก็ไม่ควรมีการขอรหัสไคลเอ็นต์ OAuth หรือรหัสลับ

หาก Notion ขอให้ระบุข้อมูลอย่างใดอย่างหนึ่ง คุณอาจเลือกตัวเลือก MCP แบบกำหนดเองแทนเซิร์ฟเวอร์ที่จัดการโดยพื้นที่ทำงาน หรือผู้ดูแลของคุณอาจยังไม่ได้เปิด ใช้ OAuth client ที่แชร์ในพื้นที่ทำงาน ให้ย้อนกลับไปเลือกเซิร์ฟเวอร์ จัดการโดยพื้นที่ทำงาน แทน

  1. ถามคำถามที่ไม่มีความเสี่ยง รู้คำตอบอยู่แล้ว และควรใช้ Snowflake ในการตอบ

  2. ตรวจสอบว่าเอเจนต์ใช้ Snowflake และแสดงผลลัพธ์

  3. ตรวจสอบว่าเข้าถึงข้อมูลที่อยู่นอกสิทธิ์ของบทบาทที่ได้รับไม่ได้

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

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

ถามเอเจนต์เกี่ยวกับข้อมูล Snowflake โดยระบุคำถามให้ชัดเจน ตัวอย่างเช่น:

  • "จาก Snowflake ยอดการสมัครใช้งานทั้งหมดของเราเมื่อเดือนที่แล้วคือเท่าไร?"

  • "จาก Snowflake บัญชี 10 อันดับแรกของเราที่สร้างรายได้สูงสุดในไตรมาสนี้มีบัญชีใดบ้าง?"

ถ้าคำสั่งของเอเจนต์ที่กำหนดเองระบุชัดแล้วว่าควรใช้ Snowflake เมื่อใด ก็มักไม่ต้องระบุว่า "จาก Snowflake" แต่สำหรับ Notion Agent การระบุชื่อ Snowflake จะช่วยให้เอเจนต์เลือกแหล่งข้อมูลได้ถูกต้อง

คำขอขนาดใหญ่อาจใช้เวลานานหรือหมดเวลา หากเป็นเช่นนั้น ให้ถามเจาะจงขึ้นหรือแบ่งคำขอเป็นคำถามย่อยๆ

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

ต้องลงชื่อเข้าใช้อีกครั้งในกรณีต่อไปนี้:

  • รีเฟรชโทเค็นหมดอายุ หรือผู้ดูแลเพิกถอนโทเค็น

  • ผู้ดูแลเปลี่ยนการผสานการทำงานกับ OAuth หรือรหัสลับไคลเอ็นต์

  • บทบาทใน Snowflake ถูกนำออก

  • ผู้ดูแลนำการตั้งค่าพื้นที่ทำงานหรือการเชื่อมต่อออก

  • นโยบายเครือข่ายบล็อกการรีเฟรชโทเค็น

เมื่อใช้เอเจนต์ที่กำหนดเอง แต่ละคนจะลงชื่อเข้าใช้แยกกัน หากคนหนึ่งต้องลงชื่อเข้าใช้อีกครั้ง ก็ไม่กระทบคนอื่น และผู้สร้างเอเจนต์ไม่ต้องทำอะไร

หากต้องเปลี่ยนรหัสลับไคลเอ็นต์: ให้ใช้วิธีเปลี่ยนรหัสลับ 2 ชุดของ Snowflake แทนการเปลี่ยนการผสานการทำงาน โดยให้รหัสลับทั้ง 2 ชุดยังใช้ได้จนกว่าจะอัปเดตและทดสอบการตั้งค่าพื้นที่ทำงานเสร็จ แล้วจึงเลิกใช้ชุดเก่า

ALTER SECURITY INTEGRATION <oauth_integration_name>
REFRESH OAUTH_CLIENT_SECRET_2;

  • ไม่มีการเชื่อมต่อ Snowflake MCP ในลิสต์ ผู้ดูแลพื้นที่ทำงานอาจยังไม่ได้เพิ่มการเชื่อมต่อนี้ หรือพื้นที่ทำงานอาจจำกัดการใช้เซิร์ฟเวอร์ที่กำหนดเอง ขอความช่วยเหลือจากผู้ดูแล

  • ระบบขอรหัสไคลเอ็นต์หรือรหัสลับ อาจเลือกตัวเลือก MCP แบบกำหนดเองไว้ ให้กลับไปเลือกเซิร์ฟเวอร์ Snowflake ที่มีป้าย Workspace Managed แทน

  • ระบบขอให้ลงชื่อเข้าใช้อีกครั้ง เซสชัน Snowflake อาจหมดอายุ หรือผู้ดูแลอาจอัปเดตการเชื่อมต่อ ให้ลงชื่อเข้าใช้ Snowflake อีกครั้ง

  • เปิดเอเจนต์ที่กำหนดเองแล้วระบบขอให้ลงชื่อเข้าใช้ Snowflake นี่เป็นเรื่องปกติในการใช้งานครั้งแรก ทุกคนที่ใช้เอเจนต์ที่กำหนดเองซึ่งมีการจัดการต้องลงชื่อเข้าใช้ด้วยข้อมูลประจำตัว Snowflake ของตนเอง

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

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

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

  • เอเจนต์หาตารางไม่พบ เอเจนต์เข้าถึงได้เฉพาะข้อมูลที่บัญชี Snowflake เข้าถึงได้ ตรวจสอบสิทธิ์ใน Snowflake แล้วระบุชื่อตารางในคำถามด้วย

  • คำขอหมดเวลา ลองถามให้เจาะจงขึ้น หรือแบ่งคำขอเป็นคำถามย่อย

สำหรับผู้ดูแล: ข้อผิดพลาดในการลงชื่อเข้าใช้และการเชื่อมต่อ

ข้อผิดพลาดเหล่านี้มักเกิดจากการตั้งค่า Snowflake ไม่ใช่ Notion แชร์ข้อผิดพลาดเหล่านี้กับผู้ดูแล Snowflake

  • URL ของเซิร์ฟเวอร์ดูเหมือนซ้ำกัน เช่น https://https%3A... ที่อยู่ถูกวางโดยมี https:// เกินมาด้านหน้า โปรดแก้ไขเพื่อให้ URL ขึ้นต้นด้วย https:// เพียงชุดเดียว

  • เห็นข้อความ "This server does not support OAuth authentication." การผสานการทำงานด้านความปลอดภัยไม่ได้ตั้งค่าสำหรับ OAuth หรือ URL ของเซิร์ฟเวอร์ไม่ถูกต้อง ขอให้ผู้ดูแล Snowflake ตรวจสอบการผสานการทำงานด้านความปลอดภัยสำหรับ OAuth และ URL ของเซิร์ฟเวอร์

  • เห็น invalid_client ขณะลงชื่อเข้าใช้หรือรีเฟรชโทเค็น รหัสไคลเอ็นต์หรือรหัสลับอาจไม่ถูกต้อง หรือรหัสลับถูกเปลี่ยนแล้ว ขอรหัสไคลเอ็นต์และรหัสลับปัจจุบันจากผู้ดูแล

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

  • เห็นข้อความ "The role ALL requested has been explicitly blocked." การเชื่อมต่อขอใช้ทุกบทบาทพร้อมกัน (session:role:all) ซึ่งถูกบล็อกไว้ ให้ระบุเพียงบทบาทเดียว เช่น session:role:analyst โดยใช้ชื่อบทบาทจริงแทน analyst

  • เห็นข้อผิดพลาดเกี่ยวกับ URL เปลี่ยนเส้นทาง (ข้อผิดพลาด 390307) URL เปลี่ยนเส้นทางที่บันทึกไว้ใน Snowflake ไม่ตรงกับ URL ที่ Notion ใช้ ขอให้ผู้ดูแลตั้งค่า URL เปลี่ยนเส้นทางในการผสานการทำงานด้านความปลอดภัยให้ตรงกับค่าของ Notion ทุกประการ

  • เห็นข้อผิดพลาด 390311 เกี่ยวกับ code challenge ที่ไม่ถูกต้อง ค่า PKCE ไม่ตรงกัน ขอให้ผู้ดูแลตรวจสอบว่าตั้งค่า OAUTH_ENFORCE_PKCE ในการผสานการทำงานด้านความปลอดภัยถูกต้องแล้ว

  • เชื่อมต่อแล้ว แต่ไม่มีเครื่องมือปรากฏ บทบาทที่ใช้อาจไม่มีสิทธิ์ USAGE สำหรับเซิร์ฟเวอร์ MCP ขอให้ผู้ดูแลตรวจสอบสิทธิ์ แล้วเรียกใช้ DESCRIBE MCP SERVER เพื่อตรวจสอบการตั้งค่า

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

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

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

  • ตัวระบุบัญชีถูกปฏิเสธ ใช้รูปแบบ organization-account ที่มีเครื่องหมายขีดกลาง เช่น myorg-myaccount ไม่ใช่จุด

  • บัญชี PrivateLink เชื่อมต่อไม่ได้ บัญชี PrivateLink ต้องตั้งค่าเครือข่ายเพิ่มเติม สอบถามผู้ดูแลว่า PrivateLink อนุญาตการเชื่อมต่อกับ Notion หรือไม่

  • ใช้ Snowflake ในรอบการทำงานตามกำหนดการหรือที่เริ่มจากทริกเกอร์ไม่ได้ รอบการทำงานเหล่านี้ไม่มีผู้ลงชื่อเข้าใช้ จึงยังใช้การลงชื่อเข้าใช้แบบรายบุคคลไม่ได้ ให้ส่งคำขอในแชทแทน

  • พบข้อผิดพลาด oauth_security_error หลังจากลงชื่อเข้าใช้ผ่านเบราว์เซอร์ นโยบายเครือข่ายระดับบัญชีอาจบล็อคคำขอนี้อยู่ ผู้ดูแลตรวจสอบได้ด้วยคำสั่งต่อไปนี้:

  • ลงชื่อเข้าใช้ได้ แต่พบข้อผิดพลาดเกี่ยวกับบทบาท แม้จะกำหนดขอบเขตถูกต้องแล้ว บทบาทเริ่มต้นอาจถูกบล็อค เช่น ACCOUNTADMIN หรือบทบาทใน BLOCKED_ROLES_LIST ผู้ดูแลตรวจสอบและแก้ไขได้ดังนี้:

คำสั่งแบบอ่านอย่างเดียวเหล่านี้ช่วยให้ผู้ดูแลตรวจสอบการตั้งค่าได้โดยไม่เปลี่ยนแปลงอะไร ให้เรียกใช้คำสั่งใน Snowflake

มุมมอง ACCOUNT_USAGE อาจแสดงข้อมูลล่าช้า ดังนั้นการไม่พบแถวจึงไม่ใช่ข้อพิสูจน์ว่าไม่เคยมีคำขอเกิดขึ้น

อย่าเปลี่ยนรหัสลับ ลดความเข้มงวดของนโยบาย หรือขยายสิทธิ์ที่ให้ไว้จนกว่าจะทราบว่าปัญหาเกิดขึ้นที่ชั้นใด

ใช้คู่มือ Snowflake เหล่านี้เพื่อดำเนินการตั้งค่าให้เสร็จสมบูรณ์:

คำถามที่พบบ่อย

ควรตั้งค่าเอเจนต์ที่กำหนดเองหรือเชื่อมต่อ Snowflake กับ Notion Agent ดี?

หากตั้งค่าการเชื่อมต่อ Snowflake MCP ให้ทีม ให้สร้างเอเจนต์ที่กำหนดเอง เพื่อให้ทุกคนใช้คำสั่งและนิยามตัวชี้วัดเดียวกัน และมีที่เดียวไว้ถามคำถาม โดยแต่ละคนยังลงชื่อเข้าใช้ด้วยข้อมูลประจำตัว Snowflake ของตัวเอง หากต้องการถามคำถามของตัวเองเท่านั้น ให้เชื่อมต่อ Snowflake MCP กับ Notion Agent หรือจะทำทั้งสองอย่างก็ได้

ถ้าเชื่อมต่อ Snowflake กับ Notion Agent แล้ว Snowflake จะเชื่อมต่อกับเอเจนต์ที่กำหนดเองของทีมด้วยไหม?

ไม่ การเชื่อมต่อแต่ละรายการแยกจากกัน และเอเจนต์ที่กำหนดเองแต่ละตัวต้องมีการเชื่อมต่อของตัวเอง การตั้งค่า Snowflake จากขั้นตอนที่ 1–10 ใช้ร่วมกันได้ แต่การลงชื่อเข้าใช้ใช้ร่วมกันไม่ได้

ทุกคนในทีมเห็นข้อมูลเดียวกันไหม?

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

ต้องแชร์รหัสผ่าน Snowflake กับทีมไหม?

ไม่ ไม่มีใครแชร์ข้อมูลประจำตัว พื้นที่ทำงานจะจัดเก็บรายละเอียดไคลเอ็นต์ OAuth ไว้เพียงครั้งเดียว และแต่ละคนจะลงชื่อเข้าใช้ Snowflake ด้วยตนเอง

ให้ข้อเสนอแนะ

แหล่งข้อมูลนี้มีประโยชน์หรือไม่?

Powered by Molteo