Shikake Works
Build logs

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

By Hiro · November 7, 2026

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 LINE-based AI chat service I run in Japan, mainly for women, where a carefully crafted AI persona listens to their worries and helps them work through them. Paid members can also ask for a short recorded voice message once or twice a month, depending on the plan. 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 voice requests.

The stack and the flow

The stack is Make, LINE, Stripe and Gemini 2.5 Flash. The main scenario has 31 modules, and many of them are LINE replies and Router branches.

The main flow looks like this:

  1. LINE – Watch messages receives a message.
  2. Data store – Get a record loads the user’s record.
  3. Router splits by status (free, trial, paid) and by what the user tapped.
  4. HTTP – Make a request calls Gemini to write the reply.
  5. LINE – Send a reply message answers the user.
  6. 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",
  "voice_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 Gemini 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 voice 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 paid-chat save now writes back every subscription field from the record it loaded.
  • The voice counter update now maps only the counter, plus 1.
  • The free-trial save now 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 voice 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 voice_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 voice messages each user had received. If I had switched it on, the first run would have wiped every paid user who had used a voice request.

I changed the mapping so it writes only voice_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.