Asocierea funcțiilor

O regulă de workflow poate trimite un email, crea o sarcină sau actualiza un câmp. Când ai nevoie de altceva, asociezi o funcție - cod care rulează la declanșarea regulii.

Este momentul în care configurarea devine dezvoltare, cu tot ce înseamnă asta: mai multă putere, dar și cod pe care cineva trebuie să îl întrețină. Merită trecut pragul doar când chiar este nevoie.

Când ai nevoie de o funcție

Acțiunile standard acoperă mai mult decât se crede. O funcție devine necesară pentru:

• Calcule pe mai multe înregistrări - de exemplu actualizarea unui total pe firmă când se schimbă o oportunitate a ei.
• Logică condiționată complexă, cu ramificații pe care criteriile regulii nu le pot exprima.
• Apeluri către sisteme externe - trimiterea unei comenzi către ERP, verificarea unui cod fiscal, notificarea unui sistem de facturare.
• Operații pe module conexe - crearea sau actualizarea unor înregistrări legate, cu date preluate din părinte.

În proiectele noastre din România, al treilea caz este cel mai frecvent: legătura dintre CRM și sistemele locale de facturare și gestiune. Acolo funcțiile sunt inevitabile, pentru că nu există integrare gata făcută.

Când NU ai nevoie

Verifică întâi dacă nu se rezolvă cu:

• Actualizare de câmp - acoperă majoritatea cererilor de „setează automat X când se întâmplă Y".
• Câmp formulă - pentru calcule în interiorul aceleiași înregistrări. Nu are nevoie de declanșator și nu se poate strica la fel ca un cod.
• Webhook - dacă doar trimiți date în altă parte, fără să procesezi nimic.
• Regulă de atribuire - pentru distribuirea înregistrărilor.

Regula noastră: dacă se poate face fără cod, se face fără cod. Peste doi ani, cine preia sistemul va înțelege o actualizare de câmp; o funcție trebuie citită și înțeleasă.

Riscurile, spuse direct

Trei lucruri pe care le vedem când preluăm un CRM cu funcții scrise în grabă:

1. Funcții fără documentație. Cine a scris-o a plecat, nimeni nu știe ce face, și nimeni nu îndrăznește să o dezactiveze. Rămâne acolo, rulează, și devine parte din folclorul firmei.
2. Bucle. O funcție care actualizează o înregistrare poate declanșa altă regulă care declanșează prima. Se manifestă ca sistem încetinit sau limite consumate, iar cauza se găsește greu.
3. Eșecuri tăcute. Dacă sistemul extern nu răspunde și funcția nu tratează eroarea, operațiunea eșuează fără ca nimeni să afle. În integrările cu facturarea, asta înseamnă comenzi care nu au ajuns unde trebuia.

Cum o faci corect

Practicile pe care le impunem în proiecte:

1. Un comentariu în capul funcției cu ce face, cine a cerut-o și când. Trei rânduri care economisesc ore peste un an.
2. Tratarea erorilor explicit. Ce se întâmplă dacă sistemul extern nu răspunde? Minimum o notificare către un responsabil.
3. Testare în sandbox, nu pe date reale. O funcție care actualizează greșit sute de înregistrări este mult mai greu de reparat decât de testat.
4. Verificarea buclelor înainte de activare: ce reguli se pot declanșa în lanț din ce modifică funcția.
5. O listă a funcțiilor active ținută în afara sistemului, cu scopul fiecăreia. Este primul lucru pe care îl cerem la un audit și rareori există.

Cine o scrie

Nu are nevoie de un programator cu experiență mare, dar are nevoie de cineva care înțelege și modelul de date, și procesul comercial. O funcție corectă tehnic dar care actualizează câmpul greșit produce date proaste, adică exact opusul scopului.

În implementările noastre funcțiile le scriem noi și le documentăm în predare, tocmai ca să nu ajungă în categoria „nimeni nu știe ce face, dar nu o atingem".