Salesforce divnosti?

Asi každý při práci se Salesforce občas narazí na nějakou podivnost, kterou prostě nechápe. Občas se i ty základní věci chovají nestandardně a nebo tam prostě nejsou, to člověka naštve. Na základě toho musí vymyslet workaround či solution, které mu pomůže danou situaci vyřešit. No a nebo... nebo to prostě musí prodat jako feature a ne jako bug. Což není snadné když tomu člověk sám pořádně nevěří a nechápe, proč zrovna tohle v Salesforce není.

Za poslední měsíc jsem si pár takových věcí poznamenal a mám tak tedy v sobě ještě naštvání a frustraci z dané situace. Pojďme se na pár takových věcí podívat.

Dynamic form a Opportunity creation

Dynamic form jsou skvělé, používám je prakticky všude, kde je to možné. Ta možnost, že člověk nemusí mít x Page Layouts je super. Jsou rychlejší, přehlednější a hlavně se tam dají i políčka lépe seřadit. Vemte si, že pokud kombinuje Multi-select picklist a v druhé sekci je nějaké jiné pole, tak se to zpravidla vždycky rozhodí a vypadá to nevzhledně. Ale to není předmětem této části.

Představte si situaci, že máte několik record types, přidáte pole do dynamic form, zapodmínkujete, aby každý typ měl rozdílný datový model. Uložíte a hle na detailu to funguje. Ale co v situaci když Opportunitu vytváříte? Tak v tuhle chvíli dojde k zobrazení standardního layoutu. Proč? Jak to tak občas je, je zatím jeden malý checkbox. Konkrétně s názvem "Prompt users to add products to opportunities", který je v setupu pod Opportunity Settings. Zjednodušeně, tenhle checkbox, pokud je označen na true, po vytvoření příležitosti vyhodí modal s tím, že musí dojít k vybrání Pricebooku a samozřejmě i produktu. Tahle neplecha brání k tomu, aby i create akce byla postavena na dynamic formu. Pokud jej označíme na false, najednou to začne fungovat. Uživatel tak akorát jen vybírá ceník a produkt až ve kroku, kdy chce na vytvořené opportunity přidat produkty. 

Jo, nějakou dobu mi trvalo než jsem na to přišel.

Lead Conversion a Description field

Pole Description je zrovna na Leadu poměrně důležité. Když jej konvertujete dojde k jeho přepisu na objekt Contact, super. Ale to je vše. Poměrně často se setkávám s dotazem, proč se pole automaticky nepřepsalo i na nově vytvořenou obchodní příležitost, protože právě v tomto poli držel obchodník důležité informace pro budoucí deal. Bohužel neznám odpověď, prostě to nejde. Není ani možné to standardní cestou nastavit, proto se musí vytvořit automatizace nebo přesvědčit zákazníka, že tyto informace jsou v systému stále, jen na jiném objektu, ke kterému má přístup. Například v konzoli je to snadno řešitelné (více otevřených tabs a je to), ale standardní prostředí to prostě ztěžuje. Achjo.

Soft validation

To mi sakra chybí! Co si pod tím představit? Prostě jen upozornění na to, že něco asi nejspíš nehraje a bylo by dobré se na to ještě jednou podívat. Zní to jako validace, ale ta vám vyloženě zakáže záznam uložit do doby, než splníte podmínku. Tady možnost uložení stále je. Prostě je to jen upozorní na situaci, že by měl uživatel raději ještě něco zkouknout.

Zrovna tohle je už naštěstí dost bodované jako idea a bude to snad brzy doručeno. Uf!

Jo a taky jsem na to s kamarádem připravili PoC, ale o tom třeba někdy jindy.

Knowledge article s translation - Mass Update

Knowledge je skvělá věc. Mám jí rád a baví mě její možnosti. Co je trošku horší je import znalostních článků, které mají potřebnou kategorii a samozřejmě i překlady do několika jazyků. Když se tohle všechno povede je vyhráno. Ale co v situaci, když potřebujete několik stovek articles s translates upravit a přidat například číselnou hodnotu do custom fieldu. Tady začíná sranda. Publikovanou verzi nelze updatovat. Musí se vytvořit draft, upravit hodnota a uložit. Problém nastává pokud máte překlady, o ty přijdete. Tady musí dojít k práci s archivací, restoru, submitu překladů, exportu dat, úpravy dat v excelu, importu zpět a následné publikaci.

Takhle napsané to vypadá, že je to rychlé. Ale jak píši výše, představte si velké množství článků, navíc chcete upravit pouze vybrané typy atd. Je to prostě záležitost na několik hodin práce. (hodně otravné práce)

Každopádně je to rychlejší než to všechno smazat a začít na zelené louce. 

Log as a povolení pro support

Známe to. Občas při řešení problému se SF supportem je potřeba povolit přístup do orgu, aby mohli danou situaci prověřit a otestovat. Pokud to nastavujete na svém uživateli, je to v pořádku a všechno jde.

Za předpokladu, že potřebujete nastavit přístup pro support u jiného uživatele, tak to bohužel nejde. A já vlastně chápu proč. Security. Dává to smysl, ale bylo by to rychlejší. Občas je skutečně náročné vysvětlit obyčejnému uživateli co a proč má udělat. 

Počet Subscriber users pro report

Víte, že počet subscriber uživatelů, kteří mohou být nastavení na reports/dashboards je omezený? V lightningu to je 7, v classicu ještě méně (ale kdo používá classic, že?). Při velké implementaci je tohle číslo značně nedostatečné. Ala naštěstí, už by to mělo být brzo vyřešené. Alespoň se tak tváří idea.

Je to prostě živý system

Vadí mi toho více, jako třeba to, že report nezobrazí veškeré emails, které odešli ze SF či nedostatečný inline editing. Nicméně to, co jsem zde popsal je zkušenost za poslední měsíc, tak o dalších problémech třeba někdy příště.

Co vadí vám? Co byste ocenili, aby Salesforce vylepšil nebo změnil? 

Dej mi vědět! info@salesforcestuff.org