DEV Community: Hiro

Sending LINE group alerts from a spreadsheet after LINE Notify shut down

Hiro — Tue, 10 Nov 2026 01:06:44 +0000

Disclosure: this post contains an affiliate link to Make. If you sign up through it, I may earn a commission at no extra cost to you.

For years, LINE Notify was the easy way to send alerts to a LINE group in Japan. It shut down on March 31, 2025. The replacement is the LINE Messaging API, which takes more setup and has a monthly message limit.

I used it to send daily deadline alerts from a spreadsheet to a small production team's LINE group. This post covers the setup, how I stayed inside the free plan, what broke, and what I'd change. The project has ended, so this is a look back at a setup that ran for real.

What it does

The automation sends one LINE message a day listing every task that is due today and not done yet. In Japan, many small teams talk in LINE groups, not Slack or email. So the alert goes where people already look.

The source was a Google Sheet with one row per article. Each row had three steps with a due date and a status: outline done, first draft done, and published.

The stack and the flow

The stack is Google Sheets, Make and the LINE Messaging API. There are two pieces: a one-time setup to get the group ID, and a daily scenario.

Getting the group ID

You cannot see a LINE group's ID anywhere in the LINE app. You have to catch it from an event.

Create a LINE Official Account with the Messaging API turned on.
Point its webhook at a Make custom webhook.
Invite the bot into the group.

When the bot joins, LINE sends a join event. The group ID is inside that event, in source.groupId. I copied it once and used it in the daily scenario.

The daily scenario

The daily scenario reads the sheet, builds one combined message, and pushes it once:

The daily scenario. One push a day, however many rows are due.

Google Sheets — reads the rows
Set variable — one nested if() returns a line only if a step is due today and not done
Filter — passes only rows where that line exists
Text aggregator — joins the lines into one message
HTTP – Make a request — calls the Messaging API push endpoint with the group ID

The message looked roughly like this (dummy data):

Due today:
- Test article A: first draft
- Test article B: publish

What it costs

LINE was the tight part. I ran this on the free LINE Official Account plan, which allows up to 200 messages a month in Japan. You cannot buy extra messages on that plan.

The way LINE counts messages matters here. A push to a group counts once for each person in the group.

For example, one alert to a five-person group uses five messages, and a month of daily alerts would use about 150. Reply messages do not count, but an alert is a push, so it always counts.

Make costs were small. The scenario ran inside my Core plan, at 10,000 credits a month for $10.59 (about ¥1,700). That plan covers all my other scenarios too.

What broke and how I fixed it

Three things went wrong, and each had a simple fix.

Too many messages

At first, the scenario sent one message per overdue row. The group got a burst of separate alerts, and each one ate into the 200-message limit.

The fix was to aggregate before sending. Set variable builds the line, Filter drops empty rows, and the aggregator joins them.

Then the push runs once a day. That one change kept the scenario inside the free plan.

Dates typed as text

Some due dates were typed by hand as text, like 6/25. Make could not compare those with today's date.

I added data validation to the three date columns in Google Sheets, set to "date". After that, nobody could type a text date into those cells.

The wrong "today"

Make runs on its own server time. Without a time zone, "today" could be a different day from Japan's today.

I set the time zone explicitly when formatting dates, like formatDate(now; "YYYY-MM-DD"; "Asia/Tokyo"). After that, "today" matched the team's calendar.

What I'd do differently

I would plan around the message limit from the first day. On LINE's free plan, the number of people in the group matters as much as how often you send.

Aggregate first. One push with everything in it is cheaper than many small ones. Multiple message bubbles in one request do not raise the count either.
Count the group. Multiply the group size by the sends per month before choosing the plan.
Lock the date columns. Data validation stops text dates before they reach Make.
Set the time zone everywhere. Any date logic for a team in Japan should say Asia/Tokyo.

If you want to build something like this yourself, you can sign up for Make with my link. It gives you the Core plan free for the first month, and I earn a commission if you stay on a paid plan.

The Make Data store mistake I made twice: blank fields that wipe your records

Hiro — Tue, 10 Nov 2026 01:02:54 +0000

Disclosure: this post contains an affiliate link to Make. If you sign up through it, I may earn a commission at no extra cost to you.

I made the same Make mistake twice. Both times, a Data store module wrote blank values into fields I never meant to touch.

The first time, it quietly erased my paid users' subscription data. The second time, I caught it one click before it erased everything.

This post covers what the system does, what broke, how I fixed it, and the rule I follow now.

What it does

It is a subscription-based AI chat service I run on LINE in Japan. Paid members also get an extra request they can use a few times a month. Make handles everything between LINE, the AI model, the payments and the user records.

The user records live in a Make Data store. One record per user holds the subscription status, the plan, the Stripe customer ID, the chat history, and a counter for those extra requests.

The stack and the flow

The stack is Make, LINE, Stripe and an AI model API. The main scenario has 31 modules, and many of them are LINE replies and Router branches.

The main flow looks like this:

The main scenario, simplified. The highlighted step is where Bug 1 lived.

LINE – Watch messages — receives a message
Data store – Get a record — loads the user's record
Router — splits by status (free, trial, paid) and by what the user tapped
HTTP – Make a request — calls the AI model to write the reply
LINE – Send a reply message — answers the user
Data store – Add/replace a record — saves the updated chat history

A separate scenario receives Stripe webhooks and sets each user's status to trial, paid or canceled. The "My page" menu checks whether a Stripe customer ID exists before it opens the billing portal.

A record looks roughly like this (dummy data):

{
  "key": "user_123",
  "status": "paid",
  "plan": "plan_b",
  "stripe_customer_id": "cus_TEST123",
  "request_used": 1,
  "History": "Hello! This is a test message."
}

What it costs

The whole Make account runs on the Core plan, with 10,000 credits a month. My invoice is $10.59 (about ¥1,700) a month.

On November 7, I had used 1,734 of 10,000 credits, about 17%. The daily average is around 150 credits, so a full month lands near 4,500. That leaves plenty of room on Core.

The AI model's API bill for my account was just under ¥1,000 (about $6) for the last 28 days. Fixing these bugs cost nothing extra.

What broke and how I fixed it

Both bugs came from the same habit: mapping blank values into fields that should have stayed untouched.

Bug 1: paid users kept turning back into free users

The symptom was strange. A user paid through Stripe, and the payment was fine, but the Data store kept showing them as free. "My page" also refused to open for them.

I first suspected a monthly reset scenario, but it was turned off. Then I suspected a scheduled export scenario, but it only reads the Data store and writes to a spreadsheet. That left the scenarios that run on each incoming message.

The real cause was the last module on the paid-chat branch. It was Data store – Add/replace a record with overwrite turned on, and it mapped only two fields: the chat history and the summary. With overwrite on, every field I did not map was saved as empty.

So the data was not being lost once a month. It was lost every time a paid user sent a message.

Status went blank, so the next message fell into the free branch. The customer ID went blank, so "My page" refused them. One module explained every symptom.

Two more modules had the same problem:

The Update a record that adds 1 to the request counter also mapped empty text into status, plan and the customer ID.
The free-trial branch saved its record without carrying over the Stripe fields.

How I found it without tracing wires

I did not follow the connections on the canvas by eye. I used Export Blueprint from the scenario's "…" menu and gave the JSON file to an AI (Claude). It listed every module, every mapping and every Router filter, and pointed straight at the three modules.

Then I had it write a fixed Blueprint and brought it back in with Import Blueprint. Only 3 of the 31 modules changed:

The 3 modules that changed

Before

Paid-chat save: overwrite on, only the chat history and summary mapped
Request counter update: empty text mapped into status, plan and customer ID
Free-trial save: Stripe fields not carried over

After

Paid-chat save: writes back every subscription field from the record it loaded
Request counter update: maps only the counter, plus 1
Free-trial save: carries over the Stripe fields

After the import, I fixed the broken user records in the Data store by hand. The users stayed paid after that.

Bug 2: the monthly reset that would have wiped everyone

Three months later, a new problem showed up. The request counter never went back to zero, so users who used their requests last month were still blocked this month.

The cause was simple. A reset scenario existed, but I had left it turned off. It searches for records where request_used is 1 or more, then runs Update a record to set it to 0.

Before turning it on, I exported its Blueprint to check it. That Update a record mapped empty text into every field: status, plan, customer ID, chat history, and the list of requests each user had made. If I had switched it on, the first run would have wiped every paid user who had used a request.

I changed the mapping so it writes only request_used = 0. Then I backed up the Data store to a spreadsheet, ran it once, and checked that status, plan and history were still there. They were.

No one had made a request yet that month, so running it early did not hurt anyone.

What I'd do differently

The rule is short: map only the fields you mean to change. In my case, a field left empty in Update a record stayed as it was. A field filled with empty text was overwritten with nothing.

Here is what I do now:

Pick the right module. I use Update a record to change one or two fields. I use Add/replace only when I want to save the whole record, and then I map every field.
Audit with the Blueprint. I export it and ask the AI to list every Data store module that writes empty values. That is faster than opening each module.
Check off scenarios too. A scenario that is turned off can still hold a bad mapping. I read the mapping again before I switch it on.
Back up first. Before an import or a first run, I export the current Blueprint and copy the Data store to a spreadsheet. Connections are not saved in the Blueprint, so I check them again after the import.

I lost some paid users' subscription data the first time, and almost lost everyone's the second time. Both were the same mistake. Now the mapping check comes before I turn anything on.

If you want to build something like this yourself, you can sign up for Make with my link. It gives you the Core plan free for the first month, and I earn a commission if you stay on a paid plan.