Widget personalizat in Zoho CRM: cand merita si cum il construiti corect

Un widget personalizat in Zoho CRM merita construit atunci cand utilizatorul trebuie sa vada sau sa foloseasca date din alta aplicatie direct in CRM. Conditia este ca acea interfata sa nu poata fi obtinuta din campuri, layout-uri sau functii native. Daca nevoia tine doar de date sau de reguli, solutia nativa este mai simpla si mai ieftin de intretinut.

Un widget este o componenta de interfata incorporabila, pe care o construiti si o adaugati in Zoho CRM. Documentatia Zoho din seria Kaizen despre widgeturi precizeaza ca widgeturile pot executa functii care folosesc date din aplicatii terte. Cu alte cuvinte, un widget aduce o fereastra dintr-un alt sistem in ecranul pe care echipa il foloseste zilnic.

Widgetul se construieste cu JS SDK-ul Zoho, adica o biblioteca JavaScript. Biblioteca va permite sa controlati interfata CRM si sa lucrati cu date in contextul utilizatorului logat. Acest detaliu conteaza: widgetul vede si modifica doar ce are voie sa vada si sa modifice persoana care il deschide.

Ghidul de fata parcurge decizia, verificarile dinainte, instrumentele, un exemplu lucrat cu cod, testarea, publicarea si limitele tehnice. Ultimele doua sectiuni privesc companiile din Romania si pasii urmatori.

Un widget personalizat in Zoho CRM poate aparea in mai multe locuri din interfata, iar alegerea locului decide cum il va folosi echipa. Intrebarile frecvente publicate de Zoho in Kaizen #147 enumera variantele disponibile. Tabelul de mai jos le grupeaza dupa momentul in care widgetul apare.

Loc de plasare	Cand apare	Potrivit pentru
Web tab	Ca fila separata in meniul CRM	Un ecran de lucru complet, folosit des
Buton personalizat	La click pe un buton dintr-o inregistrare	O actiune punctuala pe o fisa anume
Related list personalizat	In fisa inregistrarii, langa celelalte liste	Date asociate aduse din alt sistem
Element de dashboard	Pe pagina de start sau intr-un dashboard	O vedere de ansamblu
Tranzitie Blueprint	Cand o inregistrare trece dintr-o etapa in alta	Date cerute exact la acel pas
Pop-up sau call-out prin Client Script	Cand un script din formular il deschide	Interactiune legata de completarea unui formular
Extensie de telefonie	La click pe pictograma de telefon	O aplicatie terta de apelare

Lista Zoho mai include pagina de setari, notificarile sales signals si componenta wizard. Pentru Client Script, widgetul primeste date prin listenerul Notify si poate trimite date inapoi prin NotifyAndWait. Pentru telefonie, listenerele Dial si DialerActive incarca o aplicatie terta in widget atunci cand organizatia nu are o extensie nativa de telefonie.

Solutiile native ajung ori de cate ori problema tine de ce date pastrati si de reguli, nu de o interfata noua. Un widget personalizat in Zoho CRM devine justificat abia cand utilizatorul trebuie sa interactioneze cu ceva ce CRM-ul nu afiseaza singur. Tabelul de mai jos este un instrument de decizie, nu o regula fixa.

Nevoia	Solutia de incercat intai	Cand trece la widget
O informatie noua pe fisa clientului	Camp personalizat	Informatia traieste in alt sistem si trebuie vazuta in timp real
Ordinea si vizibilitatea campurilor	Layout	Rareori; layout-ul acopera aceasta nevoie
Un calcul sau o actualizare automata	Functie sau regula de workflow	Utilizatorul trebuie sa aleaga sau sa confirme ceva intr-o interfata
Date asociate dintr-o aplicatie terta	Integrare care copiaza datele in CRM	Datele nu trebuie copiate, doar consultate sau modificate la sursa
Apeluri dintr-o centrala fara extensie nativa	Extensie de telefonie din Marketplace	Nu exista extensie pentru furnizorul dumneavoastra

Diferenta de fond este costul de intretinere. Un camp sau un layout se modifica din Setup, de catre un administrator. Un widget este cod: are fisiere, versiuni si dependinte care trebuie urmarite. Orice modificare a scriptului cere un nou pachet si o noua incarcare in CRM.

Prin urmare, alegeti widgetul cand interfata adusa in CRM economiseste efectiv timp echipei. Nu il alegeti doar pentru ca solutia pare mai flexibila.

Inainte de a scrie un widget personalizat in Zoho CRM, merita sa raspundeti in scris la cateva intrebari. Raspunsurile decid locul de plasare, tipul de gazduire si cine poate folosi widgetul. Fiecare intrebare de mai jos elimina o cauza obisnuita de refacere.

1. Problema reala. Ce face utilizatorul azi, pe ce ecran si de cate ori pe zi?
2. Alternativa nativa. Rezolva un camp, un layout, o functie sau o extensie existenta aceeasi nevoie?
3. Sursa datelor. Datele stau in CRM sau intr-o aplicatie terta, si cum sunt accesate?
4. Permisiunile. SDK-ul lucreaza in contextul utilizatorului logat, deci profilul si rolul acestuia limiteaza ce vede widgetul.
5. Locul de plasare. Web tab, buton, related list, dashboard sau tranzitie Blueprint?
6. Gazduirea. Interna, pe serverele Zoho, sau externa, pe un server propriu?
7. Intretinerea. Cine pastreaza codul sursa si cine reincarca pachetul dupa modificari?

La Svennis, inainte de a scrie un widget, ii cerem utilizatorului sa ne arate ecranul pe care lucreaza si incercam intai un camp, un layout sau o functie. Scriem widgetul doar cand nevoia ramane neacoperita, iar cel mai des o vedem gresita atunci cand permisiunile utilizatorilor sunt verificate abia dupa lansare.

Ultimul punct este cel mai des ignorat. Un widget fara proprietar clar ramane in CRM si dupa ce procesul din spatele lui s-a schimbat.

Un widget personalizat in Zoho CRM se construieste cu trei instrumente: JS SDK-ul, linia de comanda zet si consola pentru dezvoltatori. O linie de comanda (CLI) este o interfata text prin care lucrati cu o aplicatie folosind comenzi. Zet este CLI-ul Zoho care construieste si impacheteaza widgeturi pentru Zoho CRM.

Instalarea zet

Zet se instaleaza prin npm, din pachetul zoho-extension-toolkit. Sistemul are nevoie de Node JS 6 sau mai nou. Comanda de instalare este npm install -g zoho-extension-toolkit.

JS SDK-ul in fisierul widgetului

SDK-ul se incarca prin adresa CDN https://live.zwidgets.com/js-sdk/1.2/ZohoEmbededAppSDK.min.js, pusa ca src in tagul head. Prin SDK, widgetul se poate inregistra la evenimente. Inregistrarea unui eveniment inseamna definirea unei functii care ruleaza cand acel eveniment are loc. Exemplele din documentatie sunt PageLoad, la incarcarea paginii de detaliu a unei inregistrari, Dial si DialerActive.

Consola pentru dezvoltatori

Ghidul Zoho Building a Client Side Application numeste developer.zoho.com consola pentru dezvoltatori a Zoho CRM. Acolo configurati un widget care face parte dintr-o extensie. Pentru asta creati un connected app, adica mijlocul prin care integrati Zoho CRM cu alte aplicatii prin API-uri.

Pentru framework, Zoho confirma ca widgeturile pot fi construite cu orice framework client-side, inclusiv React JS. Pentru un widget mic, HTML si JavaScript simplu sunt suficiente.

Exemplul construieste un widget personalizat in Zoho CRM care se deschide dintr-un buton pe fisa unui potential. Widgetul citeste contextul paginii si utilizatorul logat, apoi se inchide dintr-un buton propriu. Este scheletul pe care se adauga ulterior logica reala, de pilda apelul catre un sistem extern.

Primul pas este crearea proiectului cu comanda zet init, din care alegeti "Zoho CRM" din lista de servicii. Comanda initializeaza directorul proiectului si descarca dependintele. Codul de mai jos merge in fisierul HTML principal al proiectului. Calea relativa catre acest fisier este resource path-ul pe care il indicati la configurarea widgetului.

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <script src="https://live.zwidgets.com/js-sdk/1.2/ZohoEmbededAppSDK.min.js"></script>
</head>
<body>
  <p>Widget potential: verificati consola browserului.</p>
  <button onclick="ZOHO.CRM.UI.Popup.close()">Inchide</button>
  <script>
    // Datele paginii (modulul si inregistrarea) sosesc la PageLoad
    ZOHO.embeddedApp.on("PageLoad", function (data) {
      console.log(data);
    });

    // Initializam SDK-ul, apoi citim utilizatorul logat
    ZOHO.embeddedApp.init().then(function () {
      // Intoarce nume, Id, rol, profil
      ZOHO.CRM.CONFIG.getCurrentUser().then(function (data) {
        console.log(data);
      });
    });
  </script>
</body>
</html>

Listenerul PageLoad este inregistrat inainte de initializare, ca sa nu piarda evenimentul. In locul primului console.log veti pune logica proprie, de exemplu afisarea datelor primite pentru inregistrarea curenta. Al doilea console.log poate fi inlocuit cu o verificare de rol sau profil, daca widgetul trebuie sa arate continut diferit pe echipe. Butonul cu ZOHO.CRM.UI.Popup.close() are sens doar cand widgetul se deschide ca pop-up, cum este cazul unui buton personalizat.

Un widget personalizat in Zoho CRM trece prin patru comenzi si o configurare in Setup inainte sa ajunga la utilizatori. Ordinea de mai jos urmeaza documentatia Zoho si evita incarcarea unui pachet cu erori.

1. zet run porneste un server HTTP local, pe portul 5000 indicat de CLI. Testati widgetul folosind adresa primita, inclusiv in sandbox-ul extensiei.
2. zet validate verifica pachetul aplicatiei si identifica incalcarile de reguli. Le corectati inainte de a actualiza arhiva in consola pentru dezvoltatori.
3. zet pack creeaza o arhiva zip a aplicatiei in folderul dist al proiectului. Aceasta arhiva se incarca in CRM.
4. Configurarea in CRM se face din Setup > Developer Space > Widgets. Acolo alegeti tipul de gazduire si incarcati arhiva sau indicati adresa externa.

La gazduirea interna, Zoho CRM gazduieste continutul static al aplicatiei, deci nu aveti nevoie de alt server. Selectati arhiva zip, cu limita de 25 MB. La gazduirea externa, alegeti External din lista Hosting si introduceti adresa site-ului care gazduieste aplicatia.

Dupa publicare, legati widgetul de locul ales, in exemplul de fata un buton personalizat in modulul Potentiale. Testati apoi cu un utilizator care are profilul echipei care il va folosi, nu doar cu administratorul. Diferentele de permisiuni apar abia in acest test.

Un widget personalizat in Zoho CRM are limite de dimensiune fixe, publicate de Zoho. Merita verificate de la inceput, mai ales daca folositi un framework care genereaza multe fisiere. Limitele din intrebarile frecvente Kaizen #147 sunt urmatoarele:

• cel mult 250 de fisiere intr-un proiect de widget;
• cel mult 25 MB pentru intregul proiect;
• cel mult 5 MB pentru fiecare fisier.

Interna sau externa

Ghidul Zoho recomanda gazduirea la Zoho pentru aplicatiile client-side simple. Pentru aplicatii complexe sau pentru integrarea instrumentelor interne prin widgeturi, recomanda gazduirea externa. In cazul unei extensii gazduite extern, specificati un Sandbox URL si un Production URL unde se afla fisierele sursa.

Gazduirea interna inseamna mai putina infrastructura de administrat. In schimb, fiecare modificare inseamna un nou zet pack si o noua incarcare a arhivei. Gazduirea externa permite actualizari pe propriul server, dar adauga un server pe care trebuie sa il intretineti si sa il securizati.

Pentru majoritatea widgeturilor care afiseaza date si apeleaza un serviciu extern, gazduirea interna este punctul de pornire rezonabil. Gazduirea externa se justifica atunci cand widgetul face parte dintr-o aplicatie interna mai mare, pe care o dezvoltati oricum separat.

Pentru o companie din Romania, un widget personalizat in Zoho CRM are sens mai ales cand datele de care are nevoie echipa stau in sisteme locale sau in ERP. Inainte de a comanda cod, verificati daca exista deja o integrare publicata. Multe nevoi frecvente sunt acoperite fara un widget scris de la zero.

Cateva exemple de nevoi locale si de solutii existente:

• datele firmei dupa CUI se pot prelua cu extensia ANAF pentru Zoho CRM, fara cod propriu;
• facturarea si e-Factura se pot lega prin integrarea SmartBill cu Zoho CRM;
• comenzile, stocurile si datele contabile din ERP pot ajunge in CRM prin integrarea SAP Business One cu Zoho CRM.

Widgetul devine util cand o astfel de integrare copiaza datele, dar echipa vrea sa lucreze direct la sursa. Exemple sunt un ecran de configurare de oferta, o fereastra de apelare pentru o centrala telefonica locala sau o lista de documente dintr-un sistem intern.

Mai conteaza cine scrie si cine intretine codul. Daca in companie nu exista un dezvoltator JavaScript, stabiliti de la inceput cine reincarca pachetul dupa o modificare. Stabiliti si cine raspunde cand sistemul extern isi schimba API-ul.

Primul pas pentru un widget personalizat in Zoho CRM este o descriere scrisa a nevoii, nu codul. Notati ecranul, utilizatorii, sursa datelor si locul de plasare din tabelul de mai sus. Apoi treceti nevoia prin tabelul de decizie si eliminati variantele pe care un camp, un layout sau o functie le rezolva deja.

Daca widgetul ramane solutia, urmati aceasta ordine:

1. instalati zet cu Node JS 6 sau mai nou si creati proiectul cu zet init;
2. porniti de la scheletul din exemplul lucrat si adaugati logica pas cu pas;
3. testati local cu zet run, apoi cu un utilizator care are profilul echipei;
4. rulati zet validate si zet pack, apoi incarcati arhiva din Setup > Developer Space > Widgets;
5. notati cine detine codul sursa si cine il actualizeaza.

Daca doriti sa vedeti cum se potriveste un widget in configurarea generala a CRM-ului, pagina despre implementarea Zoho CRM in Romania descrie cum lucram cu modulele, automatizarile si integrarile. De acolo puteti porni discutia despre nevoia concreta a echipei dumneavoastra.

• Kaizen #147 - Frequently Asked Questions on Zoho CRM Widgets
• Building a Client Side Application (Zoho CRM developer guide)
• Kaizen #23 - Widgets