Salesforce Headless 360 پھیل گیا—agent کو ہزاروں APIs نہیں دکھیں گی

Salesforce نے 25 اگست 2026 کو Headless 360 کو اپنے بڑے clouds اور developer platform تک وسیع کرنے کا اعلان کیا۔ Salesforce کے ایشیا پیسفک اعلان میں Headless 360 MCP Server کو open beta، Headless Experience Layer کو open beta اور 100 سے زیادہ reusable Skills کی repository کو عمومی طور پر دستیاب بتایا گیا ہے۔

اسی 25 اگست کی توسیع کا عملی نتیجہ یہ ہے کہ MCP-aware agent کو Salesforce کی ہر متعلقہ feature، object، workflow یا underlying API الگ tool کے طور پر نہیں دکھانی پڑتی۔ TechTarget کی آزاد رپورٹ توسیع اور Headless 360 MCP Server کے open-beta status کی تصدیق کرتی ہے، مگر ساتھ یہ بھی واضح کرتی ہے کہ زیادہ بااختیار agents کی governance ایک بنیادی مسئلہ رہے گی۔

چار tools، activation اور permissions کا اصل model

Headless 360 کی developer reference کے مطابق platform/headless-360 server ہزاروں Salesforce features کو الگ tools بنانے کے بجائے چار مستقل tools کے پیچھے operations کی بڑھتی ہوئی library رکھتا ہے۔ اسی دستاویز میں API version 67.0 یا بعد کی version، mcp_api scope والی External Client App، OAuth authentication اور production و sandbox کے الگ endpoints درج ہیں۔

• Discover agent کی سمجھی ہوئی درخواست پر available operations کے index میں semantic search کرکے موزوں candidates کی درجہ بند فہرست دیتا ہے۔
• Describe منتخب operation کا technical contract، parameters، dependencies، متعلقہ APIs اور ordered steps واپس کرتا ہے۔
• Dispatch operation کو درست endpoint تک پہنچاتا اور چلنے سے پہلے access guard نافذ کرتا ہے۔
• Dispatch Read-Only صرف معلومات حاصل کرنے والا operation چلاتا ہے اور data یا configuration تبدیل نہیں کرتا۔

اس model میں APIs ختم نہیں ہوتیں؛ وہ agent کی ابتدائی tool list سے پس منظر میں چلی جاتی ہیں۔ عنوان میں “ہزاروں APIs نہیں دکھیں گی” اسی نتیجے کی مختصر تعبیر ہے: Salesforce کی دستاویز زیادہ درست طور پر “ہزاروں features” کو individual tools کے طور پر expose نہ کرنے کی بات کرتی ہے، جبکہ Describe ضرورت کے وقت متعلقہ APIs کی تفصیل سامنے لاتا ہے۔

Administrator کو Setup میں MCP Servers کھول کر headless-360 entry فعال کرنی ہوتی ہے۔ ہر transaction authenticated Salesforce user کے طور پر چلتی ہے، اس لیے object-level CRUD permissions، field-level security، sharing rules، profile permissions اور permission sets نافذ رہتے ہیں؛ اسی identity سے Salesforce میں ممنوع action agent بھی نہیں چلا سکتا۔ ہر مکمل action کی attribution اسی user کے audit trail میں ہوتی ہے۔

Read-only آغاز اور write approval کیوں الگ رہنے چاہییں

Server صرف records پڑھنے کے لیے نہیں ہے۔ دستیاب operation کے مطابق agent records بنا یا update کر سکتا، users کو create، deactivate یا freeze کر سکتا، permission sets دے سکتا، Apex triggers لکھ اور deploy کر سکتا، named credentials بنا سکتا اور event-driven integrations ترتیب دے سکتا ہے۔ اسی لیے OAuth login کامیاب ہونا محفوظ deployment کا مکمل معیار نہیں؛ اصل حد authenticated identity کی مجموعی permissions اور MCP client کی tool policy مل کر بناتی ہیں۔

محفوظ activation کے لیے ایک محدود ترتیب بنتی ہے۔ یہ Salesforce کے اندر کسی نئی approval engine کا دعویٰ نہیں بلکہ documented permission model اور client-level approval guidance کو deployment checklist میں تبدیل کرتی ہے:

1. Headless 360 کو پہلے sandbox یا Developer org میں فعال کریں اور کم سے کم اختیار والی test identity استعمال کریں۔
2. ابتدائی sessions میں Discover، Describe اور Dispatch Read-Only تک رسائی رکھیں، پھر واپس آنے والے operation، parameters اور درکار permissions کا جائزہ لیں۔
3. Record creation، deletion، user administration، Apex deployment یا configuration change سے پہلے MCP client میں انسانی منظوری لازم کریں۔
4. External Client App کا mcp_api scope، user profile، permission sets، sharing access اور field-level security الگ الگ جانچیں۔
5. منظور شدہ write کے بعد audit trail میں user attribution اور متعلقہ تبدیلی کی پڑتال کریں؛ غیر متوقع operation سامنے آئے تو write access روک دیں۔

Audit trail بعد میں بتا سکتا ہے کہ action کس user کے نام سے چلا، لیکن وہ پیشگی approval کا متبادل نہیں۔ Logging واقعہ محفوظ کرتی ہے؛ client restriction نقصان دہ یا غلط write کو execution سے پہلے روک سکتی ہے۔ وسیع admin permissions والے account کے ساتھ blanket auto-approval اس فرق کو ختم کردیتا ہے۔

Headless 360 کی توسیع کا مطلب کیا ہے—اور کیا نہیں

Salesforce کا بڑا دعویٰ platform capabilities کو روایتی application interface سے نکال کر authorized agents، applications اور دوسرے experiences کے لیے reusable بنانا ہے۔ Marketing، Sales، Service، Commerce، MuleSoft، Informatica اور Tableau سمیت بڑے platform حصے اس سمت میں شامل ہیں، لیکن ہر component کا release status ایک جیسا نہیں۔ Headless 360 MCP Server کا open beta ہونا کسی دوسرے MCP server یا Headless 360 کے ہر حصے کو beta نہیں بناتا۔

Headless 360 MCP Server کو Data 360 MCP Server کا دوسرا نام بھی نہیں سمجھنا چاہیے۔ Data 360 server مخصوص Data 360 data اور operations کے لیے ہے، جبکہ Headless 360 server وسیع Salesforce Setup اور platform capabilities کو ایک connection سے دریافت اور dispatch کرنے کے لیے بنایا گیا ہے۔ Configuration review میں یہ فرق نظرانداز ہو تو ٹیم دستیاب data، operations اور permissions کے بارے میں غلط توقع قائم کرسکتی ہے۔

چار-tool surface کا فائدہ scalability ہے، خودکار حفاظت نہیں۔ Operations library بڑھ سکتی ہے جبکہ agent کے بنیادی tools چار رہیں، مگر ہر نئی discoverable capability authenticated user کی موجودہ authority کے اندر ایک نیا ممکنہ action بھی بن سکتی ہے۔ اس لیے کم tool count کو کم privilege کے برابر سمجھنا درست نہیں۔

Open beta کی موجودہ حد

Headless 360 MCP Server جولائی 2026 سے Beta Service کے طور پر دستیاب ہے اور 25 اگست کے platform اعلان کے وقت open beta میں تھا؛ یہ عمومی دستیابی نہیں۔ Beta launch پر dozens of operations موجود تھے اور زیادہ تر Setup کے انتظامی کاموں پر مرکوز تھے۔ Library ہر release کے ساتھ بڑھنے کی توقع ہے، مگر platform-wide توسیع کا مطلب یہ نہیں کہ ہر cloud کا ہر business action ابھی Discover میں ملے گا۔

عملی coverage موجودہ operations index، org configuration، product entitlement اور authenticated user کی permissions کے امتزاج سے طے ہوگی۔ Salesforce نے یہ بھی کہا ہے کہ اضافی cloud اور developer capabilities کی availability product کے لحاظ سے مختلف ہوسکتی ہے، جبکہ pricing، packaging، region اور customer agreement بھی رسائی پر اثر ڈال سکتے ہیں۔

فی الحال تصدیق شدہ حالت یہ ہے کہ server open beta میں ہے، چار tools سے operation discovery اور execution مہیا کرتا ہے، read-only dispatch کو write execution سے الگ رکھتا ہے اور Salesforce کی موجودہ user permissions نافذ کرتا ہے۔ اگلی اہم معلومات operations coverage، پاکستان سمیت علاقائی availability، packaging اور عمومی دستیابی کی تاریخ ہوں گی؛ ان کے بغیر platform-wide سمت کو ہر Salesforce org کے لیے یکساں عملی دستیابی نہیں سمجھا جاسکتا۔

یہ بھی پڑھیں:

• Claude AI صرف chatbot نہیں: کام، coding اور منصوبوں کی اصل حدیں
• OpenAI کا AI sandbox سے نکل گیا: Hugging Face واقعے کے اصل سبق
• Claude کا پوشیدہ watermark ثبوت نہیں: ترجمہ اسے کمزور کر سکتا ہے