Slack jako platforma – funkcje, automatyzacje i nowe możliwości współpracy

Chcesz najpierw wprowadzenia do tematu? Zobacz materiał wideo przygotowany przez Ninę Jachnę na platformie Consensus – świetny start przed odsłuchem odcinka! 👉 https://play.goconsensus.com/u64ea8377

Kanały, kanwasy, listy i klipy – czyli jak Slack zmienia współpracę

W drugiej części rozmowy z ekspertami — Piotr Broniek i Michał Kuca — wychodzimy poza „czat” i pokazujemy, jak wszechstronnym narzędziem może być Slack.

Slack to nie tylko szybkie wiadomości:

• Kanały – tematyczne, prywatne lub publiczne, które porządkują komunikację. Dzięki odpowiednim zasadom nazewnictwa i strukturze, szybko znajdziesz to, czego potrzebujesz.
• Kanwasy (Canvas) — trwałe przestrzenie do przechowywania dokumentów, materiałów, notatek czy prezentacji — idealne jako baza wiedzy dla zespołu.
• Listy — proste narzędzie do zarządzania zadaniami / projektami — coś na kształt lekkiego “Trello” wbudowanego w Slack.
• Klipy audio/wideo — szybkie nagrania: prezentacje, instrukcje, instruktaż, feedback — bez potrzeby uruchamiania zewnętrznych narzędzi.

To wszystko sprawia, że Slack to kompletny ekosystem do współpracy — jednocześnie komunikacja, dokumentacja, zarządzanie zadaniami i wiedzą w jednym miejscu.

Huddle, automatyzacje i rola dewelopera Slacka

Ale Slack to nie tylko narzędzia — to również możliwości automatyzacji i elastyczność dzięki integracjom. W odcinku omawiamy między innymi:

• Huddle — szybka rozmowa „jak podejście do biurka” w biurze: idealna na nagłe pytania, szybkie decyzje lub synchronizację zespołu, bez potrzeby planowania formalnej wideokonferencji.
• Automatyzacje — dzięki wbudowanym narzędziom (np. Workflow Builder) lub dedykowanym aplikacjom, Slack pozwala automatyzować procesy: onboarding, tworzenie kanałów, zapraszanie użytkowników, wysyłkę materiałów, przypomnienia, alerty. To realna oszczędność czasu i porządek w procesach.
• Slack jako platforma developerska — Slack oferuje interfejsy API, narzędzia deweloperskie i możliwość budowania własnych rozszerzeń: od prostych workflowów do bardziej zaawansowanych aplikacji — co czyni go elastycznym i skalowalnym dla firm o różnej skali.

Dzięki temu Slack nie jest już tylko „komunikatorem”, ale pełnoprawną platformą współpracy i automatyzacji – gotową rosnąć razem z potrzebami organizacji.

Dlaczego warto posłuchać tej rozmowy

Ten odcinek to kopalnia praktycznej wiedzy — od funkcji, przez integracje, aż po rekomendacje wdrożeniowe. Jeśli:

• pracujesz w zespole, który potrzebuje lepszej organizacji komunikacji i wiedzy,
• zastanawiasz się nad narzędziem do pracy zdalnej / hybrydowej,
• chcesz zautomatyzować procesy i usprawnić onboarding / współpracę,
• albo interesujesz się technologią i możliwością rozszerzenia Slacka o niestandardowe rozwiązania —

…to rozmowa z Piotrem i Michałem dostarczy Ci konkretnych pomysłów i inspiracji.

Transkrypt

Cześć, witajcie serdecznie, z tej strony Łukasz Bujło z coffee&force.

Zapraszam Was na drugą część naszego podcastu dotyczącej platformy Slack w ramach serii podcastów Salesforce na wyciągnięcie ręki. Salesforce na wyciągnięcie ręki to porcja inspirujących rozmów i historii prosto ze świata Salesforce. Ten projekt stworzony z myślą o Tobie powstał przy współpracy z samym Salesforce, aby przybliżyć tajniki technologii chmurowej, zarządzania relacjami z klientami i nie tylko.

Przygotuj się na dawkę inspiracji i wiedzy, która może zmienić Twoje spojrzenie na technologie w biznesie. Zrelaksuj się, bądź z nami i odkrywaj nieznane zakątki Salesforce w każdym odcinku. A w drugiej części naszego podcastu kontynuujemy naszą rozmowę z Piotrkiem Brońkiem oraz Michałem Kucą.

Rozmawiamy o platformie Slack. Jeżeli nie słyszeliście naszej pierwszej części zapraszamy do odsłuchania. A teraz już nie przedłużam i kontynuujemy naszą rozmowę dotyczącą kluczowych elementów Slacka.

Dobra, mamy dwie czy trzy funkcjonalności troszkę omówione, kanały, kanwas, listy. Lecimy do kolejnej funkcjonalności, huddle. Do czego służą, czym jest to tajemnicze słowo i… Nie wiem czy kojarzycie jak najczęściej to się chyba widzi u siatkarzy albo w futbolu amerykańskim, jak przed meczem stają w kole, łapią się wszyscy za ramiona i tam zagrzewają się do walki.

To jest huddle, to był huddle, stąd się to wzięło. Huddle w Slacku to jest po prostu forma szybkiej rozmowy, takiego szybkiego telefonu do kogoś, która porównywana jest do podejścia do biurka. Czyli chcemy o coś szybko zapytać, nie musimy ustawiać w konferencji, w kalendarzu, wykonujemy szybki telefon do jednej osoby bądź też do całej grupy.

Jest to porównywane do takiego szybkiego podejścia do kogoś do biurka w biurze i zadanie takiego szybkiego pytania, nie? A jednocześnie… W ogóle jakby ciekawy temat z tą nazwą, bo generalnie też się zastanawiałem skąd im to przyszło do głowy. Znaczy tak, ja tylko dodam, że no właśnie, to jest jakby takie narzędzie do takich powiedzmy małych rozmów, niekonieczny one-on-one, mogą być większe jak najbardziej, natomiast też żeby nie było idealnie, to nie jest raczej narzędzie do organizowania potężnych wideokonferencji. To było moje kolejne pytanie, chciałem właśnie podpytać, jak już można rozmawiać wideo, czy można do wideokonferencji, dobra.

Natomiast nic nie stoi na przeszkodzie, żeby jak najbardziej wyszerowować sobie ekran, są tam jakieś feature do transkrypcji, nie zawsze on działa, czasem na przykład polski język potrafi przedstawić za pomocą chińskich znaczków, więc to nie jest do końca idealne, ale z drugiej takiej jakby fajnej rzeczy, w tym hudlu mamy bezpośredni dostęp do wątków, jeżeli to jest hudle kanałowy, plus mamy dostęp do kanwasa z danego kanału, więc możemy na bieżąco prowadzić z kimś rozmowy, coś analizować i generalnie możemy na bieżąco aktualizować i kanwasa, czy zapisywać coś w wątku, żeby nam to potem nie umknęło. Są jakieś pomysły, z tego co słyszałem, pod kątem budowania rozwiązania AI, żeby to jakoś wesprzeć, ten feature, tak to ujmę, natomiast no jak zawsze czas pokaże. Super.

Ostatnie na mojej liści z takich największych, najważniejszych funkcjonalności są klipy. Klipy rozumiemy na klipy audio i klipy video. Klipy audio to wiadomo, nagrywamy dźwięk, nagrywamy nasz głos, jeżeli coś mówimy, dzielimy się z tym na kanale albo w wiadomości prywatnej.

Jeżeli chodzi o klipy, no to klip możemy nagrać za pomocą kamery, tak na przykład, żeby się przedstawić, nie wiem, jesteśmy nowi w zespole, chcemy powiedzieć cześć i mamy na tyle odwagi, żeby nagrać taki klip i wrzucić go na kanał, to oczywiście możemy go nagrać, ale klipów też możemy użyć, jeżeli potrzebujemy wskazać komuś coś na komputerze, tak, czyli nie wiem, powiedzmy, odwołajmy się do Salesforce’a. Mamy użytkownika z Salesforce’a albo, nie wiem, innego administratora, developera, któremu chcemy coś pokazać. Nie musimy pisać opisu kliknij tu, idź tam, ponieważ to zajmie dużo więcej czasu niż nagranie wszystkiego klipu, który po prostu będzie wyświetlał zawartość naszego ekranu i w trzy sekundy jesteśmy w stanie wskazać osoby, jak coś wykonać, tak, gdzie kliknąć, gdzie pójść, a nie, albo na przykład się wyzwaniać i nie tu, wyżej, nie, trzy centymetry w prawo daj myszkę, nie, nie tu, za daleko, teraz troszeczkę w lewo.

Więc myślę, że to jest takie narzędzie, które jest w stanie fajnie poinstruować użytkowników, współpracowników, gdzie jest co, nie? Dokładnie, małe demo, mały filmik instruktażowy, nawet na zasadzie onboardingu, można komuś szybko coś wytłumaczyć, jak na przykład się wewnątrz firmowo czy rozwiązuje jakieś rzeczy, czy gdzie coś jest, na zasadzie takiego, powiedzmy, bardzo prostego nawet, nie wiem, tutoriala w kontekście samego Slacka, a z racji tego, że to jest, no właśnie, to jest dalej jakiś plik w jakimś formacie wspieranym przez Slacka, w dalszym ciągu mamy możliwość wyszukiwania tego w Slacku, możemy to zamknąć w kanwasie i nawet zbudować taki, no może nie dashboard, bo to nie w tą stronę, ale nawet takiego, wiecie, dedykowanego kanwasa, który będzie przechowywał na przykład takie onboardingowe materiały, jak to się teraz ładnie nazywa. Przypomniał mi się jeszcze jeden fajny przykład, właśnie już a propos tego wspomnianego domu mediowego, tam jedna z osób to jest oczywiście montażysta, który nagrywa klipy zamiast renderować te filmy od razu, nie? Więc jeżeli potrzebuje nagrać mały kawałek filmu, nie musi go renderować, tylko nagrywa klip bezpośrednio ze swojego programu, który montuje, tak, żeby móc pokazać reszcie zespołu, co zrobił i czy to jest okej, zamiast stracić czas na renderowanie, po prostu wysyła to w fragmentach przez klipy na kanał i tam są w stanie sobie komentować to, co powinno być zmienione, co jak sklejać i tak dalej, nie? Super opcja. Wiecie co, rozmawiamy o Slacku, nazywamy Slack jako platformę współpracy, więc wymieniliśmy sobie jakieś funkcjonalności, ale żeby nazywać to platformą, to jest zdecydowanie za mało, tak? Że mamy jakieś funkcjonalności, więc jeżeli myślimy o platformie, to pojawia się temat chociażby automatyzacji.

No i powiedzcie, żeby obronić tę naszą tezę, czy Slack ma jakieś opcje automatyzacji? Jak sobie poradził z tym wątkiem? Jakie mamy możliwości Slacku? Nie wiem, czy mamy tyle czasu. Oj tak, to prawda. Omówmy to najważniejsze i troszeczkę na wyższym poziomie, nie? Ja spróbuję ze swojej strony tak w miarę takiej developerskiej, w miarę sensownie i logicznie, ale tak jeszcze abstrahując trochę od samych tych narzędzi, ale w kontekście tego całego platformowania, to najlepiej widać na planie Enterprise, gdzie możemy stworzyć nieskończoną ilość workspace’ów, które są ze sobą, mogą być ze sobą powiązane i możemy tworzyć na przykład tak zwane org wide channels, czyli kanały, które tak naprawdę przechodzą bezpośrednio przez wszystkie stworzone workspace’y i to fajnie pokazuje, że tak naprawdę to, co my mamy na planie, czyli darmowym, pro-biznes, to jest tylko namiastka tego, co tak naprawdę można osiągnąć na Enterprise gridzie.

Wiesz co, jeszcze jakbyś wytłumaczył, co to są workspace’y w Slacku. Jasne, jakby ja nazywam to tak mądrze workspace, bo to jest taka oficjalna nomenklatura, natomiast Piotrek już o tym wspominał, że tutaj jakby poprzez workspace mamy na myśli pojedynczą instancję Slacka, czyli pojedyncze środowisko, gdzie po prostu jesteśmy zaproszeni w tą stronę, więc jakby każdy taki workspace to jest jedna instancja na planie Enterprise grid, możemy mieć ich nieskończenie wiele i one mogą być jakby świadome siebie i skomunikowane ze sobą albo mogą stać jako jakby osobne, czy nawet ukryte byty, ale to tak tylko w kontekście samej platformy, a nie automatyzacji. Natomiast wracając do Sedna, to tak, z jednej strony mamy workflow buildera, tak, to jest kupione zewnętrzne narzędzie, które zostało w jakiś sposób zintegrowane ze Slackiem, jest to narzędzie typu no code, więc generalnie każdy powinien być w stanie to zbudować, jeżeli ktoś zna Salesforcea, pracował, wie czym jest flow, akcje, które nie wymagają znajomości jakby wiedzy programistycznej, można po prostu jakby zbudować sobie następujące po sobie wykonujące się akcje i generalnie mamy tak naprawdę jakąś tam automatyzację.

Oczywiście możemy też budować… Poczekaj, to poproszę Cię od razu przykład, nie, żebyśmy sobie mogli wyobrazić. Dobrze, nie ma problemu, ja bardzo lubię temat onboardingu, ja na przykład rozwijam u siebie to gdzieś tam tak ad hoc i na zasadzie, że stworzyłem dla dziewczyny automatyzację, która jest wywoływana przez kliknięcie na link. W Slacku to jest pokazywane jako zwykły baton albo jako bookmark w kanale, więc generalnie osoba klika sobie taki batonik, wywołuje jakby automatyzację, prosty formularz, nazwa kanału, użytkownicy, których chcesz zaprosić i generalnie z tego, co pamiętam, tyle.

I potem tylko tak naprawdę kolejny baton, submit. To, co się potem dzieje, to jest tworzę prywatny kanał, na którym automatycznie podlinkowuję wszystkie zasoby, z których my korzystamy w procesie onboardingu. Zapraszam wszystkich użytkowników, którzy zostali wybrani.

Oczywiście nazwa kanału jest w oparciu o to, co dana osoba wpisała. Każdemu użytkownikowi tworzę prywatny kanwas z listą tasków, które trzeba zrobić i ponadto jeszcze tworzę też dodatkowy kanał do pracy dla ludzi odpowiedzialnych za cały proces onboardingu. I tak naprawdę osoba tylko wymyśla nazwę kanału i wybiera osoby, które zaprasza, a reszta dzieje się pod spodem i tak naprawdę największy efort to content.

Jeszcze bym zapomniał, jeszcze w międzyczasie, jak osoby zostają zapraszane do tych kanałów, to też dostają prywatną wiadomość, taką onboardingową, i tam są też takie instrukcje itd., więc największym wyzwaniem paradoksalnie nie było zbudowanie samej automatyzacji, co napisanie ładnego, user-friendly, konkretnego contentu na poszczególne etapy. I wszystko tak naprawdę bez wiedzy deweloperskiej, za pomocą standardowych, predefiniowanych akcji, które dostarcza nam Slack na płatnym planie. I wiadomo, jeżeli ktoś jest już trochę rozeznany, to tak naprawdę 30 minut wyklikania i tyle, nic więcej.

Nie 30 minut pracy, a osoba, która wcześniej musiała robić wszystko manualnie, tworzyć kanały, zapraszać ludzi, każdemu indywidualnie wysłać jakieś maile, jakieś powiadomienia, wszystko jest w jednym miejscu, całe… Czyli jak duża, duża oszczędność czasu, nie? Tak, a cały proces trwa, no nie wiem, chyba z 20 sekund, no bo tam zanim on sobie utworzy bukmarkiet, to gdzieś tam chwilę mu zajmuje, nie? Ale tak w dużym skrócie, nie? To jest jakby jedna rzecz. Druga, z racji tego, że mamy API, jak najbardziej to jest dostępne wszędzie, możemy budować zewnętrzne aplikacje, które się komunikują ze Slackiem za pomocą tych API. Oczywiście zewnętrzne, czyli hostowane na zewnętrznym serwerze czy platformie typu, nie wiem, Wercel, Heroku i tak dalej, ale tu mówimy już o budowaniu stricte aplikacji.

Oprócz tego oczywiście mamy też marketplace, tak samo jak w przypadku Salesforce’a, AppExchange, więc generalnie możemy korzystać już z gotowych aplikacji zbudowanych tudzież płatnych, tudzież przez takich partnerów technologicznych jak na przykład Google, Microsoft, Dropbox i tak dalej, ale też ostatnim takim większym featurem, poniekąd możemy to podciągnąć, dlatego że zostali podkupieni może przez Salesforce’a, kto wie, ale jest coś, co się nazywa ładnie Next Gen Apps, przynajmniej to było takie pierwotne nazewnictwo. To generalnie to jest coś, co już faktycznie w moim mniemaniu możemy bardzo mocno podciągnąć pod aspekt platformy, ponieważ to rozwiązanie pozwala nam budować customowe aplikacje, customowe automatyzacje z dostępem do wbudowanej w Slacka bazy danych automatyzacji i to jest coś, co możemy deployować, tudzież instalować, może tak będzie bardziej nietechnicznie, bezpośrednio na nasz workspace, na naszą instancję Slacka i generalnie nic nie wychodzi poza tzw. cztery ściany, tak wszystko jest przechowywane wewnątrz tej platformy.

Czy coś jeszcze mi przychodzi do głowy? Mi na razie wystarczy. Lubicie nasze rozmowy o Salesforce? Kliknijcie subskrybuj i bądźcie na bieżąco z każdym nowym odcinkiem. Twoja kolejna porcja inspiracji już w drodze.

Dołącz do nas. Dużo fajnych funkcjonalności nam, Piotrek. Jak już jesteśmy z Salesforce’owi, to jeszcze może wypadałby wspomnieć właśnie o tej integracji Salesforce’a ze Slackiem.

To jest moje kolejne pytanie, bo to na pewno jest ta część, która się zmieniła po akwizycji Slacka przez Salesforce’a. Przecież Salesforce i tu możemy też na przykładzie integracji ogólnie omówić, co zrobił i jaki był pomysł trochę Salesforce’a na tego Slacka i jak m.in. wykorzystał integrację. To tak.

Historia, którą ja znam. Na początku mieliśmy dostęp do aplikacji właśnie na tym ApexChange’u. Michał, przypomnij mi, proszę, nazwę oficjalną tego sklepu.

ApexChange? Nie, nie, nie. To jest Salesforce’owy, a Slack’owy? App Directory. Slack App Directory.

Więc tam pojawiło się kilka aplikacji. Salesforce for Slack, Service Cloud for Slack, Sales Cloud for Slack, CRM Analytics for Slack. Ciężko było na początku się połapać, która robi co, po nazwie coś tam dało radę i rozróżnić.

Więc one w taki troszeczkę niedoskonały sposób, niedoskonały mam na myśli interfejs użytkownika, były w stanie tworzyć rekordy. Z poziomu Slack w Salesforce’ie mogliśmy te rekordy przeglądać, mogliśmy w taki troszeczkę ograniczony sposób przeglądać nasze opportunities, pipelines. Jesteśmy w stanie wysyłać nasze dashboardy, snippet naszych dashboardów na kanały o odpowiednich godzinach, po prostu wybierając jako ten kanał dystrybucji odpowiedni kanał Slack.

I te aplikacje były nie do końca doskonałe, nie do końca była do nich dokumentacja. Miałem taką sytuację z tymi aplikacjami, że na dwa dni przed prezentacją dla klienta po prostu wszystko przestało działać. Północy siedziałem, mówię, co jest nie tak, czy wszystko wygląda okej.

Złożyłem ticket do Slacka, powiedzieli gościu, nic się nie martw, masz tutaj linki do działających wersji, to my tam kiedyś opublikujemy. Mówię, o Jezu, dobrze, że się udało, bo prezentacja była tuż tuż, więc nie było łatwo, dokumentacji też brakowało. Później, o ile się nie mylę, proszę Michale, popraw mnie, jeżeli się mylę, pojawiły się akcje slackowe w flowach.

W tych flowach, które znamy z Salesforce’a. Tak i nie. Tak nawiązując do tego, co powiedziałeś, to jeżeli ktoś już pracuje trochę czasu w ekosystemie Salesforce’a i ma duże doświadczenie z paczkami budowanymi przez zespół Salesforce’a, to wie, że czasem nie wszystko działa, żeby nie wchodząc za bardzo w detale, ale generalnie, jeżeli ktoś sobie przejrzy rating tych aplikacji na AppExchange’u i przeczyta komentarze, to zrozumie, o co chodzi.

Natomiast potem, będąc szczerym, nie wiem, czy akcje flowowe są dostępne out of the box. Chyba i tak trzeba skonfigurować, bo jest dostępny teraz, żeby to brzmiało logicznie, tak jak mówisz, wcześniej były aplikacje na Slacku, paczki na Salesforce’ie, natomiast teraz już jest dedykowana sekcja poświęcona Slackowi w Salesforce’ie i tam już się konfiguruje konkretne ustawienia pod Sales Cloud, Service, chyba Marketing, nie wiem, czy jest już więcej, czy na razie tylko te trzy i tam faktycznie już wtedy można sobie trochę jakby pomanipulować tymi ustawieniami i chyba dopiero w tym momencie masz dostęp do jakichś tych predefiniowanych akcji we flow. Ale nie jestem pewny, może to jest out of the box.

Nie, oczywiście ja myślę, że one są out of the box. Tak, ja mam wrażenie. W sensie, nie pamiętam.

A, możliwe, że po zainstalowaniu dopiero paczki i tej companion apps one się pojawiają. Racja. Mówię, nie pamiętam, nie będę… Tak, one są do użytku i możemy wysyłać informacje z Salesforce’a do Slacka, możemy wysyłać approval requests na dany kanał, tak, żeby nasz menadżer miał wygodnie wszystko z poziomu jednego kanału.

Możemy tworzyć kanały, możemy, nie wiem, wysyłać alerty, tak, nie wiem, powiedzmy, nasza opportunity zbliża się, taki oklepany przykład, ale nie wiem, już niedługo nasza opportunity ma close date, nie? Jest tydzień do tej daty, a jeszcze nie jest osiągnięty dany stage, więc możemy wysyłać takie alerty, żeby powiadomić, nie wiem, menadżerów czy zespół, że halo, trzeba coś zrobić z tym opportunities, bo przegramy, nie? Więc tak, Salesforce ściśle współpracuje ze Slackiem, no i cały czas dochodzą nowe narzędzia, tak? Slack Sales Elevate to już jest, co prawda, płatne, ale narzędzie, które już w dużo lepszy sposób pozwala na manipulowanie, tworzenie rekordów Salesforce’owych z poziomu Slacka, nie? Więc widać, że Salesforce i Slack nad tym pracują, żeby te platformy wyglądały i współpracowały jak najbardziej tylko mogły. Zresztą to, co widzimy teraz w Slacku, ten UI, który w sposób przedstawiania tych opportunitiesów, tak jak on wygląda teraz w Slacku, prawdopodobnie już niedługo będzie wyglądał tak w Salesforce, nie? No bo jak wiemy, nadchodzi też revamp Salesforce’owego UI-a i on właśnie będzie, z tego co widziałem na screenach, będzie właśnie na to modłę slackową. Trochę idea jest taka, że na co dzień pracuję, komunikuję się z zespołem, rozmawiam sobie tutaj na kanałach i w tym momencie bez potrzeby zaglądania, otwierania przeglądarki, wchodzenia w Salesforce’a, mogę wiele operacji, które bym tylko wcześniej robił na orgu, na Salesforce’ie, mogę teraz robić to w Slacku, tak? Tak jest, dokładnie.

Plus możemy dyskutować rekordy w zespole, tak żeby np. sprzedać szybciej albo rozwiązać czyjś problem szybciej i zespołowo. Czyli możemy z kanału, możemy mieć przypięte konto do kanału i wtedy wszyscy wiedzą, co dyskutujemy, tak? Ja jeszcze tylko dodam, że jeszcze tego nie zbadałem, ale to zostawię na razie na swojego bloga, ale gdzieś czytałem, że ponoć nawet można, chyba już w tym momencie, wysyłać screen flowy z Salesforce’a do Slacka, w Slacku uzupełnić to jako formularz i to wraca z powrotem do Salesforce’a.

Też wiem, że oczywiście to są takie tematy, że wszyscy by chcieli w końcu wymienić chatera i zastąpić to Slackiem, natomiast wiadomo, wbudowanie Slacka w Salesforce’a to podejrzewam, że jeszcze trochę albo nigdy. Natomiast wiem też, że nawet chyba na zeszłorocznym Dreamforce’ie pewna ekipa próbowała w taki dość oryginalny sposób jakby zamokować, czyli jakby udawać, że budowali Slacka bodajże w community na Salesforce’ie. Oczywiście w oparciu o jakieś tam customowe obiekty i pola tam odpowiadały za jakieś tam rich teksty i tak dalej, łącznie z tym panelem i tak dalej, i potem to wszystko trafiało do Slacka i jak ktoś odpowiadał na Slacka, trafiało na community, więc generalnie oficjalnej integracji nie ma, ale to po prostu obeszli trochę ograniczenia właśnie tych dwóch platform w taki dość ciekawy sposób, więc kto wie, może kiedyś to się jakoś bardziej rozwinie.

No i tak, w kontekście tego Sales Elevate, tak jak już wspomniałeś, tu idziemy trochę taką modelą Salesforce’ową właśnie add-ony i dodatkowe koszty, no ale też to widziałem teraz na World Tour London, jak byłem, to też są pomysły, żeby zrobić coś podobnego pod kątem ponoć Service Clouda i też są jakieś tam pomysły, żeby mimo wszystko bardziej… to trochę bardziej idzie w kierunku, może nie tyle, że przeniesienie jakby, wiecie, Slacka w Salesforce’a, co bardziej pewnych rzeczy ze Salesforce’a na UI Slacka, żeby móc bezpośrednio pracować nad jakimiś tam właśnie obiektami, rekordami, nie tylko Opportunity, bo na razie to się wszystko to rozbija, ale to, jak zawsze, czas pokaże. Rozmawiamy sobie teraz trochę o technicznych aspektach, mówimy integracja, mówimy automatyzacja, więc zostaniemy jeszcze chwilę przy tych technicznych rzeczach, no to od razu też pojawia się taki aspekt, no dobra, trzeba tworzyć, tak? I mamy tutaj trochę dwie perspektywy. Administrator Slacka, deweloper Slacka, jak jeszcze dewelopera w Salesforce’ie, to już opowiadaliśmy sobie i to też Michał Kocował wcześniej gościem u mnie, więc też możecie posłuchać jego historii, jak ta historia deweloperska wyglądała.

No to jak ja mogę sobie wyobrazić, jak wygląda development, rola dewelopera Slacka? To zależy. Nie, a tak szczerze, no to jest kilka rzeczy, z którymi na tą chwilę trzeba się, no nazwijmy to, pogodzić, bo wiem, że nie każdemu pasują pewne rozwiązania obecnie podjęte jakby przez firmę Slack. Z jednej strony mamy te zewnętrzne aplikacje, które tak naprawdę są przez nas utrzymywane na jakichś zewnętrznych serwerach, na zewnętrznych platformach i jedyne, co robią metaforycznie, to komunikują się poprzez API.

Więc z jednej strony możemy podejść do tego na zasadzie, że tak jakbyśmy budowali jakikolwiek inny projekt developerski, w sensie taki trochę serwer komunikujący się z API, natomiast w praktyce to wygląda trochę inaczej. Można to trochę przyrównać do Salesforce’a w momencie, w którym chcemy budować jakieś aplikacje na Salesforce albo konfigurujemy credentials albo connected app i tak dalej, musimy tam jakąś pracę wykonać po stronie platformy. Podobnie to wygląda na Slacku.

Mamy dedykowany panel, gdzie możemy po prostu stworzyć jakby taką początkową konfigurację aplikacji, gdzie możemy decydować o tym, do jakiego API, do jakiej metody, tak naprawdę do czego ma dostęp dana aplikacja. Musimy też dokonać pewnych wyborów na zasadzie czy dana aplikacja działa w kontekście jakiegoś użytkownika, czy tylko w kontekście jakby systemowym, co też się wiąże trochę z takimi technikami, jak właśnie już autoryzacja, tokeny i inne tego typu niskopoziomowe, nazwijmy to, tematy. Natomiast potem tak naprawdę, jeżeli już przybrniemy przez ten temat, no to tak naprawdę tworzymy taką backendową aplikację, która się robi tak zwane callouty za pomocą głównie protokołu HTTP do Slacka i poprzez nasz kod, poprzez te wywołania tych metod wykonujemy pewne akcje po stronie samego Slacka.

Polączka powiedzmy jest taka, że oczywiście Slack jak najbardziej wspiera tego typu inicjatywy, jakby mamy trzy predefiniowane, znaczy trzy, ale jeden predefiniowane frameworki do tego, mamy coś takiego, co się nazywa Bolt, to jest jakby taki trochę wyższy poziomowo framework, czy zbiór jakby funkcji, które możemy wykorzystać przy pisaniu aplikacji, no ale jest to framework napisany głównie dla Javascriptu, Java i Pythona z tego, co kojarzę, reszta niestety musi być wspierana i tworzona przez tak zwane community. Jeżeli chodzi o przekazywanie jakby kontentu poprzez te funkcje i API, Slack ma swój własny jakby syntax, czy składnię czegoś, co się nazywa markdown, więc też wypuścili takie narzędzie, gdzie możemy testować jakby strukturę tych wiadomości, jak one będą wyglądały stricte po interpretacji przez Slacka, czyli generalnie my piszemy jakby jakiś kawałek tekstu w formacie JSON, jeżeli komuś to coś mówi, a w drugim okienku mamy tak naprawdę już wizualną reprezentację tego, jak to będzie wszystko wyglądało na Slacku. To jest jakby takie jedno rozwiązanie, drugie już powiedzmy, że nowsze, ten tak zwany next-gen apps, już hostowany i trzymany na platformie Slacka.

To już jest troszkę gorzej dla niektórych, na szczęście nie dla mnie, ponieważ to jest rozwiązanie póki co wspierane tylko przez TypeScript, a wiem, że sporo deweloperów ma problem z pracą z JavaScriptem czy TypeScriptem, woleliby coś bardziej statycznego, więc wiem, że to jest taki dość wysoki próg wejścia, gdzieś tam rozmawiamy z ekipą ze Slacka, żeby chociaż rozważyli Pythona, bo to już ma jakby trochę większą tolerancję dla deweloperów, natomiast to już jest z kolei jeszcze inny narzędzie, jakby cała ta koncepcja działa już na trochę innych technologiach, bo zamiast na, mówię, że ktoś się obraca w ekosystemie JavaScripta, na pewno będzie kojarzył, tu już nie używamy Node’a, korzystamy z Dino, to jest jakby twór tego samego autora, tego samego twórcy, ale jakby to jest jego odpowiedź na kilka błędów architektonicznych, których dokonał w tym pierwszym narzędziu, więc tu już mówię, już wchodzi TypeScript, już wchodzi Dino i tak naprawdę też mamy dedykowany wiersz poleceń, w sensie narzędzie CLI do deployowania i pracy z tym wszystkim, więc jakby to są takie dwie ścieżki. Oczywiście w tym roku też Slack już wypuścił jakiś tam zalążek czegoś, co się nazywa Developer Program, czyli generalnie już taka inicjatywa, taki ukłon z ich strony, że już dają taki szerszy dostęp do planu Enterprise, gdzie już faktycznie możemy z najnowszymi featurami testować nasze aplikacje, bo to też jest dość istotne, że trzeba bardzo mocno rozważyć, czy chcemy budować aplikacje, które będą wspierały pojedyncze instancje Slacka, pojedyncze workspacy, czy chcemy budować aplikacje, które będą mogły być zainstalowane na tym planie Enterprise. To wynika z tego, że jak mamy pojedynczą instancję, to jakby ten użytkownik ma dostęp do jednego miejsca, aplikacja jest przypisana jakby, tak to określmy, do jednego workspace’a, do jednej instancji, natomiast w Enterprise’ie, jeżeli mamy nieskończoną ilość workspaców, to to musi być jakoś zarządzane, więc tutaj już jakby jest trochę bardziej taki zaawansowany temat, jeżeli chodzi o całe takie, to się ładnie nazywa authorization flow.

Myślę, że to możemy sobie kropkę postawić, bo dużo rzeczy gdzieś tam… Jedyne, co tylko, wiesz co, jeśli jeszcze mogę, to jedyne, co tylko dodam, bo to wiem, że tak może wyglądać trochę strasznie, natomiast tak uważam, że Slack ma bardzo fajną dokumentację techniczną, gdzie bardzo dużo rzeczy jest wyjaśnione, są przykłady, jeżeli chodzi o workflow’y, są przykłady, jeżeli chodzi o te takie standardowe, starsze aplikacje, są przykłady, jeżeli chodzi o te next genowe aplikacje, więc można naprawdę jakby, wiadomo, to nigdy nie jest wystarczająco dużo, ale jest całkiem sporo zasobów na ich stronie takiej technicznej, na czym można faktycznie trochę bazować, można od tego zacząć i w miarę, wiadomo, nabywania umiejętności można pójść gdzieś tam dalej na własną rękę. Czyli ma co deweloper w Slacku robić, jest cała masa różnych rzeczy i koncepcji. I tu zakończymy drugą część naszej rozmowy dotyczącej platformy Slack, a w trzeciej, ostatniej części będziemy rozmawiać o implementacji Slacka w organizacji, zastanowimy się nad kluczowymi krokami w procesie wdrażania Slacka, jakie są wyzwania, jakie mogą się pojawiać oraz jak je pokonywać oraz przyjrzymy się troszeczkę krytycznym okiem odnośnie Slacka, odnośnie ich funkcjonalności oraz konkurencji.