常見問題
常見問題
如果你常用 LINE 與客戶溝通業務往來、傳送帳單、確認預約細節、提醒重要事項……），覺得手動作業（一筆筆整理帳單或預約細項、進 LINE 後台找到指定客戶帳號、傳送資訊給對方）太麻煩，希望找到更自動化、效率更高的方法，Ragic 的「傳送即時訊息」功能是個不錯的選擇。
只要你的客戶帳單、提醒事項，或預約資訊 Ragic 表單上有一個「客戶 LINE user ID」欄位、設計好對應的「傳送即時訊息」按鈕，有需要時就可以一鍵傳送客製化 LINE 訊息給客戶，一鍵傳送多個訊息也沒問題。
不過，客戶的 LINE user ID（常簡稱為 UID，類似 LINE 的「電話號碼、收訊地址」概念）並不容易取得。商家需要透過 LINE 官方帳號（而非私人帳號）在客戶加好友互動時執行特定步驟，才能取得 UID；否則即使是客戶本人，也查看不到這項資訊。
在這篇文章中，我們將示範一種不寫程式、透過 Make 串接，取得商家 LINE 官方帳號好友 UID，並且自動讓這些 UID 資訊統整在 Ragic 表單上（如下圖）的方法。
要示範的 Make 自動化串接流程如下：
藉由這個自動化串接流程，我們會將所有把我們官方帳號加入好友、傳送訊息的紀錄通通整合到一張「事件記錄表」。
後續透過拋轉搭配「欄位值不可重複」的設定， 就可以將事件記錄表上所有出現過的的 LINE user ID 資訊統整歸納到通訊錄上，運用相關資料就會更容易。
這是目前所知方法中，不需要寫程式且較為便利的一種，可以自動獲得一份相對完整的 LINE 通訊錄（包含 UID、頭貼、LINE 暱稱等資訊）。
不過，這個方法無法自動比對出 UID 對應的真實客戶姓名（通常需要客戶直接回訊說明、填答，才能取得），若有需要，會需要手動填寫。
如果你希望取得 UID 時，同步要求客戶填寫姓名與其他通訊資料、並讓 Make 協助自動將這些資訊整合進同一張表單，請另外參考後面的進階教學。
首先，我們要在 Ragic 建立一張「事件記錄表」，我們希望這張表單可以讓我們知道官方帳號發生了哪些「事件」——一般是有新客戶將我們加入好友，或者是收到新的訊息等等。讓電腦幫我們取得做這件事的人的資訊，除了 user ID 以外，也包括對方在 LINE 上顯示的暱稱，甚至是頭貼。
因此它看起來通常會像這樣：
在事件記錄表中，一個客戶可能會有多筆事件資料——他們可能傳送多則訊息，甚至有可能多次解除、加入我們的好友。為了更有效率地整理資料，我們需要製作一個「一位客戶只會有一筆資料」的通訊錄，再將事件資料拋轉至通訊錄上。
這張通訊錄與事件記錄表的架構大致相同，唯一不同之處在於，我們希望在將資料從事件記錄表拋轉過來時，同一個 user ID（LINE 使用者）的資料不會重複。因此你可以直接複製事件記錄表的表單設計，只要記得在通訊錄中為 user ID 欄位加入不可重複的屬性，就能夠確保一個客戶在這張表單中只會有一筆資料了。
接下來，就可以設定從「事件記錄表」拋轉到「客戶通訊錄」的流程了。我們建議你的拋轉方式是：先將未拋轉過的資料篩選出來，再一次執行這些資料的拋轉按鈕。如果你的資料量累積到非常大，那麼這可以有效減低系統的負擔、降低運作時間。設計方式如下：
首先，我們在事件記錄表裡加入一個打勾欄位，命名為「已執行過拋轉」。
接下來，請參考下圖分別製作一個拋轉按鈕、一個更新這張表單欄位值按鈕，再將兩個按鈕合併，別忘了要將「個別按鈕失敗時繼續執行」打勾，這樣當系統在偵測到同一個 user ID 已經被加進通訊錄時，還是會繼續執行下一個按鈕——將事件紀錄標示為「已執行過拋轉」，避免下一次再被嘗試執行拋轉：
三個按鈕都建立完畢之後，你可以自行將拋轉、更新這張表單欄位值按鈕隱藏，只留下合併後的按鈕。
為了讓 Make 可以串接到 LINE，我們需要在 LINE 的後台開啟 Messaging API，它可以讓 Make 和 Ragic 能夠取得官方帳號上發生的事件的細節。
如果你從未做過相關設定，請參考請我們寫的這篇教學步驟來開啟 Messaging API。
在觸發端的選擇上，我們將會使用 LINE 的 Watch Events。
接下來，Make 會向你索取 Messaging API 的「Channel Access Token」以連結到帳號，請根據這裡的教學步驟，登入 LINE Developers 並在後台（Console）:依序點擊你的 Provider、Channel 後，在 Messaging API 分頁的最下方取得 Channel Access Token。
連結帳號後，Make 會提供你一個 Webhook 網址，這個網址能讓 Messaging API 在發現任何事件發生時，可以直接傳送到 Make 提供的這個網址上。
回到 LINE Developers 後台，將這個 Webhook 填入並打開「Use Webhook」，就完成觸發端的設定了。
這個觸發端運作時，會傳送的資料像下圖這樣，它會提供事件的種類，例如新好友、移除好友或收到訊息等等，並附帶使用者的 user ID，讓我們進行後續的設定與操作：
Tips：在預設情況下，Watch Events 會在 LINE 官方帳號有新好友、新訊息，甚至被封鎖、被加入群組時都發送事件紀錄，如果對你來說有點太雜，那麼你可以在觸發端的後面加入一個 filter（篩選器），設定 type 以確保只有符合條件的事件會觸發後續動作端，舉例來說，如果像下圖設定為 follow，那麼就只有在官方帳號被加為好友時，才會觸發後續的流程。
因為 Make 上的 Watch Events 能夠給我們的資訊其實非常有限——我們最多只能知道事件是由哪個 user ID 發生，因此我們需要透過收到的 user ID，回頭再向 Messaging API 請求更多這個 user ID 對應的資訊。
在這一步，我們會利用 Make 上的 HTTP 動作端：Make a request 來進行請求：
要向 Messaging API 取得使用者資訊的語法是 GET，而請求的 URL 是：
https://api.line.me/v2/bot/profile/{userId}
其中的 {userId} 就是觸發端接收到的 user ID，因此要設定成這樣：
接下來，由於 user ID 本身是一串加密的資訊，因此我們除了告訴 Messaging API：我們希望解密這個使用者的資訊以外，還要一併附上我們這裡的鑰匙。要把這個鑰匙附給 Messaging API 的話，請在 Headers 中加入一個 item，並用下列的方式設定：
Name：Authorization
Value：Bearer {Channel access token}
最後，因為 Messaging API 會將我們請求的資訊用一長串的純文字發回來，不過，這串文字在 Make 上看起來就像這樣，沒有將顯示名稱、頭貼等等資訊分開，其他動作端也只能將整個「Data」一起填到欄位中。
所以我們要再請 HTTP 動作端幫我們將這串回應整理一遍，讓顯示名稱、頭貼等資訊都分開。為此，我們要在動作端設定中，將 Parse response 設定為「Yes」。
設定完後，這個動作端會看起來像是這樣：
現在，透過觸發端與 HTTP 動作端，我們可以取得使用者的 user ID、顯示名稱、頭貼、使用語系和狀態文字，這些資訊已經能夠讓你有效在後台分辨每一位使用者了，接下來，我們就讓這些資訊記錄到 Ragic 表單，為他們留下紀錄。
在這裡，我們要用 Ragic 的動作端：Create a record，將資訊建立在我們步驟 1 設計的事件記錄表中。只要將各個資訊填到指定的欄位中就可以了：
接下來，我們來嘗試看看官方帳號發生的大小事件是否能夠順利完成整個自動化流程吧！按下 Make 裡左下角的 Run once，再直接加入 LINE 官方帳號的好友：
回到 Make 可以看到各個動作端都有運作紀錄：
最後直接進到我們設計的事件記錄表，就能看到各個事件發生的詳細紀錄，使用者的 user ID 與暱稱也都有顯示上去囉！
接下來，直接把收到的資料透過先前製作的按鈕拋轉到通訊錄，後續整理資料也就更容易了。
如果通訊錄中已經有這個 user ID，那麼資料拋轉就會被阻擋，確保通訊錄中不會有重複的 user ID，不過「已執行過拋轉」欄位還是會被打勾，讓你透過篩選批次執行按鈕時能更有效率，不會讓拋轉失敗的資料永遠留在篩選中被重複執行。
如果你覺得這些事件、好友在 LINE 上的暱稱、頭貼對你來說沒有太多意義，相反地，你更希望除了 user ID 之外，記錄的通通都是真實姓名或其他聯絡方式等資訊，那麼也許你可以考慮看看讓客戶在事件觸發時，直接收到一份屬於自己的「登錄連結」，客戶在透過這個連結建立自己的資料之後，你就將會看到對方的 user ID 與真實姓名、電話、Email 等資訊，讓你更有效地取得客戶完整資訊。
要注意的是，透過這個方法設計自動化流程的話，Ragic 並不會在事件觸發時留下任何紀錄，只有客戶確實透過連結填寫表單，你才能在表單中看到填表人的 user ID 等資訊。
在這個方法中，我們將會用 Make 設計這樣的流程：
它會在 LINE 官方帳號被加入好友時，傳送一則帶有下圖這種「會員資料登錄表」的訊息給對方：
若對方利用你傳送的連結完成資料登錄，你在 Ragic 表單中就會看到對方填寫的資訊與 user ID 一起顯示出來：
在進階串接裡，我們將會直接讓客戶來填寫自己的資訊，因此我們可以直接按照自己需要的資訊，建立成一張表單，舉例來說，除了客戶的 user ID 以外，知道客戶的真實姓名、性別、電話、Email 等聯絡資訊，對後續溝通來說可能會方便很多，那麼你的表單看起來可能就像這樣：
不過，為了避免客戶在填寫資料時造成誤會，我們需要將某些欄位隱藏，保留起來讓系統自動產生，或者是讓我們後續再做記錄，因此，我們要將這張通訊錄透過多版本工作表，複製出一張隱藏了客戶編號、user ID、備註等欄位的一張「會員資料登錄表」：
接下來，我們要設定 LINE 的觸發端，接收官方帳號的新好友、新訊息等事件，由於操作步驟相同，請點擊這裡查看觸發端的設定方式。
由於我們希望能夠讓客戶自己填寫自己的資料，因此我們會將上一步製作的「資料登錄表」傳送給他們，讓他們填寫自己的基本資訊。不過，因為使用者自己也不會知道自己的 user ID，因此我們需要透過 pfv 參數，來為他們先填上自己的 user ID。具體操作步驟如下：
首先，我們要先在 Make 上加入一個 LINE 的「Send a Push Message」動作端，設定為傳送給觸發端取得的使用者的 user ID，並且先新增一個 Message：
接下來設定剛剛新增的 Message 需要的 Text，在「資料登錄表」上點選分享這張表單，並複製填寫表單用網址：
再把這個網址直接貼到 Text 上，如果需要的話，也可以在這裡設定一些歡迎訊息。
接下來，我們要加入 pfv 參數。這樣一來，即使使用者看不到 user ID 欄位，也不知道自己的 user ID 也沒關係，因為我們透過 Make 取得了他們的 user ID，而透過 pfv 參數，就能夠讓我們預先拿到的 user ID 在他們點開連結時自動填入。
為了實現這個效果，你需要先確認 user ID 欄位的欄位編號，並且將其加入剛剛的網址上。
舉例來說，示範表單的 user ID 欄位編號是 1006047，那麼我們就在填寫表單網址的後方加入「&pfv1006047=」：
最後，再在 Make 上，在這個網址後方加入一個來自觸發端的 user ID 參數，提醒客戶完成資料登錄的訊息、表單網址就完成囉。
現在，你的自動化流程看起來會像這樣：
不過由於 Messaging API 會接收所有事件，所以沒有過濾事件的話，不管你的官方帳號是被新使用者加好友、被封鎖、移除好友，還是接到一則訊息，都會反覆傳送剛剛設定的資料登錄表。為了避免這種情況，我們要加入一個過濾器（Filter），設定只有使用者將我們的官方帳號加入為好友時，才傳送資料登錄表給對方。
點擊觸發端與動作端中間的連接點，如下圖設定只有觸發端的事件種類為「follow」時，才執行動作端，就能滿足我們的需求囉。
完成自動化流程的設計之後，我們來測試一次整個流程吧！直接在 LINE 上加入官方帳號的好友，就會看到其中一則歡迎訊息就是我們剛剛設定的資料登錄提醒：
在 Make 上，也能看到篩選器與自動化流程的運作記錄：
客戶在 LINE 點入網址後，會看到一張簡單的資訊登錄表：
但當客戶填完資料並送出之後，你就能在通訊錄表單上看到包括 user ID 的完整資料囉！
感謝您的寶貴意見！
