Salesforce Open Badges: CRM ट्रिगर से सत्यापन-योग्य Credentials जारी करें

ज़्यादातर ट्रेनिंग टीमें पहले से ही Salesforce में दर्ज करती हैं कि किसने क्या पूरा किया। कोर्स एनरोलमेंट “Completed” हो जाता है, कोई पार्टनर अकाउंट सर्टिफिकेशन टियर तक पहुँच जाता है, कोई ग्राहक ऑनबोर्डिंग पूरी कर लेता है। रिकॉर्ड बदल जाता है, और फिर एक हफ़्ते बाद कोई सूची एक्सपोर्ट करके हाथ से सर्टिफिकेट ईमेल करता है।

यह गाइड बताती है कि इस अंतर को कैसे ख़त्म करें: जब कोई रिकॉर्ड आपके मनचाहे स्टेटस पर पहुँचता है, Salesforce https://badges.ninja API को कॉल करता है, एक Open Badge v2.0 credential जारी होता है, और सत्यापन लिंक रिकॉर्ड में वापस सेव हो जाता है। फिर आप उस लिंक को ईमेल टेम्पलेट, रिपोर्ट या Experience Cloud पेज में इस्तेमाल कर सकते हैं।

आपको चाहिए: एक Salesforce एडमिन (या डेवलपर सैंडबॉक्स), https://badges.ninja पर पहले से डिज़ाइन किया हुआ एक badge, और एक API key। अगर आपने पहले कभी API कॉल नहीं की है, तो पहले API quickstart पढ़ें; इसमें दस मिनट लगते हैं।

CRM ट्रिगर कब सही औज़ार है

Apex लिखने से पहले जाँच लें कि आपको उसकी ज़रूरत है भी या नहीं। अगर आप सत्र में एक बार या तिमाही में एक बार बैच में credentials जारी करते हैं, तो डैशबोर्ड का CSV अपलोड ज़्यादा तेज़ है और उसमें कोई कोड नहीं लगता। Salesforce वाला रास्ता तब काम आता है जब:

• रिकॉर्ड बदलते ही बिना किसी मानवीय कदम के जारी करना हो।
• “किसने कमाया” वाला डेटा पहले से Salesforce में है और आप दूसरा सोर्स ऑफ़ ट्रुथ नहीं चाहते।
• आप रिपोर्टिंग के लिए credential लिंक को Contact, Lead या कस्टम ट्रेनिंग रिकॉर्ड पर सेव करना चाहते हैं।

अगर आपका वर्कफ़्लो टूल Apex की जगह Zapier है, तो वही API कॉल वहाँ भी चलती है; देखें Zapier Open Badges automation।

आप क्या बना रहे हैं

इस फ़्लो में चार हिस्से हैं:

1. एक badge जो विज़ुअल डिज़ाइनर में बना हो। उसका id कॉपी करें (GET /badges से मिलने वाला id)।
2. एक API key जो आपके डैशबोर्ड के API Keys पेज पर बनी हो। key सिर्फ़ एक बार दिखती है, इसलिए तुरंत सुरक्षित रख लें।
3. Salesforce में एक Named Credential जो key को रखे, ताकि वह कोड में कभी दिखाई न दे।
4. एक Apex trigger और एक Queueable क्लास जो award जारी करे और award लिंक को रिकॉर्ड में वापस लिखे।

चरण 1: key को Named Credential में रखें

Apex में API key को हार्ड-कोड करना वह ग़लती है जिससे बचना चाहिए। Setup में कस्टम हेडर के साथ एक External Credential बनाएँ, फिर API होस्ट की ओर इशारा करने वाला एक Named Credential बनाएँ:

• URL: https://api.badges.ninja
• Custom header name: X-Api-Key
• Custom header value: आपकी key, इस रूप में bws_YOUR_KEY_HERE
• Named Credential name: BadgesNinja

जो permission set आपकी ऑटोमेशन चलाता है, उसे External Credential के principal का एक्सेस दें। Named Credential होने पर अलग से Remote Site Setting की ज़रूरत नहीं होती; Salesforce credential के ज़रिए callout को अधिकृत करता है। अगर आपका org अब भी legacy Named Credentials या सादा endpoint इस्तेमाल करता है, तो https://api.badges.ninja को Remote Site Setting के रूप में जोड़ें और हेडर कोड से भेजें।

चरण 2: रिकॉर्ड में फ़ील्ड जोड़ें

जो ऑब्जेक्ट उपलब्धि को दर्शाता है (हम Training_Enrollment__c नाम का एक कस्टम ऑब्जेक्ट इस्तेमाल करेंगे), उसमें ये जोड़ें:

• Badge_Id__c (Text): जारी किया जाने वाला badge। इसे हर कोर्स के हिसाब से सेव करने पर एक ही trigger कई badges सँभाल लेता है।
• Badge_Award_Id__c (Text, unique): API से मिला award id।
• Badge_Url__c (URL): सार्वजनिक सत्यापन पेज।
• Badge_Error__c (Long Text): आख़िरी त्रुटि, ताकि एडमिन डीबग लॉग खोले बिना विफलताएँ देख सकें।

Badge_Award_Id__c फ़ील्ड दोहरा काम करता है। यह आपका डुप्लिकेट गार्ड है: trigger तभी जारी करता है जब यह ख़ाली हो।

चरण 3: Apex callout

Trigger सीधे callout नहीं कर सकता, क्योंकि जिस ट्रांज़ैक्शन में uncommitted DML हो, उसमें callouts की अनुमति नहीं होती। काम को ऐसे Queueable को सौंप दें जो Database.AllowsCallouts लागू करता हो।

POST /awards का API कॉन्ट्रैक्ट छोटा है। बॉडी में badgeId, name और email वाला एक नेस्टेड recipient ऑब्जेक्ट, और अनिवार्य issuedOn होता है। सफल कॉल HTTP 200 के साथ { "awardId": "..." } लौटाती है। प्राप्तकर्ता का नाम कम से कम पाँच अक्षरों का होना चाहिए, इसलिए “Al Li” नाम का Contact अस्वीकार हो जाएगा; कॉल करने से पहले सत्यापन कर लें।

public class BadgeIssueJob implements Queueable, Database.AllowsCallouts {
    private Id enrollmentId;
    public BadgeIssueJob(Id enrollmentId) { this.enrollmentId = enrollmentId; }

    public void execute(QueueableContext ctx) {
        Training_Enrollment__c e = [
            SELECT Id, Badge_Id__c, Badge_Award_Id__c, Contact__r.Name, Contact__r.Email
            FROM Training_Enrollment__c WHERE Id = :enrollmentId LIMIT 1
        ];
        if (e.Badge_Award_Id__c != null) { return; }   // already issued

        Map<String, Object> recipient = new Map<String, Object>{
            'name' => e.Contact__r.Name,
            'email' => e.Contact__r.Email
        };
        Map<String, Object> body = new Map<String, Object>{
            'badgeId' => e.Badge_Id__c,
            'recipient' => recipient,
            'issuedOn' => Datetime.now().getTime()
        };

        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:BadgesNinja/awards');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');
        req.setBody(JSON.serialize(body));

        HttpResponse res = new Http().send(req);
        if (res.getStatusCode() == 200) {
            Map<String, Object> out = (Map<String, Object>) JSON.deserializeUntyped(res.getBody());
            String awardId = (String) out.get('awardId');
            e.Badge_Award_Id__c = awardId;
            e.Badge_Url__c = 'https://badges.ninja/awards/' + awardId;
            e.Badge_Error__c = null;
        } else {
            e.Badge_Error__c = res.getStatusCode() + ': ' + res.getBody();
        }
        update e;
    }
}

दो बातें ध्यान देने लायक हैं। पहली, issuedOn epoch मिलीसेकंड में है, और Datetime.getTime() ठीक यही लौटाता है। दूसरी, रिस्पॉन्स में सत्यापन URL शामिल नहीं होता, इसलिए कोड उसे award id से बनाता है: https://badges.ninja/awards/<awardId>।

चरण 4: Trigger

Trigger को पतला रखें। वह सिर्फ़ यह तय करता है कि कौन-से रिकॉर्ड योग्य हैं और हर रिकॉर्ड के लिए एक job enqueue करता है।

trigger TrainingEnrollmentBadge on Training_Enrollment__c (after insert, after update) {
    for (Training_Enrollment__c e : Trigger.new) {
        Boolean completed = e.Status__c == 'Completed';
        Boolean wasCompleted = Trigger.isUpdate && Trigger.oldMap.get(e.Id).Status__c == 'Completed';
        if (completed && !wasCompleted && e.Badge_Award_Id__c == null && e.Badge_Id__c != null) {
            System.enqueueJob(new BadgeIssueJob(e.Id));
        }
    }
}

wasCompleted की जाँच ज़रूरी है। इसके बिना, पूरे हो चुके रिकॉर्ड में बाद का कोई भी बदलाव लॉजिक को दोबारा चला देगा। job के अंदर ख़ाली award id वाले गार्ड के साथ मिलकर, एक रिकॉर्ड कभी भी सिर्फ़ एक credential ही बना सकता है।

एक सीमा का ध्यान रखें: Salesforce एक ट्रांज़ैक्शन से थोड़े ही Queueable jobs enqueue करने देता है (synchronous संदर्भ में 50)। अगर आप बड़ी संख्या में completions लोड करते हैं, जैसे 2,000 पंक्तियों का डेटा इंपोर्ट, तो ऊपर वाला trigger इस सीमा से टकरा जाएगा। बल्क लोड के लिए या तो सूची को डैशबोर्ड के CSV बल्क awards से अपलोड करें, या Database.AllowsCallouts वाली Batchable क्लास अपनाएँ जो हर scope में कुछ ही रिकॉर्ड प्रोसेस करे।

त्रुटि प्रबंधन और रीट्राई

API मानक स्टेटस कोड लौटाती है, और हर कोड पर आपके कोड को अलग तरह से प्रतिक्रिया देनी चाहिए:

क्योंकि job त्रुटि को रिकॉर्ड में लिखता है और Badge_Award_Id__c को ख़ाली छोड़ देता है, रीट्राई उतना ही आसान है जितना एक चेकबॉक्स पलटना या रिकॉर्ड दोबारा सेव करना। एक छोटी शेड्यूल्ड Apex क्लास, जो बिना award id और अस्थायी त्रुटि वाले completed enrollments ढूँढकर उन्हें दोबारा enqueue करे, बिना किसी अतिरिक्त इन्फ्रास्ट्रक्चर के आपको स्वचालित रीट्राई कतार दे देती है। प्रयासों की सीमा एक काउंटर फ़ील्ड से तय करें ताकि स्थायी रूप से ख़राब रिकॉर्ड हमेशा लूप में न चलता रहे।

इसे प्रोडक्शन से जोड़ने से पहले अपना प्लान जाँच लें। Free प्लान साल में 1,200 credentials देता है; Starter $9 प्रति माह और Pro $29 प्रति माह है। हर Lead पर चलने वाला trigger छोटे प्लान को जल्दी ख़त्म कर देगा, इसलिए मानदंड को असली उपलब्धियों तक सीमित रखें।

Salesforce में credential को दिखाई देने योग्य बनाना

Badge_Url__c भर जाने के बाद आप इसे कहीं भी इस्तेमाल कर सकते हैं:

• ईमेल अलर्ट और टेम्पलेट: इस फ़ील्ड को “बधाई हो, यह रहा आपका credential” ईमेल में मर्ज करें।
• रिपोर्ट: Badge_Award_Id__c != null पर बनी रिपोर्ट आपको कोर्स, क्षेत्र या अकाउंट ओनर के हिसाब से जारी की गई संख्या देती है।
• Experience Cloud: पार्टनर के सर्टिफिकेशन पेज पर लिंक दिखाएँ ताकि ख़रीदार ख़ुद उसे सत्यापित कर सकें।
• पेज लेआउट: URL फ़ील्ड जोड़ें ताकि सपोर्ट स्टाफ़ “क्या उन्हें उनका badge मिला?” का जवाब एक नज़र में दे सके।

सत्यापन पेज सार्वजनिक है और इसके लिए साइनअप की ज़रूरत नहीं, और यही इसका पूरा मक़सद है। प्राप्तकर्ता, हायरिंग मैनेजर या ग्राहक की प्रोक्योरमेंट टीम लिंक खोलकर पुष्टि कर सकती है कि credential किसने जारी किया, वह क्या प्रमाणित करता है, और कब। मशीन-पठनीय जाँच के लिए, किसी भी award का Open Badge v2.0 JSON-LD https://api.badges.ninja/certify-badge/award/<awardId> पर उपलब्ध है।

प्राप्तकर्ताओं को सामान्य अतिरिक्त सुविधाएँ भी मिलती हैं: एक अनूठा सत्यापन URL, QR कोड, A4 PDF सर्टिफिकेट, और प्राप्तकर्ता पोर्टल से Add to LinkedIn का विकल्प, जिसमें साइन-इन पासवर्ड से नहीं बल्कि magic link से होता है।

यह AppExchange badge प्लगइन से बेहतर क्यों है

AppExchange के badge प्लगइन आमतौर पर प्रति Salesforce सीट या managed-package लाइसेंस के हिसाब से महँगे होते हैं। वह लागत आपकी Salesforce टीम के आकार के साथ बढ़ती है, जारी किए गए credentials की संख्या के साथ नहीं, इसलिए दस लोगों की ट्रेनिंग टीम और दस हज़ार learners वाला प्रोग्राम एक ही नतीजे के लिए बहुत अलग क़ीमत चुकाते हैं।

API इंटीग्रेशन यह मॉडल पलट देता है। आप एक फ़्लैट प्लान पर credential की मात्रा के हिसाब से भुगतान करते हैं, trigger कोड आपका है जिसे आप पढ़ और बदल सकते हैं, और आउटपुट मानक Open Badge v2.0 है, इसलिए प्राप्तकर्ता किसी प्रोप्राइटरी व्यूअर में बँधे नहीं रहते। डिज़ाइन की आज़ादी भी आपके पास रहती है: विज़ुअल डिज़ाइनर में 80+ टेम्पलेट, शेप, आइकन और कस्टम अपलोड मिलते हैं, किसी पैकेज के अंदर तय लेआउट नहीं।

ईमानदार समझौता: प्लगइन क्लिक करके इंस्टॉल हो जाता है और उसमें Apex की ज़रूरत नहीं होती। अगर आपकी टीम में कोई कुछ दर्जन पंक्तियों का कोड सँभाल नहीं सकता, तो प्लगइन या no-code कनेक्टर बेहतर विकल्प हो सकता है। अगर आप इंटीग्रेशन की जगह सामान्य रूप से प्लेटफ़ॉर्म की तुलना कर रहे हैं, तो Credly alternative में क़ीमत और फ़ीचर के अंतर साथ-साथ दिए गए हैं।

लाइव जाने से पहले टेस्ट करना

पूरा फ़्लो पहले सैंडबॉक्स में चलाएँ।

1. एक टेस्ट badge और ऐसे ईमेल पते वाला टेस्ट प्राप्तकर्ता बनाएँ जो आपके नियंत्रण में हो।
2. Apex टेस्ट में HttpCalloutMock लागू करें जो स्टेटस 200 और {"awardId":"test-award-id"} लौटाए; Salesforce टेस्ट संदर्भ में असली callouts की अनुमति नहीं देता, और डिप्लॉय करने के लिए आपको यह कवरेज चाहिए।
3. सैंडबॉक्स में एक enrollment को Completed करें और जाँचें कि Badge_Award_Id__c और Badge_Url__c एक मिनट के भीतर भर जाते हैं।
4. URL को प्राइवेट ब्राउज़र विंडो में खोलें और पुष्टि करें कि सार्वजनिक सत्यापन पेज बिना साइन-इन के दिखता है।
5. जानबूझकर विफलता कराएँ (badge id ख़ाली छोड़ें, या पाँच अक्षरों से छोटा प्राप्तकर्ता नाम इस्तेमाल करें) और पुष्टि करें कि त्रुटि Badge_Error__c में आती है।

अगर API key कभी डीबग लॉग या स्क्रीनशॉट में लीक हो जाए तो उसे रोटेट करें। रद्द करना API Keys पेज से तुरंत हो जाता है, और आपको सिर्फ़ External Credential अपडेट करना होता है, कोड नहीं।

समापन

पैटर्न छोटा है: पतला trigger तय करता है कब, Queueable callout करता है, Named Credential key रखता है, और रिकॉर्ड के तीन फ़ील्ड नतीजा सँजोते हैं। यह ट्रेनिंग माइलस्टोन, पार्टनर टियर, इवेंट में उपस्थिति, या Salesforce में व्यक्त की जा सकने वाली किसी भी स्थिति-परिवर्तन के लिए काम करता है।

एक ऑब्जेक्ट और एक badge से शुरू करें, एक हफ़्ते तक देखें, और जब रीट्राई व्यवहार आपके डेटा के अनुकूल लगे तो दायरा बढ़ाएँ।

अपना पहला सत्यापन-योग्य credential जारी करने के लिए तैयार हैं? badges.ninja पर मुफ़्त शुरू करें — विज़ुअल डिज़ाइनर, सार्वजनिक सत्यापन पेज, PDF सर्टिफिकेट, Open Badge v2.0 आउटपुट। क्रेडिट कार्ड की ज़रूरत नहीं।