Reguli de validare si campuri obligatorii in Zoho CRM: ghid practic de configurare

Pentru reguli de validare si campuri obligatorii in Zoho CRM, alegerea depinde de tipul greselii pe care vreti sa o opriti. Campul obligatoriu opreste salvarea cand campul este gol. Regula de validare opreste salvarea cand valoarea introdusa este gresita. Functia Deluge preia verificarile pe care o regula simpla nu le poate exprima.

Echilibrul conteaza mai mult decat numarul de reguli. Daca faceti obligatorii toate campurile inca de la crearea unui lead, agentul de vanzari este blocat la fiecare salvare. Atunci completeaza campurile cu valori de umplutura. Datele arata complete, dar nu sunt corecte.

Abordarea care functioneaza are trei parti:

• campuri obligatorii putine la creare, adaugate treptat pe masura ce oportunitatea avanseaza pe etape;
• reguli de validare pentru format si valori permise, cu mesaje de eroare care spun exact ce trebuie corectat;
• functii Deluge doar pentru verificarile pe care regulile standard nu le acopera.

Mai exista un al patrulea element, adesea ignorat. Documentatia Zoho precizeaza ca actualizarile venite prin workflow, Blueprint, API, import sau webforms au prioritate fata de regula de validare. Prin urmare, o regula buna in formular nu garanteaza date curate in tot CRM-ul. Restul ghidului explica fiecare mecanism, limitele lui si felul in care le combinati.

Cele trei mecanisme se confunda usor, asa ca merita definite separat. Fiecare raspunde la alta intrebare despre datele introduse.

Campul obligatoriu

Un camp obligatoriu este o setare a campului care verifica un singur lucru: ca acesta nu este gol. Nu verifica daca valoarea are sens. Un telefon scris "0000" trece de un camp obligatoriu fara nicio problema.

Regula de validare

O regula de validare este o functie Zoho CRM care defineste ce valori nu sunt acceptate pentru un camp si prinde datele gresite inainte sa fie salvate. Documentatia Zoho descrie comportamentul astfel: daca valoarea introdusa corespunde criteriilor din regula, CRM-ul afiseaza o alerta si nu permite salvarea inregistrarii. La definirea regulii alegeti daca alerta apare cand conditia este indeplinita sau cand nu este indeplinita. Mesajul de eroare este personalizabil.

Functia Deluge de validare

Deluge este limbajul de scripting al platformei Zoho. O functie Deluge de validare primeste datele inregistrarii, le verifica prin cod si intoarce fie o eroare cu mesaj, fie acceptul. Este solutia pentru reguli pe care conditiile din interfata nu le pot descrie, de exemplu verificarea formatului unui cod intern.

Pe scurt, campul obligatoriu raspunde la intrebarea "exista o valoare?". Regula de validare raspunde la "este valoarea acceptabila?". Functia Deluge raspunde la "respecta valoarea o logica pe care doar codul o poate exprima?".

Campurile obligatorii se stabilesc pe etape, pentru ca informatia apare treptat pe parcursul vanzarii. Un utilizator din comunitatea Zoho a descris exact aceasta situatie. Unele informatii importante despre client apar doar spre finalul ciclului de vanzare. Unele dintre ele tin de compania client (Account), nu de oportunitate (Deal).

Acelasi utilizator a observat doua lucruri utile pentru orice configurare. Primul: in Deals, anumite campuri pot fi facute obligatorii conditionat, in functie de etapa. Al doilea: impunerea lor la nivel de lead nu este realista, pentru ca este prea devreme in procesul de vanzare pentru a avea acele date.

Regula practica rezulta direct de aici. Pentru fiecare etapa din pipeline, notati ce stie agentul in mod realist in acel moment. Exemplu de lucru:

1. Lead nou: nume, companie si o cale de contact.
2. Calificare: sursa, nevoia si persoana care decide.
3. Oferta: valoare, data estimata de inchidere si produsele.
4. Negociere si castigat: datele de facturare si cele contractuale.

Limita apare cand informatia ceruta sta in alt modul. Obligativitatea conditionata din Deal nu forteaza completarea campurilor din Account. In plus, potrivit unei postari din comunitate, Zoho CRM accepta un singur camp parinte pentru o dependenta de campuri. Pentru cerinte care traverseaza module, aveti nevoie de o functie sau de un Blueprint. Ordinea campurilor in layout o stabiliti cel mai bine in lista de configurare Zoho CRM dinaintea lansarii.

O regula de validare in Zoho CRM se creeaza pe modul si se aplica la salvarea inregistrarii. Pentru a o crea, utilizatorul are nevoie de permisiunea de profil pentru personalizarea modulului. Fara aceasta permisiune, optiunea nu este disponibila.

Regulile sunt specifice layout-ului. In acelasi modul, de exemplu Leads, puteti avea reguli diferite pe acelasi camp, pentru layout-uri diferite. Este util cand vindeti catre doua tipuri de clienti cu cerinte diferite de date.

Pasii de configurare urmeaza aceeasi logica pentru orice regula:

1. Alegeti modulul si layout-ul in care se aplica regula.
2. Selectati campul verificat.
3. Definiti conditia si alegeti daca alerta apare cand conditia este indeplinita sau cand nu este.
4. Scrieti mesajul de eroare.
5. Testati salvarea cu o valoare corecta si cu una gresita.

Mesajul de eroare decide daca regula ajuta sau enerveaza. "Valoare invalida" il lasa pe agent sa ghiceasca. "Codul trebuie sa contina caracterul /" ii spune exact ce sa corecteze. Personalizarea mesajului este inclusa in functie, deci folositi-o la fiecare regula.

Documentatia Zoho enumera contextele in care regulile se aplica: Creare, Creare rapida, Editare si Editare rapida, toate in versiunea Web, plus copierea personalizarilor in Sandbox. Daca echipa dumneavoastra lucreaza mult din alte interfete, testati acolo separat comportamentul inainte de lansare.

Regulile de validare din Zoho CRM au limite clare, iar cunoasterea lor din timp va scuteste de reconfigurari. Prima limita tine de tipul campului. Documentatia Zoho precizeaza ca regulile nu sunt suportate pentru campurile de tip lookup, lookup cu selectie multipla, lista cu selectie multipla, formula, numar automat si text pe mai multe linii.

A doua limita tine de complexitatea conditiilor. Valorile din documentatie sunt urmatoarele:

• 10 conditii parinte pentru fiecare regula;
• 5 conditii copil pentru fiecare conditie parinte;
• 5 criterii pentru fiecare conditie copil.

A treia limita este ordinea. Regulile se executa in ordinea in care au fost create. Daca doua reguli verifica acelasi camp, prima creata se aplica prima. Notati ordinea intr-un document intern, ca sa stiti ce mesaj vede agentul.

A patra limita apare la stergere. Un camp asociat unei reguli de validare nu poate fi sters direct. Mai intai stergeti regula, apoi campul.

Cand cerinta depaseste aceste limite, trecerea la o functie Deluge este pasul firesc. Un exemplu din comunitatea Zoho: un utilizator avea un modul personalizat cu intre 1 si 24 de campuri pentru scadente de rate. Voia ca fiecare scadenta sa nu fie anterioara celei dinainte. Cu 24 de campuri, o asemenea regula devine greu de intretinut prin conditii in interfata. O functie care parcurge scadentele este mai usor de citit si de modificat.

O functie Deluge de validare verifica prin cod valoarea unui camp si intoarce o eroare cu mesaj cand valoarea nu respecta regula. Exemplul de mai jos porneste de la un caz real din comunitatea Zoho. In modulul Deals, campul Marking_Code trebuie sa contina caracterul "/". Functia citeste inregistrarea trimisa la salvare, verifica valoarea si opreste salvarea daca formatul este gresit.

Codul de mai jos se lipeste in editorul functiei de validare asociate regulii din modulul Deals:

// Citeste inregistrarea trimisa la salvare
entityMap = crmAPIRequest.toMap().get("record");
markingCode = entityMap.get("Marking_Code");
response = Map();
// Codul trebuie sa contina caracterul /
if(!markingCode.contains("/"))
{
	response.put('status','error');
	response.put('message','Codul de marcare trebuie sa contina caracterul /');
}
else
{
	response.put('status','success');
}
return response;

Trei linii sunt cele pe care le adaptati. "Marking_Code" este numele API al campului; il inlocuiti cu numele campului dumneavoastra. Conditia markingCode.contains("/") este regula propriu-zisa; o schimbati cu verificarea de care aveti nevoie. Textul din 'message' este mesajul vazut de agent; scrieti-l ca pe o instructiune de corectare.

Acelasi utilizator a raportat si o problema importanta. Functia mergea la crearea manuala a oportunitatii. Nu mai parea sa functioneze cand campul era completat ca obligatoriu intr-o tranzitie Blueprint. Explicatia se afla in documentatia Zoho si este subiectul sectiunii urmatoare.

Datele ocolesc regulile de validare din Zoho CRM ori de cate ori campul este actualizat prin alta cale decat formularul. Documentatia Zoho este explicita. Daca un camp folosit intr-o regula este actualizat prin workflow, Blueprint, API, import sau webforms, actualizarea campului are prioritate fata de regula de validare.

Blueprint are o regula proprie. Cand exista atat o regula de validare, cat si o validare Blueprint pentru acelasi camp, cu conditii diferite, Blueprint inlocuieste regula de validare. Asta explica de ce functia pe Marking_Code parea sa nu functioneze in tranzitia Blueprint. Validarea trebuie configurata si in Blueprint, nu doar in regula modulului.

Webforms au un comportament aparte. Inregistrarile generate prin webforms care indeplinesc criteriile regulii nu sunt respinse. Ele sunt trimise la aprobare manuala. Cineva din echipa trebuie deci sa verifice coada de aprobare, altfel lead-urile asteapta acolo nevazute.

Practic, fiecare cale de intrare cere propria verificare:

• formularele utilizatorilor: reguli de validare si campuri obligatorii;
• tranzitiile Blueprint: validari definite in Blueprint;
• importurile: curatarea fisierului inainte de incarcare;
• integrarile prin API: verificari in integrare, inainte de scriere;
• webforms: urmarirea cozii de aprobare manuala.

La Svennis testam fiecare regula nu doar din formular, ci si printr-un import de proba si prin integrarile clientului, pentru ca pe aceste cai ajung de obicei datele care trec de validare neobservate.

Alegerea mecanismului de validare in Zoho CRM depinde de cerinta, de momentul in care apare informatia si de calea prin care intra datele. Tabelul de mai jos rezuma ce verifica fiecare mecanism, unde se aplica si unde are limite, pe baza documentatiei Zoho si a cazurilor din comunitate.

Mecanism	Ce verifica	Cand il folositi	Limita principala
Camp obligatoriu in layout	Ca exista o valoare	Datele pe care agentul le are mereu la creare	Nu verifica daca valoarea este corecta
Obligatoriu conditionat pe etapa	Ca exista o valoare intr-o anumita etapa	Informatii care apar mai tarziu in vanzare	Nu forteaza campuri din alt modul, de exemplu Account
Regula de validare	Ca valoarea respecta o conditie	Format, valori permise, intervale	Nu merge pe lookup, formula, numar automat, text pe mai multe linii
Functie Deluge de validare	Orice logica scrisa in cod	Reguli complexe sau multe campuri comparate	Cere intretinere si testare la fiecare schimbare
Validare in Blueprint	Campurile cerute la o tranzitie	Procese cu pasi impusi	Inlocuieste regula modulului cand conditiile difera

Cititi tabelul de sus in jos. Incepeti cu cel mai simplu mecanism care rezolva cerinta. Treceti la urmatorul doar cand limita lui va blocheaza. Fiecare nivel adaugat inseamna inca un element de testat si de documentat.

Pentru o companie din Romania, cea mai mare parte a riscului vine adesea din integrari, nu din formularele completate manual. Comenzile dintr-un magazin online, facturile sau datele firmelor ajung in Zoho CRM prin API. Potrivit documentatiei Zoho, actualizarile prin API au prioritate fata de regulile de validare. Integrarea trebuie deci sa trimita date deja corecte.

Daca aveti o integrare WooCommerce cu Zoho CRM, verificati ce campuri completeaza ea si in ce format. Regula din layout nu se aplica acelor inregistrari. Aceeasi intrebare se pune pentru o integrare SmartBill cu Zoho CRM, unde datele de facturare trebuie sa ajunga complete.

Pentru datele de identificare a firmelor, preluarea automata reduce nevoia de reguli de format. Extensia ANAF pentru Zoho CRM completeaza datele firmei pe baza CUI, in loc sa va bazati pe tastarea manuala. Mai putine campuri scrise de mana inseamna mai putine reguli de validare de intretinut.

Echipele de vanzari mici sunt un al doilea factor. Intr-o firma cu cinci agenti, fiecare blocare la salvare se simte imediat. O regula prea stricta ajunge sa fie ocolita prin valori de umplutura. Porniti cu putine reguli, urmariti ce mesaje de eroare apar des in primele saptamani si ajustati regulile dupa ele.

Configurarea validarii in Zoho CRM merge cel mai bine in ordinea de mai jos. Fiecare pas foloseste rezultatul celui anterior.

1. Scrieti etapele pipeline-ului si, pentru fiecare, campurile pe care agentul le cunoaste in mod realist in acel moment.
2. Faceti obligatorii la creare doar campurile din prima etapa. Pe restul le cereti conditionat, pe etape.
3. Listati campurile cu format sau valori permise si verificati daca tipul lor accepta reguli de validare.
4. Creati regulile, cu mesaje de eroare care spun exact ce trebuie corectat, si notati ordinea crearii.
5. Pentru cerintele care trec de limitele regulilor, scrieti o functie Deluge si testati-o pe valori corecte si gresite.
6. Repetati validarile importante in Blueprint, daca folositi tranzitii cu campuri obligatorii.
7. Testati fiecare cale de intrare: formular, import de proba, integrari prin API si webforms.
8. Desemnati o persoana care verifica saptamanal coada de aprobare manuala a webforms.

Daca sunteti la inceputul proiectului, ghidul de implementare Zoho CRM va arata unde se incadreaza validarea in planul general. Pentru configurarea contului si a integrarilor, pagina Zoho CRM pentru companii din Romania descrie cum lucram concret.

• Zoho CRM: Trabalhando com regras de validacao
• Zoho Community: Validation to ensure certain Account Fields are populated when Deal Stage changes
• Zoho Community: validation rules doesn't work in Blueprint when it is validated using function
• Zoho Community: how to use validation rules in subform
• Zoho Community: Validation rules for dates (after, before, other fields)