Agentforce Data Readiness Checklist

Agentforce data readiness वह स्थिति है जिसमें आपके Salesforce records complete, consistent, valid, fresh, deduplicated, और exposed PII से मुक्त होते हैं, ताकि AI agents accurate context retrieve करें और trustworthy responses generate करें। आपका डेटा Agentforce के लिए तब तैयार है जब उन छह में से हर शर्त मापी जाए और एक परिभाषित threshold पर खरी उतरे, मान न ली जाए। यह checklist आपको verify करने के लिए items देती है, हर एक के मायने रखने का कारण, और वह DQS metric जो इसे मापती है।

Agentforce agents Salesforce records retrieve करते हैं, CRM data में grounded responses generate करते हैं, और users की ओर से actions लेते हैं। उन हर step में आपका डेटा source of truth के रूप में पढ़ा जाता है। यदि कोई field blank है, तो agent के पास कोई context नहीं है। यदि कोई value चार तरह से spell की गई है, तो agent इसे चार facts मानता है। यदि एक Case comment में Social Security Number है, तो agent इसे surface कर सकता है। Readiness का मतलब है उन gaps को deployment से पहले बंद करना, न कि production में किसी agent के गलत जवाब देने के बाद। इस list के पीछे की पूरी phased योजना के लिए, Agentforce Preparation देखें।

आप कैसे जानें कि आपका Salesforce डेटा Agentforce के लिए तैयार है?

आप मापकर जानते हैं, हाथ से records inspect करके नहीं। हर उस object पर एक DQS scan चलाएँ जिसे agent access करेगा, फिर हर metric की तुलना एक target threshold से करें। नीचे के छह क्षेत्रों पर काम करें। हर checkbox कुछ ऐसा है जिसे आप एक scan result के साथ verify कर सकते हैं, इसलिए “क्या मेरा डेटा तैयार है” का जवाब एक राय के बजाय एक संख्या बन जाता है।

Measuring step वह है जिसे अधिकांश organizations छोड़ते हैं। Accenture के AI-ready data पर research में, 61% CXOs ने माना कि उनके data assets अभी भी generative AI के लिए तैयार नहीं हैं, और केवल 7% companies ने advanced AI को scale करने के लिए आवश्यक data readiness के स्तर तक पहुँचा था। एक checklist जिसे scan results के विरुद्ध verify किया गया है वह है कि आप पता लगा सकते हैं कि आप उस line के किस तरफ हैं।

checklist को अपने project notes में copy करें और जैसे-जैसे आप items की पुष्टि करें, उन्हें check करें।

Scope और Access

कुछ भी मापने से पहले define करें कि agent किसे touch करता है। एक agent जो गलत objects पढ़ता है वह fail होता है चाहे आपके org का बाकी हिस्सा कितना भी clean हो।

• हर उस object को list करें जिसे Agentforce पढ़ेगा या लिखेगा। Agent केवल वही retrieve करता है जिसकी उसके topics और actions अनुमति देते हैं। अपने scans को ठीक उसी set तक scope करें ताकि आप वही डेटा मापें जिसे agent असल में देखता है।
• हर object के भीतर उन fields को list करें जिन्हें agent responses के लिए उपयोग करता है। Description, Comments, Notes, और key picklists context carry करते हैं। सभी fields scan करना effort बर्बाद करता है; उन्हें scan करें जो answers को ground करते हैं।
• पुष्टि करें कि field-level security intent से match करती है। एक agent running user की access inherit करता है। User से छुपा हुआ field agent के लिए अदृश्य होता है, इसलिए एक “missing” answer कभी-कभी एक permission gap होता है, data gap नहीं।
• Record करें कि कौन से integrations उन fields में लिखते हैं। Integrations inconsistent और duplicated values का सबसे आम स्रोत हैं। writers को जानना आपको बताता है कि intake को कहाँ fix करना है, सिर्फ डेटा को नहीं।

Completeness

जब agent जिन fields को पढ़ता है वे empty होते हैं तो agents vague responses generate करते हैं। Completeness मापने वाली पहली चीज है क्योंकि missing context कमजोर agent output का सबसे आम कारण है।

• agent जिन हर field को responses के लिए उपयोग करता है उन पर Completeness Rate 85% या उससे अधिक है। एक blank Description agent को एक answer ground करने के लिए कुछ नहीं देता। Completeness Rate उन records का प्रतिशत report करती है जहाँ field में एक value है।
• Critical context fields में किसी एक स्रोत से कोई systemic blanks नहीं हैं। एक integration द्वारा खाली छोड़ा गया field एक process fix है, record-by-record cleanup नहीं। Field-level Completeness Rate स्रोत को isolate करती है।
• Required-for-the-business fields populated हैं, भले ही schema में required न हों। Agentforce एक blank field को fact की अनुपस्थिति मानता है। DQS कैसे per object “should be filled” को scope करता है इसके लिए Completeness देखें।

Consistency और Validity

जब वही real-world value कई रूपों में दिखाई देती है, तो agent हर एक को distinct मानता है और inconsistently जवाब देता है। जब कोई value अपने expected format को तोड़ती है, तो downstream retrieval unreliable हो जाता है।

• picklist और reference fields पर Conformance Rate 90% या उससे अधिक है। एक Country field जिसमें “US”, “USA”, और “United States” हो, एक fact को तीन में बाँट देता है। Conformance Rate आपके canonical set से match करने वाली values का प्रतिशत report करती है। मौजूदा variants discover करने के लिए Import from Field का उपयोग करें, फिर canonical values define करें। Consistency देखें।
• formatted fields पर Validity Rate 90% या उससे अधिक है। बिना @ वाला email, अक्षरों वाला phone number, या असंभव date ऐसा data है जिस पर agent कार्य नहीं कर सकता — वह न भेज सकता है, न call कर सकता है, न schedule कर सकता है। Validity Rate आपके format rules पास करने वाली values का प्रतिशत report करती है। Validity देखें।
• Cross-field contradictions हल हो गए हैं। एक Billing State जो अपने Billing Country का विरोधाभास करती है, agent को एक false relationship सिखाती है। Consistency checks उन values को surface करती हैं जो आपस में असहमत होती हैं।

Freshness और Duplicates

Stale data answers को ऐसे facts में ground करता है जो अब सच नहीं हैं। Duplicate records agent को एक entity के दो versions देते हैं, इसलिए response इस पर निर्भर करता है कि यह कौन सी copy retrieve करता है।

• date-sensitive fields पर Timeliness Rate आपके target पर खरी उतरती है। दो साल पुराना Last Activity या अतीत में एक Close Date agent को भटकाता है। Timeliness Rate आपकी परिभाषित window के भीतर current records का प्रतिशत report करती है। Timeliness देखें।
• agent जिन objects को पढ़ता है उन पर Duplicate Rate कम है। जब agent एक ही customer के तीन records में से एक retrieve करता है, तो यह partial history से जवाब देता है। Duplicate Rate उन records का प्रतिशत report करती है जो किसी अन्य की duplicate हैं। Uniqueness देखें।
• deployment से पहले duplicates को merge या flag करें, बाद में नहीं। forms, imports, और manual entry में बने duplicates monitoring के बिना multiply होते हैं। इन्हें हल करें ताकि agent प्रति entity एक record पढ़े।

PII और Compliance

एक agent जिन text fields को पढ़ता है उनमें PII AI context में enter करती है और एक generated response में दिख सकती है। यह वह क्षेत्र है जहाँ एक readiness gap एक compliance incident बन जाता है।

• agent जिन text fields को access करता है उन पर PII Exposure Rate 1% से नीचे है। SSNs और credit-card numbers copy-paste और email-to-case के माध्यम से Description, Comments, और Notes में accumulate होते हैं। PII Exposure Rate एक pattern match वाले records का प्रतिशत report करती है। PII Detection देखें।
• Case Description और Comments पर शून्य SSN या credit-card matches। Financial PII सबसे उच्च-severity finding है। इसे isolate करने के लिए Critical preset scan चलाएँ, फिर confirmed matches को mask, delete, या exclude करें।
• expected-content fields के लिए per-field pattern overrides configured हैं। एक Email field design से email pattern से match करता है, जो noise है, exposure नहीं। Per-field overrides उस noise को हटाते हैं ताकि rate real risk दर्शाए।
• Compliance team ने post-remediation PII scan पर sign off कर दिया है। GDPR, CCPA, HIPAA, और PCI DSS को PII की पहचान और सुरक्षा की आवश्यकता होती है। DQS पूरी तरह Salesforce के अंदर चलता है, इसलिए detection के दौरान कोई records org से बाहर नहीं जाते। Agentforce PII Compliance देखें।

Operations और Monitoring

जैसे-जैसे users नए records enter करते हैं, data quality degrade होती है। एक dataset जो आज pass होता है, हफ्तों के भीतर नई समस्याएँ accumulate करता है, इसलिए readiness एक ऐसी स्थिति है जिसे आप बनाए रखते हैं, एक milestone नहीं जिसे आप एक बार पार करते हैं।

• scope में हर dimension के लिए baseline metrics documented हैं। आपको शुरुआती संख्याओं की जरूरत है यह साबित करने के लिए कि remediation काम कर गई और बाद में regression detect करने के लिए।
• एक recurring scan schedule configured है। Scheduled scans एक one-time snapshot को एक trend line में बदल देती हैं। high-volume text objects पर PII साप्ताहिक चलाएँ, completeness और consistency मासिक, और एक full scan त्रैमासिक।
• प्रति dimension remediation ownership assigned है। एक metric जिसका कोई owner नहीं है वह सुधरता नहीं। completeness, PII, और इसी तरह के लिए जिम्मेदार व्यक्ति को नामित करें।
• remediated data के विरुद्ध agent responses test किए गए हैं। एक passing scan अच्छे behavior की भविष्यवाणी करता है; एक test इसकी पुष्टि करता है। verify करें कि outputs accurate हैं और generated content में कोई PII नहीं दिखती।

Readiness Thresholds एक नजर में

हर क्षेत्र के लिए pass criteria के रूप में इस table का उपयोग करें। targets Agentforce Preparation योजना से match करते हैं।

अगर मेरा org कई items में fail होता है तो क्या?

एक failing checklist अपेक्षित शुरुआती बिंदु है, देरी करने का कारण नहीं। अधिकांश orgs पहले scan पर ऐसी समस्याएँ खोजते हैं जिनकी उन्हें expect नहीं थी। इस क्रम में prioritize करें: पहले PII, क्योंकि यह compliance risk उठाती है; फिर completeness और consistency, क्योंकि वे agent context की quality को आकार देती हैं; फिर validity, timeliness, और uniqueness। पहले सबसे उच्च-impact, सबसे कम-effort वाले items fix करें, scan rerun करें, और अपने baseline से तुलना करें। एक step-by-step remediation path के लिए, Agentforce के लिए Salesforce Data Cleanup और Agentforce Agents क्यों Fail होते हैं देखें।

अगले कदम

• Agentforce Preparation: इस checklist के पीछे की पूरी phased readiness योजना
• Agentforce के लिए Salesforce Data Cleanup: failing items को कैसे remediate करें
• PII Detection: agents जिन fields को पढ़ते हैं उनके लिए PII scanning configure करें
• Agentforce Agents क्यों Fail होते हैं: कमजोर agent output के पीछे की data समस्याएँ
• Agentforce Data Quality FAQ: सामान्य readiness सवालों के त्वरित जवाब
• Salesforce में Data Quality कैसे मापें: Data Quality Score विस्तार से
• AI Readiness Assessment: अपना current readiness score प्राप्त करें