常见问题
常见问题
如果你常用 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 的完整数据啰！
感谢您的宝贵意见！
