hledat

Začněte vyhledáváním výše

  1. Domů
  2. Články
  3. Salesforce divnosti?

Sales­force divnosti?

Salesforce stuff
Salesforce divnosti?

Asi každý při prá­ci se Sales­force občas narazí na nějak­ou podi­vnost, kter­ou prostě nechápe. Občas se i ty zák­lad­ní věci chova­jí nes­tandard­ně anebo tam prostě nej­sou, to člově­ka naštve. Na zák­ladě toho musí vymyslet workaround či solu­tion, které mu pomůže danou situaci vyřešit. No anebo… nebo to prostě musí pro­dat jako fea­ture a né jako bug. Což není snad­né, když tomu člověk sám pořád­ně nevěří a nechápe, proč zrov­na tohle v Sales­force není.

Za posled­ní měsíc jsem si pár takových věcí poz­na­me­nal
a mám tak tedy v sobě ještě naštvání a frus­traci z dané situ­ace. Pojďme se na pár takových věcí podívat. 

Dynam­ic form a Oppor­tu­ni­ty cre­ation 

Dynam­ic form jsou skvělé, používám je prak­ticky všude,
kde je to možné. Ta možnost, že člověk nemusí mít x Page Lay­outs
je super. Jsou rych­le­jší, přehled­nější, a hlavně se tam dají i políč­ka lépe seřa­dit. Vemte si, že pokud kom­bin­u­je Mul­ti-select pick­list
a v druhé sek­ci je nějaké jiné pole, tak se to zpravid­la vždy­cky rozhodí a vypadá to nevzh­led­ně. Ale to není před­mětem této části. 

Před­stavte si situaci, že máte něko­lik record types, přidáte pole
do dynam­ic form, zapod­mínku­jete, aby každý typ měl rozdíl­ný datový mod­el. Uložíte a hle na detailu to fun­gu­je. Ale co v situaci,
když Oppor­tu­ni­tu vytváříte? Tak v tuh­le chvíli dojde k zobrazení stan­dard­ního lay­outu. Proč? Jak to, tak občas je, je zatím jeden malý check­box. Konkrét­ně s názvem Prompt users to add prod­ucts to oppor­tu­ni­ties”, který je v setupu pod Oppor­tu­ni­ty Set­tings. Zjednodušeně, tenhle check­box, pokud je označen na true,
po vytvoření příleži­tosti vyhodí modal s tím, že musí dojít k vybrání Price­booku a samozře­jmě i pro­duk­tu. Tahle neplecha brání k tomu, aby i cre­ate akce byla postave­na na dynam­ic for­mu.
Pokud jej označíme na false, najed­nou to začne fun­go­vat.
Uži­va­tel tak ako­rát jen vybírá ceník a pro­dukt až ve kroku, kdy chce na vytvořené oppor­tu­ni­ty při­dat produkty. 

Jo, nějak­ou dobu mi trva­lo, než jsem na to přišel. 

Lead Con­ver­sion a Descrip­tion field 

Pole Descrip­tion je zrov­na na Leadu poměrně důležité.
Když jej kon­ver­tu­jete dojde k jeho přepisu na objekt Con­tact, super.
Ale to je vše. Poměrně čas­to se setkávám s dotazem, proč se pole auto­mat­icky nepřep­sa­lo i na nově vytvoře­nou obchod­ní příleži­tost, pro­tože právě v tom­to poli držel obchod­ník důležité infor­ma­ce
pro budoucí deal. Bohužel neznám odpověď, prostě to nejde.
Není ani možné to stan­dard­ní ces­tou nas­tavit, pro­to se musí vytvořit autom­a­ti­zace nebo přesvědčit zákazní­ka, že tyto infor­ma­ce jsou v sys­té­mu stále, jen na jiném objek­tu, ke které­mu má příst­up. Napřík­lad v kon­zoli je to snad­no řešitel­né (více otevřených tabs
a je to), ale stan­dard­ní prostředí to prostě ztěžu­je. Achjo. 

Soft val­i­da­tion 

To mi sakra chy­bí! Co si pod tím před­stavit? Prostě jen upo­zornění
na to, že něco asi nejspíš nehra­je a bylo by dobré se na to ještě jed­nou podí­vat. Zní to jako val­i­dace, ale ta vám vyloženě zakáže záz­nam uložit do doby, než splníte pod­mínku. Tady možnost uložení stále je. Prostě je to jen upo­zorní na situaci, že by měl uži­va­tel raději ještě něco zkouknout. 

Zrov­na 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řiprav­ili PoC, ale o tom tře­ba někdy jindy. 

Knowl­edge arti­cle s trans­la­tion — Mass Update

Knowl­edge je skvělá věc. Mám jí rád a baví mě její možnos­ti.
Co je trošku horší je import znalost­ních článků, které mají potřeb­nou kat­e­gorii a samozře­jmě i překla­dy do něko­li­ka jazyků. Když se tohle všech­no povede je vyhráno. Ale co v situaci, když potře­bu­jete něko­lik stovek arti­cles s trans­lates uprav­it a při­dat napřík­lad čísel­nou hod­no­tu do cus­tom fiel­du. Tady začíná sran­da. Pub­liko­vanou verzi nelze upda­to­vat. Musí se vytvořit draft, uprav­it hod­no­ta a uložit. Prob­lém nastává, pokud máte překla­dy, o ty při­jdete. Tady musí dojít k prá­ci s archivací, restoru, sub­mi­tu překladů, expor­tu dat, úpravy dat v excelu, impor­tu zpět a násled­né publikaci. 

Takhle nap­sané to vypadá, že je to rych­lé. Ale jak píši výše, před­stavte si velké množství článků, navíc chcete uprav­it pouze vybrané typy atd. Je to prostě záleži­tost na něko­lik hodin práce. (hod­ně otravné práce) 

Kaž­dopád­ně je to rych­le­jší než to všech­no smazat a začít na zelené louce. 

Log as a pov­olení pro sup­port 

Známe to. Občas při řešení prob­lé­mu se SF sup­port­em je potře­ba povolit příst­up do orgu, aby mohli danou situaci prověřit a otesto­vat. Pokud to nas­tavu­jete na svém uži­vateli, je to v pořád­ku a všech­no jde. 

Za před­pok­ladu, že potře­bu­jete nas­tavit příst­up pro sup­port u jiného uži­vatele, tak to bohužel nejde. A já vlast­ně chápu proč. Secu­ri­ty. Dává to smysl, ale bylo by to rych­le­jší. Občas je skutečně náročné vysvětlit obyče­jné­mu uži­vateli co a proč má udělat. 

Počet Sub­scriber users pro report 

Víte, že počet sub­scriber uži­vatelů, kteří mohou být nas­tavení na reports/​dashboards je omezený? V light­ningu to je 7, v clas­sicu ještě méně (ale kdo používá clas­sic, že?). Při velké imple­mentaci je tohle čís­lo značně nedostatečné. Ala naštěstí, už by to mělo být brzo vyřešené. Ale­spoň se tak tváří idea

Je to prostě živý sys­tem 

Vadí mi toho více, jako tře­ba to, že report nezo­brazí vešk­eré emails, které odešli ze SF či nedostatečný inline edit­ing. Nicméně to, co jsem zde pop­sal je zkušenost za posled­ní měsíc, tak o dalších prob­lémech tře­ba někdy příště. 

Mohlo by vás také zajímat

Salesforce divnosti?