ตั้งค่า 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 |
| ผู้ดูแลระบบ Snowflake |
ฐานข้อมูล MCP |
| ผู้ดูแลระบบ Snowflake |
สคีมา MCP |
| ผู้ดูแลระบบ Snowflake |
เซิร์ฟเวอร์ MCP |
| ผู้ดูแลระบบ Snowflake |
คลังข้อมูล |
| ผู้ดูแลระบบ Snowflake |
บทบาทการเข้าถึง |
| ผู้ดูแลระบบ Snowflake |
URL เซิร์ฟเวอร์ |
| ผู้ดูแลระบบ Snowflake |
ขอบเขตบทบาทหลัก |
| ผู้ดูแลระบบ 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 ดังนั้นให้ละเว้นรายการที่อนุญาตเมื่อคุณใช้โมเดลนี้
ใช้บทบาทเฉพาะที่มีสิทธิ์น้อยที่สุดสำหรับเซิร์ฟเวอร์ 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
ขั้นตอนนี้จำเป็นเฉพาะเมื่อองค์กรกำหนดให้ใช้นโยบายเครือข่าย ขอให้ผู้รับผิดชอบด้านความปลอดภัยหรือเครือข่ายอนุมัติช่วง IP ขาออกปัจจุบันของ Notion
การรวมระบบ OAuth ต้องอนุญาตเส้นทางของ Notion ทั้งสองเส้นทาง:
เส้นทาง API ที่จัดการการเรียกกลับ OAuth และการแลกเปลี่ยนรหัสการอนุญาต
เส้นทางรันไทม์ของพื้นที่ทำงานที่ตรวจสอบความถูกต้องของการเชื่อมต่อ เรียกใช้เครื่องมือ และรีเฟรชโทเค็น
เส้นทางเหล่านี้อาจใช้ที่อยู่ IP ขาออกของ Notion ต่างกัน หากอนุญาตเฉพาะที่อยู่ที่ใช้แลกเปลี่ยนโทเค็นครั้งแรก การลงชื่อเข้าใช้อาจสำเร็จ แต่การตรวจสอบการเชื่อมต่อหรือรีเฟรชโทเค็นอาจล้มเหลว ให้ใช้ช่วง IP ขาออกปัจจุบันของ Notion ที่อนุมัติแล้ว อย่าเพิ่มที่อยู่ IP ที่พบเพียงครั้งเดียวจากเบราว์เซอร์หรือบันทึกลงในลิสต์ที่อนุญาตสำหรับระบบที่ใช้งานจริง
ใช้นโยบายเครือข่ายนี้กับการรวมระบบ OAuth ไม่ใช่กับผู้ใช้แต่ละราย อย่าเปลี่ยนนโยบายระดับบัญชีสำหรับการลงชื่อเข้าใช้ผ่านเบราว์เซอร์ การเข้าถึง VPN หรือการเข้าถึงเครือข่ายของผู้ใช้ หากนโยบายเครือข่ายบล็อกคำขอโทเค็น Snowflake อาจส่งคืน invalid_client ข้อผิดพลาดนี้ไม่ได้หมายความว่ารหัสไคลเอ็นต์หรือรหัสลับไม่ถูกต้องเสมอไป
เรียกใช้คำสั่งนี้ในเวิร์กชีต Snowflake ที่ปลอดภัย ชื่อการรวมระบบแยกตัวพิมพ์เล็ก-ใหญ่ และมักเป็นตัวพิมพ์ใหญ่ทั้งหมด:
แชร์รหัสไคลเอ็นต์และรหัสลับที่ตรงกันให้ผู้ดูแลพื้นที่ทำงาน Notion ผ่านช่องทางที่ปลอดภัยและได้รับอนุมัติ Snowflake มีรหัสลับที่ใช้ได้ 2 ชุด จึงสลับใช้ได้โดยไม่ต้องหยุดให้บริการ อย่าวางรหัสลับชุดใดลงในเอกสาร แชท ทิกเก็ต หรือระบบควบคุมเวอร์ชัน
การเชื่อมต่อ MCP ที่ตั้งค่าในพื้นที่ทำงานเป็นฟีเจอร์ที่ยังอยู่ในช่วงอัลฟ่า
หากพื้นที่ทำงานยังไม่มีสิทธิ์เข้าถึง ให้ติดต่อทีมดูแลลูกค้าหรือสมัครเข้าร่วมโปรแกรมสิทธิ์เข้าถึงก่อนใครสำหรับเอเจนต์ข้อมูล
เมื่อ Snowflake พร้อมแล้ว เจ้าของหรือผู้ดูแลพื้นที่ทำงานจะเพิ่มเซิร์ฟเวอร์ให้พื้นที่ทำงานเพียงครั้งเดียว จากนั้นสมาชิกจะค้นหาเซิร์ฟเวอร์ได้โดยไม่ต้องเห็นรหัสลับไคลเอ็นต์ OAuth ไม่ว่าจะเชื่อมต่อ Snowflake MCP กับเอเจนต์ที่กำหนดเองหรือ Notion Agent ของตนเองก็ตาม
ไปที่
การตั้งค่าของพื้นที่ทำงานเลือก
การเชื่อมต่อ→MCP ที่แชร์ในพื้นที่ทำงานเลือก
MCP พื้นที่ทำงานใหม่
กรอกข้อมูลในช่องเหล่านี้ จากนั้นเลือก เพิ่มเซิร์ฟเวอร์ MCP:
ฟิลด์ | สิ่งที่ต้องป้อน |
|---|---|
ชื่อ | ชื่อที่ชัดเจนสำหรับสมาชิก เช่น |
คำอธิบาย | ข้อความสั้นๆ เกี่ยวกับข้อมูลและวัตถุประสงค์การใช้งาน |
URL ของเซิร์ฟเวอร์ | URL สาธารณะของเซิร์ฟเวอร์ Snowflake MCP ตามที่ระบุไว้ในเวิร์กชีตทุกประการ |
กำหนดค่าการยืนยันตัวตนด้วยตนเอง | เปิดใช้งาน แล้ว Notion จะตรวจหารายละเอียด OAuth ของ Snowflake |
ใช้ไคลเอ็นต์ OAuth ที่แชร์ในพื้นที่ทำงาน | เปิดใช้งาน |
URI สำหรับเปลี่ยนเส้นทาง | Notion สร้าง URI นี้ให้ ตรวจสอบว่าตรงกับ URI ที่ส่งให้ผู้ดูแล Snowflake |
รหัสไคลเอ็นต์ | รหัสไคลเอ็นต์จากการรวมระบบ OAuth ของ Snowflake |
รหัสลับไคลเอ็นต์ | รหัสลับที่ตรงกับรหัสไคลเอ็นต์ ซึ่งได้รับผ่านช่องทางที่ปลอดภัยและได้รับอนุมัติ |
ขอบเขต OAuth | เลือกขอบเขต |
หลังจากบันทึกแล้ว ให้ยืนยันว่าแถวใหม่ปรากฏขึ้นภายใต้ แชร์กับพื้นที่ทำงานนี้ และ ไคลเอ็นต์ OAuth ของพื้นที่ทำงาน แสดงสถานะ กำหนดค่าแล้ว
การตั้งค่านี้ทำอะไรบ้าง:
ช่วยให้สมาชิกค้นหาเซิร์ฟเวอร์ที่ได้รับอนุมัติพบ
จัดเก็บรหัสลับของไคลเอ็นต์ OAuth ไว้ในที่จัดเก็บการเชื่อมต่อแบบเข้ารหัสของ Notion เพียงครั้งเดียว
สมาชิกจะลงชื่อเข้าใช้ด้วย URL ของเซิร์ฟเวอร์ ไคลเอ็นต์ และขอบเขตสิทธิ์ที่อนุมัติไว้เท่านั้น
ไม่สร้างเซสชัน Snowflake ที่แชร์หรือข้ามการควบคุมการเข้าถึงของ Snowflake
ไม่เชื่อมต่อสมาชิกทุกคนโดยอัตโนมัติ แต่ละคนต้องลงชื่อเข้าใช้แยกต่างหาก
หากลบการตั้งค่านี้ สมาชิกใหม่จะค้นหาเซิร์ฟเวอร์ไม่พบอีก แต่การเชื่อมต่อเดิมอาจยังปรากฏอยู่ จึงควรเพิกถอนสิทธิ์ใน Snowflake และลบการเชื่อมต่อเดิมไปพร้อมกัน
เมื่อผู้ดูแลเตรียมการเชื่อมต่อ Snowflake MCP พร้อมแล้ว ก็ใช้งานได้ 2 วิธี หากตั้งค่าให้ทีม ให้เริ่มที่ 11A หากต้องการถามคำถามของตัวเอง ให้ข้ามไปที่ 11B จะใช้ทั้ง 2 วิธีก็ได้ เพราะเป็นการเชื่อมต่อแยกกัน
เอเจนต์ที่กำหนดเองช่วยให้ทีมถามเรื่องข้อมูล Snowflake ได้ในที่เดียว เพียงเชื่อมต่อ Snowflake ครั้งเดียว เพิ่มคำสั่งเกี่ยวกับเมตริกและตาราง แล้วแชร์เอเจนต์กับทีม ทุกคนที่ใช้งานต้องลงชื่อเข้าใช้ Snowflake ด้วยข้อมูลประจำตัวของตนเอง จึงได้รับคำตอบจากข้อมูลที่ตนมีสิทธิ์ดูเท่านั้น
การยืนยันตัวตนแยกตามบุคคลในเอเจนต์ที่กำหนดเองยังอยู่ในช่วงอัลฟ่า
หากพื้นที่ทำงานยังไม่มีสิทธิ์เข้าถึง ให้ติดต่อทีมดูแลลูกค้าหรือสมัครเข้าร่วมโปรแกรมสิทธิ์เข้าถึงก่อนใครสำหรับเอเจนต์ข้อมูล
เชื่อมต่อ Snowflake เข้ากับเอเจนต์ที่กำหนดเอง
เปิดเอเจนต์ที่กำหนดเอง หรือ สร้างเอเจนต์ใหม่
ไปที่
การตั้งค่า→เครื่องมือและการเข้าถึงเลือก
เพิ่มการเชื่อมต่อจากนั้นเลือกเซิร์ฟเวอร์ Snowflake ที่ระบุว่าWorkspace Managedอย่าเลือกCustom MCP serverหรือป้อน URL ของเซิร์ฟเวอร์ด้วยตนเองลงชื่อเข้าใช้ Snowflake ในเบราว์เซอร์ของคุณ ระบบอาจแสดงหน้าลงชื่อเข้าใช้ Okta หรือ SSO ตามปกติขององค์กรคุณ
ตรวจสอบและอนุมัติบทบาท Snowflake ที่ร้องขอ
เลือกเครื่องมือที่เอเจนต์สามารถใช้ได้ ปล่อยให้เครื่องมือที่สามารถเขียนข้อมูลได้และ
CORTEX_AGENT_RUNตั้งค่าไว้ให้ขออนุมัติจนกว่าคุณจะทดสอบเครื่องมือเหล่านั้นแล้วเลือก
เชื่อมต่อและยืนยันว่าการเชื่อมต่อแสดงสถานะเป็นเชื่อมต่อแล้ว
เพิ่มข้อมูลบริบทให้เอเจนต์
การเชื่อมต่อช่วยให้เอเจนต์เข้าถึง Snowflake ได้ ส่วนคำสั่งจะบอกเอเจนต์ว่าบริษัทใช้ข้อมูลนั้นอย่างไร ระบุในคำสั่งของเอเจนต์ว่าควรใช้เครื่องมือใดกับคำถามประเภทใด ทีมกำหนดเมตริกหลักอย่างไร และควรเริ่มจากตารางหรือมุมมองเชิงความหมายใด ตัวอย่างคำถามที่ตรวจสอบแล้วเพียงไม่กี่ข้อก็ช่วยได้มาก หากต้องการจุดเริ่มต้นที่พร้อมใช้ โปรดดูคู่มือชุดเครื่องมือ Data Scout
แชร์เอเจนต์
แชร์เอเจนต์กับทีมของคุณแบบเดียวกับที่แชร์เอเจนต์ที่กำหนดเองอื่นๆ เมื่อมีคนถามคำถามที่ต้องใช้ Snowflake เป็นครั้งแรก ระบบจะแจ้งให้คนนั้นลงชื่อเข้าใช้ด้วยบัญชี Snowflake ของตนเอง โดยจะไม่ขอรหัสไคลเอนต์หรือรหัสลับ
การยืนยันตัวตนแยกตามบุคคลใช้เมื่อมีคนแชทกับเอเจนต์โดยตรง
รอบการทำงานตามกำหนดการหรือที่เริ่มจากทริกเกอร์ไม่มีผู้เข้าสู่ระบบ จึงยังใช้สิทธิ์เข้าถึง Snowflake ของใครไม่ได้ หากต้องการใช้ข้อมูล Snowflake ตามกำหนดการ ให้ปรึกษาผู้ดูแล Snowflake ก่อนตั้งค่า
หากต้องการถามคำถามในแชทของตัวเอง ให้เชื่อมต่อ Snowflake กับ Notion Agent เมื่อลงชื่อเข้าใช้ด้วยบัญชี Snowflake ของตัวเอง เอเจนต์จะเข้าถึงได้เฉพาะข้อมูลที่บัญชีนั้นมีสิทธิ์ดู
ไปที่
การตั้งค่า→Notion AIภายใต้
เซิร์ฟเวอร์ MCPให้เลือกเพิ่มเซิร์ฟเวอร์ MCPเลือกเซิร์ฟเวอร์ Snowflake ที่ระบุว่า
Workspace Managedอย่าเลือกCustom MCP serverหรือป้อน URL ของเซิร์ฟเวอร์ด้วยตนเองเลือก
เชื่อมต่อลงชื่อเข้าใช้ Snowflake ในเบราว์เซอร์ของคุณ ระบบอาจแสดงหน้าลงชื่อเข้าใช้ Okta หรือ SSO ตามปกติขององค์กรคุณ
ตรวจสอบและอนุมัติบทบาท Snowflake ที่ร้องขอ
เมื่อเบราว์เซอร์ของคุณถามว่าจะเปิด Notion หรือไม่ ให้เลือก
เปิด Notionยืนยันว่าสถานะเซิร์ฟเวอร์คือ
เชื่อมต่อแล้วไม่ใช่ต้องการการยืนยันตัวตน
หลังจากที่คุณเชื่อมต่อแล้ว Snowflake จะปรากฏใน แหล่งข้อมูลทั้งหมด → เซิร์ฟเวอร์ MCP ในแชท
ไม่ควรมีการขอรหัสไคลเอ็นต์ OAuth หรือข้อมูลลับของไคลเอ็นต์ ไม่ว่าจะเลือกวิธีใด
หาก Notion ขอข้อมูลอย่างใดอย่างหนึ่ง คุณอาจเลือกตัวเลือก MCP แบบกำหนดเองแทนเซิร์ฟเวอร์ที่จัดการโดยพื้นที่ทำงาน หรือผู้ดูแลของคุณอาจยังไม่ได้เปิดใช้ ใช้ OAuth client ที่ใช้ร่วมกันในพื้นที่ทำงาน ให้ย้อนกลับไปเลือกเซิร์ฟเวอร์ ที่จัดการโดยพื้นที่ทำงาน แทน
ถามคำถามที่ไม่เสี่ยง มีคำตอบที่ทราบอยู่แล้ว และต้องใช้ Snowflake ในการตอบ
ยืนยันว่าเอเจนต์ใช้ Snowflake และส่งคืนผลลัพธ์
ตรวจสอบว่าเข้าถึงข้อมูลนอกเหนือจากสิทธิ์ของบทบาทที่ได้รับไม่ได้
หากตั้งค่าเอเจนต์ที่กำหนดเอง ให้เพื่อนร่วมทีมที่มีสิทธิ์ใน Snowflake จำกัดกว่าลองใช้ด้วย เพื่อนร่วมทีมควรเห็นเฉพาะข้อมูลที่ตนมีสิทธิ์ดู ไม่ใช่ข้อมูลทั้งหมดที่ผู้สร้างเอเจนต์มีสิทธิ์ดู วิธีนี้ช่วยตรวจสอบได้เร็วที่สุดว่าเอเจนต์ใช้สิทธิ์การเข้าถึงของแต่ละคน ไม่ใช่สิทธิ์ของผู้สร้างเอเจนต์
สำหรับการตรวจสอบเชิงลึก ให้ขอให้ผู้ดูแลระบบ Snowflake ของคุณยืนยันผู้ใช้ บทบาท คลังข้อมูล และประวัติการสืบค้นของคุณ การลงชื่อเข้าใช้สำเร็จเป็นการยืนยันตัวตนของคุณ แต่ไม่ได้ยืนยันว่าการให้สิทธิ์ทุกอย่างถูกต้อง
ถามคำถามเฉพาะเจาะจงเกี่ยวกับข้อมูล Snowflake ของคุณกับเอเจนต์ ตัวอย่างเช่น:
"จาก Snowflake ยอดการสมัครใช้งานทั้งหมดของเราเมื่อเดือนที่แล้วคือเท่าไร?"
"จาก Snowflake บัญชีใดบ้างที่สร้างรายได้สูงสุด 10 อันดับแรกในไตรมาสนี้?"
สำหรับเอเจนต์ที่กำหนดเอง คุณมักจะข้ามคำว่า "จาก Snowflake" ได้เมื่อคำสั่งของเอเจนต์ระบุชัดเจนว่าควรใช้ Snowflake เมื่อใด สำหรับ Notion Agent ของคุณ การระบุชื่อ Snowflake จะช่วยให้เอเจนต์เลือกแหล่งข้อมูลที่ถูกต้องได้
คำขอขนาดใหญ่อาจใช้เวลานานขึ้นหรือหมดเวลา หากเกิดเหตุการณ์ดังกล่าว ให้ถามคำถามที่แคบลงหรือแบ่งคำขอออกเป็นคำถามย่อย ๆ
ส่วนใหญ่การเชื่อมต่อจะคงอยู่โดยไม่ต้องทำอะไร Snowflake ใช้โทเค็นการเข้าถึงที่มีอายุสั้น และ Notion จะรีเฟรชให้ในเบื้องหลัง โทเค็นการเข้าถึงที่ใกล้หมดอายุเพียงอย่างเดียวไม่ทำให้การเชื่อมต่อหลุด
คุณจะต้องลงชื่อเข้าใช้อีกครั้งหาก:
โทเค็นรีเฟรชหมดอายุหรือถูกผู้ดูแลเพิกถอน
ผู้ดูแลแทนที่การผสานการทำงาน OAuth หรือรหัสลับของไคลเอ็นต์
บทบาท Snowflake ของคุณถูกลบออก
ผู้ดูแลลบการตั้งค่าพื้นที่ทำงานหรือการเชื่อมต่อของผู้ใช้ออก
นโยบายเครือข่ายบล็อกการรีเฟรชโทเค็น
เมื่อใช้เอเจนต์ที่กำหนดเอง แต่ละคนจะลงชื่อเข้าใช้แยกกัน หากมีคนต้องลงชื่อเข้าใช้อีกครั้ง ก็ไม่กระทบคนอื่น และผู้สร้างเอเจนต์ไม่ต้องทำอะไร
หากกำลังเปลี่ยนรหัสลับของไคลเอ็นต์: ใช้วิธีเปลี่ยนรหัสลับแบบสองชุดของ Snowflake แทนการเปลี่ยนการผสานรวม โดยให้รหัสลับทั้งสองชุดใช้งานได้นานพอที่จะอัปเดตและทดสอบการตั้งค่าพื้นที่ทำงานก่อนเลิกใช้ชุดเดิม
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โดยเปลี่ยนเป็นชื่อบทบาทจริงที่ใช้พบข้อผิดพลาดในการเปลี่ยนเส้นทาง (ข้อผิดพลาด 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 กับ Notion Agent ดี?
หากตั้งค่าการเชื่อมต่อ Snowflake MCP ให้ทีม ให้สร้างเอเจนต์ที่กำหนดเอง ทุกคนจะใช้คำสั่งและคำจำกัดความของตัวชี้วัดชุดเดียวกัน และมีที่เดียวสำหรับถามคำถาม โดยแต่ละคนยังเข้าสู่ระบบด้วยข้อมูลประจำตัว Snowflake ของตนเอง หากต้องการถามคำถามของตัวเองเท่านั้น ให้เชื่อมต่อ Snowflake MCP กับ Notion Agent จะใช้ทั้ง 2 แบบก็ได้
ถ้าเชื่อมต่อ Snowflake กับ Notion Agent แล้ว จะเชื่อมต่อกับเอเจนต์ที่กำหนดเองของทีมด้วยไหม?
ถ้าเชื่อมต่อ Snowflake กับ Notion Agent แล้ว จะเชื่อมต่อกับเอเจนต์ที่กำหนดเองของทีมด้วยไหม?
ไม่ การเชื่อมต่อทั้ง 2 อย่างแยกกัน และเอเจนต์ที่กำหนดเองแต่ละตัวต้องมีการเชื่อมต่อของตัวเอง การตั้งค่า Snowflake ในขั้นตอนที่ 1–10 ใช้ร่วมกันได้ แต่ต้องลงชื่อเข้าใช้แยกกัน
ทุกคนในทีมเห็นข้อมูลเดียวกันไหม?
ทุกคนในทีมเห็นข้อมูลเดียวกันไหม?
ไม่ แต่ละคนลงชื่อเข้าใช้ Snowflake ด้วยข้อมูลประจำตัวของตัวเอง และเอเจนต์จะเข้าถึงได้เฉพาะข้อมูลที่บัญชีนั้นเข้าถึงได้ เอเจนต์ที่กำหนดเองก็เช่นกัน
ต้องแชร์รหัสผ่าน Snowflake กับทีมไหม?
ต้องแชร์รหัสผ่าน Snowflake กับทีมไหม?
ไม่ ไม่ต้องแชร์ข้อมูลประจำตัว พื้นที่ทำงานจะเก็บรายละเอียดไคลเอ็นต์ OAuth ไว้ครั้งเดียว แล้วแต่ละคนลงชื่อเข้าใช้ Snowflake ด้วยตัวเอง
