Jsou okamžiky, kdy konzultant musí opravdu přemýšlet, které z těch všech možných řešení je nejlepší. Nejlevnější. Nejflexibilnější. Umožňující něco, o čem zákazník ještě nepřemýšlel, ale možná to bude chtít. Jak by bylo správné to v Salesforce dělat. Tenhle konkrétní jednoduchý příklad, přesně ukazuje, co vše se mi honí hlavou, když přemýšlím o zadání.
Chceme u kontaktů evidovat záznamy o telefonátech z call centra. Současně je potřeba automaticky změnit informace na kontaktu, pokud pracovník vyplní nové údaje.
Jaké možnosti mne napadly?
- obyčejný formulář a workflow/proces pro aktualizaci údajů;
- flow pro zadávání informací a aktualizaci informací;
- flow pro zadávání informací, workflow/proces pro aktualizaci údajů;
- visualforce stránka pro zadávání informací, trigger pro aktualizaci údajů.
Obyčejný formulář
Znělo to nadějně – stejně musím vytvořit nový objekt pro evidenci telefonátů, polím dám předvolené hodnoty podle aktuálních hodnot na kontaktu (aby pracovníci viděli, jaké jsou aktuální údaje a mohli je jednoduše změnit) a workflow mi po uložení aktualizuje informace na kontaktu.
Bohužel, u checkboxů si můžete předvolenou hodnotu vybrat pouze napevno, nikoliv ji natáhnout odjinud. Slepá ulička.
Flow
Vytvořit objekt, udělat flow, přidat na kontakt tlačítko, které flow spustí. Jednoduché, funkční a pravděpodobně přesně tak, jak to má být.
Načíst informace z kontaktu, jehož ID jsme flow předali při spuštění, zobrazit obrazovku s předvyplněnými poli a nechat uživatele změnit hodnoty, vytvořit záznam telefonátu a konečně aktualizovat pole na kontaktu.
Celé to má jedinou chybičku, kterou si vývojář uvědomí asi jako první. Je to neskutečně pracné. Pokud máte dvacet polí, tak vás čeká:
- 20x přiřazení hodnoty pole do proměnné;
- 20x přidání pole na obrazovku a nastavení předvolené hodnoty;
- 20x přiřazení hodnoty při vytváření nového záznamu;
- 20x aktualizace hodnoty pole podle zadaných hodnot, ideálně pouze pokud se liší.
Prostě a jednoduše se uklikáte (nebo si to vývojář alespoň myslí).
Flow + workflow
Proč přesunout aktualizaci kontaktu z flow do workflow/procesu, který se spustí po vytvoření záznamu telefonátu? Na první pohled to nemá naprosto žádný důvod, jenom rozsypu funkcionalitu na více míst, navíc je to podobně pracné naklikat.
Důvod se objeví po prvním měsíci, když zákazník pošle Excel s pár sty řádky, kam telefonáty celý měsíc zapisovali, protože ještě nevyškolili uživatele. Mohli byste je prosím naimportovat?
Jasně, mohli, jeden import pro vytvoření záznamu telefonátu, druhý pro aktualizaci údajů na kontaktu.
Víte, pro nás to dělá i externí agentura, takže to budeme importovat každý měsíc.
Přesně v tento okamžik přichází na řadu odtrhnutí aktualizace dat do separátního procesu, protože se spustí automaticky a vy si ušetříte jeden import dat.
Visualforce stránka a trigger
Jupí, krásné programátorské řešení. Jedna VF stránka s připojeným APEX controllerem, který načte defaultní hodnoty. Krásné je, že kopírovat řádky jde velice rychle, určitě rychleji, než to klikání hodnot v tom skvěle animovaném UI. Trigger, který aktualizuje kontakt po vytvoření záznamu telefonátu. Co řádek to pole, krásně se to kopíruje. Napsat testy, aby vám prošlo nasazení do produkce, už je drobný detail.
Máte pocit fantastické rychlosti vývoje, nevýhodou je, že běžný uživatel se bude velmi bát přidat další pole, přestože je to v podstatě stejné kopírování jako ve flow. Na druhou stranu, pokud to chcete zjednodušit sobě i jemu, tak použijete field set, kde si přesně určí, která pole chce na obrazovce mít a v jakém pořadí. Vám se zjednoduší kód, on se nebude bát do toho sáhnout a přidat další pole je otázka pár kliků, jednoznačně nejrychlejší, ze všech řešení.
Click or code?
Jako vždy zůstává ta velká otázka. Klikat nebo kódovat? Co je lepší, co je rychlejší, co se bude snadněji udržovat, rozšiřovat, splní i budoucí požadavky?
A hlavně – kde přesně začíná kódování? Opravdu běžný power user zvládne naklikat flow nebo v něm udělat změny? Nebo už je to věc, kterou raději nechá na konzultantovi/vývojáři?
Jak přemýšlíte o zadání vy? Raději klikáte nebo píšete kód?
Hezkej článek. Já osobně klikám a to ze dvou důvodů: 1. Nejsem Apex vývojář, takže mi nic jiného nezbyde:) 2. Naklikat to, je vždy transparentnější řešení pro zákazníka či pro další jemnější zásahy ze strany admina/buildera. Ovšem má to i své proti a to že né vždy se dá naklikat právě to, co si zákazník vymyslí:) Pak holt jde na řadu Apex vývojář, kterému se člověk stejně nikdy nevyhne, pokud nechce používat Salesforce pouze jako „vylepšený excel“
Mě na tom klikání mnohdy vadí, že je to rozsypané po spoustě míst a hrozně špatně se to dohledává. Typicky mám objekt, pole, na validation rules se musím podívat jinam (nikoliv u pole), pak musím projít workflow a procesy, zda se něco nad tímhle objektem náhodou nespouští a pak se modlit, aby tenhle objekt náhodou neměnilo workflow/proces spouštěné nad jiným objektem.
Trochu rozdíl oproti triggerům, které vidím přímo na objektu a mohu s nimi tak trochu počítat.
Díky za pěkný článek. Neznám to úplně v SF, ale na toto jsem již několikrát narazil v Lotus Notes, kde ty možnosti jsou podobné. Buď naklikáš akci přes Simple Actions, nebo to uděláš v @Formulích nebo jdeš nakonec do programování v LotusScriptu. No a v 90% se to z původního jednoduchého, „naklikatelného“ zadání změnilo na něco co naklikat nešlo. Tu se měly přenést iniciály místo celého jména, tady to mělo být Upper Case, jinde se měly sčítat dvě pole dohromady a to jen za určité podmínky, a to mluvě jen o těch jednodušších požadavcích. Takže člověka to naučilo začít psát i ty jednoduché úkony programováním, ačkoliv to zabralo více času. Je ovšem pravda, že SF je trochu něco jiného, pokud potřebujeme, aby funkcionalita byla srozumitelná a jasná i adminovi bez programátorských zkušeností.
V LN jsem se typicky dostával do situací, kdy klient přišel, že si vyvinul vlastní aplikaci a potřebuje jenom „tohle“, co už sám nezvládne. Já na to kouknul a bylo nutné to od základů přepsat, protože „tohle“ potřebovalo změnit celou strukturu dat a další věci.
Tady je to podobné 🙂