BLOG
SALESFORCE

Blog: 7 gode råd til Salesforce valideringsregler

En salgsmulighed skal lukkes, og det er super vigtigt, at der altid er ordrenummer på. Et emne oprettes og der skal altid være angivet en email. Kunden har addresse på sjælland, derfor skal det altid være det sjællandske kontor der er ansvarlig for dem.

[5. maj 2015] Ovenstående er klassiske eksempler på scenarier hvor man kan vælge at anvende valideringsregler i Salesforce. Helt kort, så er valideringsregler til for at sikre, at din data i Salesforce opfylder de krav, som der stilles til den. Det kan være alt fra forretningskrav til krav stillet af jeres integrationer.

De 7 Gode Råd:

  1. Never, ever, ever opret valideringsregler direkte i Produktion
  2. Kør reglerne så smalt som muligt
  3. Husk at orienter brugeren om at der er kommet nye regler
  4. Pas på der ikke kommer for mange regler
  5. Brug ALDRIG ID’er i en valideringsregel
  6. Vær opmærksom på layouts vs. valideringsregler
  7. Test, Test og Mere Test

Herunder er hver enkelt uddybet, for at forklare nærmere:

 

1. Never, ever, ever opret valideringsregler direkte i Produktion

Salesforce er virkelig nemt at modificere og redigere i produktionsmiljøet. Hvis salgschefen eller en anden del af forretning lige kommer forbi og siger; ”Kan du ikke sørge for at personens titel altid er udfyldt?”, så kan en administrator meget hurtigt oprette en valideringsregel og gøre bestilleren tilfreds... og potentielt smadre en integration eller skabe fejl for en deployment.

Det lyder måske tosset, men, det kan være alt fra et test script som ikke udfylder rolle når det kører (og derved forhindrer deployment), eller det kan være en integration som ikke har data eller lignende.

Selvom det tager længere tid, så opret valideringsreglen i jeres sandkasse, test at den gør hvad den skal og så deploy den til produktion. Dette vil sørge for at alle test kører, og eventuelle fejl vil vise sig før det er lagt i produktion.

(Bonus info: du kan køre alle tests fra din sandkasse og fange evt. fejl inden du deployer)

2. Kør reglerne så smalt som muligt

Denne regel er nok den man hyppigst glemmer. Tag eksemplet med ordrenummer. Dette bliver et krav 1 år efter jeres første Salesforce implementering, nu vil integrere Salesforce med jeres finans system. For at det kan lade sig gøre, skal der være et ordrenummer på lukkede salg.

En valideringsregel på sådan et scenarie kunne se ud således:

AND(
StageName = ’Closed’,
ISBLANK(OrderNumber)
)

Ovenstående betyder at hvis “Stage” er lig med lukket, så skal der være et ordrenummer. Det betyder også, data-mæssigt, at i vil have data for et helt år, som aldrig vil komme til at leve op til de nye standarder. Og hvis i lige pludselig skal opdatere alle salgsmuligheder, så vil al historisk data fejle. Der er det bedre at indsnævre hvor ”sjældent” den skal validere. Lad os tage ovenstående som eksempel, der med en lille ændring, ikke vil pårvirke historisk data:

AND(
ISCHANGED(StageName),
StageName = ’Closed’,
ISBLANK(OrderNumber)
)

Ovenstående betyder at den kun tjekker om der er et ordrenummer, når du lukker salget, dvs. du kan ikke lukke et salg uden ordrenummer, men, alle tidligere lukkede salg kan sagtens eksistere uden ordrenumre.

Derfor, kør dine valideringsregler så smalt eller så sjældent som det er muligt / acceptabelt for det ønskede resultat.

3. Husk at orienter brugeren om at der er kommet nye regler

Igen, samme scenarie, der skal være ordrenummer på lukkede salg. Hvis Råd # 1 og #2 er fulgt, og det bare bliver lagt i produktion, er der en reel risiko for at forvirre slutbrugerne. De vil køre med business-as-usual, og så lige pludselig får de en fejl. De kan ikke gennemføre processen som de er plejer. Dette kan skabe unødvendig frustration over for processen, systemet og evt. IT-afdelingen.

En melding fredag om at fra på mandag af, så skal de fremadrettet udfylde disse nye felter kan gøre mirakler for at reducere frustrationerne. Præcis her er det fantastisk at starte i sandkassen og så deploy til produktion, for så sikrer du dig at alt er klar til mandag morgen, og man bare kan deploye. Alternativet til en melding er evt. at det bliver præsenteret på team-møde eller af deres nærmeste leder. Men husk at kommunikere det ud.

4. Pas på der ikke kommer for mange regler

Dette er en fald gruppe som man risikerer opstår lidt spontant. Først har man brug for at der bliver udfyldt eksempelvis ”By”, så en ”Reason for Lost” og så noget mere, og noget mere etc.

Slut resultatet kan være en process der er så langsommelig og bøvlet at man demotiverer slutbrugeren. Derfor spørg altid: Er det ”need to have” eller er det bare ”nice to have” ?

5. Brug ALDRIG ID’er i en valideringsregel

Dette ses ofte ved brug af record types, at man lige anvender ID’et, men istedet – brug da eksempelvis RecordType.DeveloperName. Tilsvarende gør sig gældende hvis det er muligt at anvende en custom label frem for en tekststreng eller at anvende Custom Permissions frem for profiles og permissions sets mm. – det gør opbygningen mere robust, og du er sikker på at dine regler virker når du deployer fra et miljø til et andet.

6. Vær opmærksom på layouts vs. valideringsregler

Det at gøre et felt påkrævet kan gøres via enten et sidelayout eller en valideringsregel. Hvis det altid er påkrævet kan sidelayout være svaret, hvis det kun er påkrævet når visse betingelser er opfyldt, så er valideringsregler svaret. En vigtig forskel er at hvis det kun er påkrævet ved hjælp af sidelayout, så kan du godt importere data til din Salesforce instans med success, hvorimod samme import vil fejle hvis det er påkrævet ved brug af en valideringsregel.

7. Test, Test og Mere Test

I forlængelse af det første råd, så kan det ikke understreges hvor vigtigt test er. Det kan godt være der kun valideres på et enkelt felt, og man ser at den gør som man forventer. Til tider kan det dog godt svare sig at prøve at køre hele processen omkring objektet igennem, for at sikre sig at man ikke har ødelagt noget eksisterende automatik eller stopper en anden process der rører samme objekt. Så test, test og mere test. Det kan spare dig tid og ressourcer i sidste ende.

todo todo