Twórz Własne Automatyzacje
3 godz. 14 min · Make · Biznes i Automatyzacje
Adam GospodarczykKorzystając z różnych narzędzi, na przykład do obsługi mailingu, masz do dyspozycji na ogół kilka wbudowanych integracji - przykładowo połączenie z kalendarzem czy bramką płatności. Wyobraź sobie, że takie narzędzie możesz połączyć praktycznie z dowolnym innym, nawet jeśli nie ma go na liście. To właśnie potencjał Make, które umożliwi takie automatyzacje.
Jeśli znasz Zapier, Make to podobna koncepcja, ale daje dużo bardziej zaawansowane możliwości, jest dużo tańsza (lub darmowa) a dodatkowo, ma naszym zdaniem bardziej przyjazny i czytelny interfejs zwłaszcza przy tworzeniu rozgałęzionych scenariuszy. Tworzenie automatyzacji z Make to czysta przyjemność i zdrowa porcja dopaminy!
Co najważniejsze, Make umożliwia tworzenie automatyzacji bez użycia ani jednej linii kodu! To jak programowanie 2.0, gdzie rezultaty widzisz i testujesz w prostym, wizualnym edytorze. To najłatwiejszy sposób aby zacząć przygodę z programowaniem i nowoczesnym podejściem do technologii no-code i low-code.
Mimo, że Make jest natywnym środowiskiem no-code, osoby, które nieco lepiej rozumieją zasady działania protokołu HTTP i API i mają podstawy programowania w JS, otrzymują zupełnie nowe możliwości tworzenia oprogramowania, w sposób wizualny i prostszy niż kiedykolwiek. Jeśli osoby początkujące z Make stają się programistami, programiści stają się superbohaterami!
Wyjątkowe w Make jest podejście do tworzenia automatyzacji wizualnie, gdzie bardzo czytelne jest całe flow scenariusza i to, jak przepływają w nim dane. Zaawansowane możliwości jak stosowanie filtrów czy funkcji sprawia, że w tak prostym interfejsie w zasadzie nie ma zadań niemożliwych!
Z dowolnego narzędzia możesz wysłać dane w postaci Webhooka do Make, które zostaną natychmiastowo odebrane. Następnie możesz łatwo przekazać je w dowolne miejsce i do dowolnego narzędzia - na przykład Airtable, z którego często korzystamy aby gromadzić dane, HubSpot'a, Asany czy wysłać powiadomienie SMS, e-mail, Slack. Całość zajmie Ci kilka minut.
Ten kurs jest przeznaczony dla każdej osoby, która chce pracować wydajniej i zatrudnić roboty (automatyzacje), które wykonają za nią powtarzalne zadania. Dzięki temu, zwiększysz efektywność swojej pracy oraz zostaniesz bohaterem automatyzacji w swojej firmie. Osoby, które przerobiły kurs HTTP i API, a także programiści, mogą wycisnąć z tego kursu jeszcze więcej, na dobre zmieniając swoje podejście do automatyzacji. Polecamy wcześniejsze przerobienie przynajmniej kursu HTTP i API, aby lepiej zrozumieć omawiane zagadnienia.
Cześć! W tej lekcji pokażę Ci zaawansowane
techniki dotyczące organizacji automatyzacji w ramach Integromat'u.
Chodzi o to, że tworzenie automatyzacji jest bardzo fajne.
Natomiast w momencie, gdy nie dbamy o
fundamenty, o których mówiłem w poprzednich lekcjach, takie jak
odpowiednie nazewnictwo poszczególnych elementów naszej automatyzacji, to bardzo
szybko dochodzimy do sytuacji, w której nie jesteśmy w stanie się w niej odnaleźć.
Natomiast jednocześnie muszę powiedzieć,
że nawet w momencie, gdy dbamy o te wszystkie fundamenty i tak przy pewnej
skali możemy dojść do sytuacji, w której odnalezienie jakiejś automatyzacji będzie
dla nas wyzwaniem lub też po prostu nie będziemy pamiętać, że jakaś automatyzacja
jest już przygotowana i tym samym będziemy duplikować sobie pracę.
Zatem podzielę się teraz z Tobą
zaawansowanymi technikami, które wykorzystujemy wspólnie z Grzegorzem.
Mianowicie pierwszym rodzajem podziału
automatyzacji, który stosujemy są organizacje.
Natomiast tutaj trzeba pamiętać o tym, że
każda z tych organizacji musi mieć wykupione oddzielny plan.
Oznacza to, że jeżeli mamy już zupełnie
oddzielne projekty, które nie powinny być mieszane ze sobą, warto oddzielić nową
organizację, opłacić dodatkowy plan i tam organizować sobie wszystkie scenariusze.
W naszym przypadku istnieje logiczne
uzasadnienie, dlaczego mamy akurat taki podział.
Przykładowo w ramach konta overment, mam zorganizowane wszystkie scenariusze
prywatne, które w żaden sposób nie będą łączyć się z pozostałymi organizacjami.
Taki podział na organizacje ma też dość duże uzasadnienie w momencie, gdy mamy
jakiś większych klientów, dla których wykonujemy automatyzację.
Mianowicie chodzi o to, że w ramach
każdego klienta możemy zorganizować sobie np.
połączenia czy webhook'i.
Przykładowo w przypadku mojego prywatnego
konta, a raczej połączenia nazywamy po prostu nazwą mojego projektu.
Jak widzisz, poza tą prostą regułą nie ma
tutaj jakiejś bardzo skomplikowanej logiki dotyczącej nazewnictwa połączeń.
Natomiast czasem zdarzają mi się sytuacje,
w której tworzę jakąś prostą automatyzację dla jakiś oddzielnych projektów, które
tutaj chcę jasno oddzielić od moich pozostałych projektów.
Z tego powodu zawsze w nazwie połączenia uwzględniam nazwę tego projektu.
Jest to o tyle ważne, że w momencie, gdy
będziemy teraz tworzyć nową integrację, to w momencie wybierania akcji oraz
połączenia możemy się łatwo tutaj pomylić i wykonać akcję na błędnym połączeniu.
Coś takiego zwykle zakończy się błędem, natomiast zwracam Twoją uwagę, że nie
zawsze musi tak być, a już szczególnie w momencie, gdy spróbujesz wykonać jakąś
akcję wykorzystującą bezpośrednie połączenie z API.
Z tego powodu warto być tutaj bardzo ostrożnym, tym bardziej, że w momencie gdy
będziemy tworzyć kolejne moduły, to Integromat lubi nie zapamiętywać tego domyślnie
wybranego połączenia, tylko wybierać pierwsze, które znajduje się na liście.
Z tego powodu, jeżeli tworzę sobie kolejne moduły, mogę łatwo się pomylić i
doprowadzić do sytuacji, w której rzeczywiście tutaj wybrałem połączenie
Overment Slack natomiast tutaj tworząc nowy moduł mam połączenie Claire.
Naprawdę warto o tym pamiętać w kontekście
zarówno organizacji, jak i późniejszego tworzenia scenariuszy.
Kolejną rzeczą, na którą warto zwrócić uwagę są nazwy webhook'ów.
W związku z tym, że Webhook'i tak
naprawdę nawet nie różnią się ikonką, musimy zadbać o ich odpowiednie nazwy.
Akurat muszę przyznać, że na moim
prywatnym koncie panuje tutaj mały bałagan.
Natomiast jednocześnie zachowuję tutaj taką ogólną strukturę, która pozwala mi
identyfikować Webhook'i w bardzo szybki sposób.
Dodatkowo w przypadku webhook'ów zwykle
jest tak, że będziemy je przypisywać tylko do jednego scenariusza.
Zatem dobra wiadomość jest tutaj taka, że raczej będą one bezpośrednio powiązane ze
scenariuszami, w których je wykorzystujemy.
Natomiast czasem może zdarzyć się tak, że będziemy chcieli wykorzystać webhook
ponownie i w tym momencie dodatkowa nazwa okaże się tutaj niesamowicie przydatna.
Także w temacie nazw weebhook'ów oraz połączeń czy w ogóle scenariuszy polecam
wypracować własną strukturę nazewnictwa, aczkolwiek musi być ona zorganizowana tak,
aby identyfikacja konkretnego zasobu była natychmiastowa.
Oznacza to, że w momencie, gdy otworzysz listę połączeń, zidentyfikowanie tego,
o które Ci chodzi powinno być natychmiastowe.
Jednocześnie chciałbym podzielić się tutaj
pewnym błędem, który popełniłem w momencie gdy organizowałem w swojej webhook'i
poprzedzając je prefix'em, w tym przypadku stanowiącym imię mojego bota.
Okazuje się, że coś takiego jest mało użyteczne z prostego powodu.
W momencie, gdy rozwijamy listę
webhook'ów czy połączeń, możemy zacząć wpisywać pierwsze litery nazwy i w ten
sposób webhook zostanie odnaleziony na naszej liście.
W przypadku, gdy posiadamy prefix taki jak mój.
Coś takiego jest albo niemożliwe, albo po prostu bardziej skomplikowane.
Z tego powodu lepiej by było doprowadzić do sytuacji, w której na początku mam
nazwę mojego webhook'a, a dopiero potem przypisanego do niego bota.
Kolejnym elementem, odgrywające ogromną
rolę w kontekście organizacji scenariuszy są foldery,
mianowicie ja obecnie jestem na etapie
redukcji moich automatyzacji i upraszczania ich w taki sposób, aby
zarządzanie nimi było zdecydowanie prostsze.
Z tego powodu większość automatyzacji, które posiadałem zostały w tej chwili albo
wyłączone, albo zupełnie usunięte ze względu na to, że albo nie
spełniały już swojej funkcji albo zastąpiły je inne, prostsze scenariusze.
Dodatkowo w kontekście samych folderów.
Jak wiesz, od jakiegoś czasu wykorzystuję
kategoryzowanie moich automatyzacji w ramach botów oraz imion, które im nadałem.
Chodzi tutaj o to, że w momencie gdy miałem rozbudowaną strukturę katalogów, za
każdym razem musiałem zastanawiać się, czy podczas tworzenia nowego scenariusza
tworzyć również nowy folder, bądź też przydzielić go do istniejącego, co nie
było wcale prostym zadaniem w momencie, gdy miałem kilkadziesiąt folderów.
W tym momencie podział moich automatyzacji na boty nie tylko sprawdza się całkiem
dobrze, ale również daje mi mnóstwo frajdy.
Co prawda, jak widzisz w tej chwili do
każdego bota przypisanych jest dosłownie kilka makr.
Natomiast widzę już potężną różnicę,
ponieważ dokładnie taką samą strukturę mam zachowaną w Zapierze.
Czy np. Keyboard maestro
dzięki temu jestem w stanie łatwo odnajdywać powiązania pomiędzy
automatyzacjami, które występują pomiędzy różnymi systemami.
Mało tego, tutaj zdarzają się sytuacje, w których jeden scenariusz wywołuje drugi i
jest to najbardziej zaawansowana i jednocześnie najbardziej elastyczna forma
organizacji scenariuszy, na którą do tej pory wpadłem.
Mianowicie ten scenariusz należy do Jenny, która przygotowuje informacje o
nowo przeczytanej książce, którą potem chce umieścić w social media.
Aby to było możliwe, musi skorzystać z
pomocy Nicky, która przygotuje dla niej grafiki.
I tutaj jak widzisz, wykorzystuję moduł
HTTP do tego, aby wykonać zapytanie na webhook, który uruchamia scenariusz
odpowiedzialny za przygotowanie odpowiedniego formatu grafik.
Następnie nawet dochodzi do sytuacji, w
której Jenny uruchamia swój drugi scenariusz, którego rolą jest umieszczenie
informacji o nowym wpisie w mojej ogólnej tabeli dotyczącej wszystkich postów.
Zatem tutaj ta najważniejsza zasada mówi o tym, aby reużywalne akcje scenariuszy
zamykać po prostu w oddzielnych scenariuszach.
Rozpoczynamy od webhook'a.
Mało tego, wykorzystuję funkcję TextExpander'a
do tego, aby odwoływać się do tych poszczególnych webhook'ów i tym samym
wywoływać je z poziomu Keyboard maestro bądź innej aplikacji, która nie jest Integromat'em,
a jednocześnie potrzebuje wysłać dane na wskazany webhook.
To wszystko ma jeszcze dodatkową zaletę, chociażby w postaci takiej, że jakiś czas
temu zamieniłem moduł generujący grafiki na własne rozwiązanie.
W takiej sytuacji zamiast modyfikować
kilkadziesiąt różnych scenariuszy, które miałyby być odpowiedzialne za tworzenie
grafik, w tej sytuacji musiałem to zrobić tylko w kilku miejscach, w których
rzeczywiście funkcjonuje Nicky odpowiedzialna za tworzenie grafik.
Podobnie też jeżeli zdarzyłoby się tutaj
tak, że chciałbym stworzyć dodatkowe formaty, to oczywiście nic nie stoi na
przeszkodzie, ponieważ mogę po prostu skopiować ten moduł, a następnie
uwzględnić adres nowo wygenerowanej grafiki w odpowiedzi tego webhook'a.
Podobnie też mogę robić w drugą stronę, czyli np.
przesłać dodatkowe dane, które zmienią zachowanie tego scenariusza.
Efekt końcowy będzie tutaj taki, że ten
scenariusz będzie miał swoją domyślną ścieżkę, ale już w sytuacji, gdy pojawi
się na webhook'u jakiś dodatkowy parametr, równie dobrze mogę doprowadzić do
sytuacji, w której będzie wykonana ta alternatywna ścieżka i tym samym odpowiedź
z tego scenariusza będzie wyglądała inaczej.
Zatem jeżeli chodzi o najważniejszą koncepcję z tego filmu, to chciałem
podkreślić tą możliwość dzielenia scenariuszy na mniejsze fragmenty, które
zamykasz w takich oddzielnych scenariuszach, które są wywoływane albo
bezpośrednio przez Ciebie, albo przez inne scenariusze z wykorzystaniem modułu HTTP.
Tym bardziej, że na tym etapie wiesz już doskonale w jaki sposób z niego korzystać
i taka organizacja scenariuszy nie będzie stanowiła dla Ciebie już żadnego wyzwania.
Oczywiście ostatecznie wcale nie musisz korzystać z tego rozwiązanie, które tutaj
sugeruję, ponieważ w Twoim przypadku może zupełnie się nie sprawdzić.
Jednocześnie chciałbym zachęcić Cię do
tego, aby eksplorować podobne rozwiązania, bądź też zupełnie inne
podejścia, które sprawdzają się w Twoim przypadku.
Chodzi o to, że zarządzanie dużą ilością scenariuszy to naprawdę duże wyzwanie, na
które również ja nie posiadam jednoznacznej odpowiedzi.
Pokazałem Ci tutaj jedynie moje podejście, które do tej pory sprawdza się całkiem
dobrze, tym bardziej, że jeszcze nie miałem okazji Ci tego pokazywać.
Natomiast w ramach Keyboard maestro
również organizuję sobie scenariusze, uwzględniając grupowanie względem botów.
Oznacza to, że np.
w tym miejscu pojawiają się kolejne
automatyzację, które dotyczą bezpośrednio Rose i zarządzania moimi newsletter'ami.
Efekt końcowy będzie taki, że będę mógł
zarządzać swoimi scenariuszami bezpośrednio z poziomu mojego komputera,
nawet bez konieczności uruchamiania Integromat'u, a dodatkowo ze względu na to, że
automatyzację są rozbite właśnie na takie mniejsze części, daje mi to możliwość
wywoływania ich poszczególnych fragmentów bez konieczności wykonywania kompletnego
scenariusza uwzględniającego wszystkie kroki.
Przykładowo w przypadku Nicky nie muszę
zupełnie wykonywać całego scenariusza odpowiedzialnego np.
za tworzenie postów na Instagramie i
uwzględniać kroków dotyczących tego, że one potem trafiają np.
do Airtable, tylko mogę po prostu wykonać scenariusz
odpowiedzialny za przygotowanie grafiki i tym samym np.
w moim schowku, ponieważ taką opcję daje Keyboard maestro,
mogą pojawić się linki, które kierują bezpośrednio do utworzonych grafik.
Zatem myślę, że warto tutaj podkreślić tą
elastyczność, jaką daje podział scenariuszy na mniejsze kawałki.
Jednocześnie chciałbym Cię przed tym przestrzec, aby nie przesadzać w drugą
stronę ze względu na to, że można tutaj doprowadzić do sytuacji, w której
zarządzanie tymi małymi fragmentami będzie po prostu bardzo uciążliwe.
Mam nadzieję, że tą lekcją udało mi się
zainspirować Cię do przygotowania własnej strategii organizacji i automatyzacji, a
być może również wykorzystać niektóre elementy, które sam posiadam.
Teraz dziękuję Ci za uwagę i zapraszam do kolejnych lekcji.
Cześć!