Skip to main content
Populate custom field sets a custom field value on the store that triggered the run, or clears it. It’s how a flow records what it observed, so the rest of Meridian can act on it.

​
Configuring the action

Pick the field to write, then say where the value comes from: a fixed value, or from the trigger. The action always writes to the triggering store: the run already knows which store it’s for. A flow with no store behind it (some test runs) traces the write as skipped.

​
A fixed value

The same value on every run. The value editor matches the field’s type: a checkbox offers true/false, a select offers its options, a date offers a date picker, a number takes a number.
  • Leave the value empty to clear the field on that store.
  • For a checkbox, unchecked writes false, not an empty value. Clearing and setting-to-false are different states, and segments can tell them apart.
  • A value that doesn’t fit the field’s type is refused rather than stored loosely.

​
From the trigger

Write the value this run was fired with, instead of one you decided in advance. The picker offers exactly what a variable condition on the same flow could branch on: the same variables, because the same resolver reads them:
  • the crossing that fired a usage view threshold (usage_view_value, usage_view_threshold, and the window it was measured over),
  • the tracked event behind the run: its event_quantity, or any properties. property your app sent,
  • the store’s own details (its plan, its revenue, when it installed).
This is what turns usage into something the CRM can work with. “When a store’s GMV passes 10,000, write the GMV onto the store” gives you a number on the store card, in segments, and in reports. No export, no second system.
The value takes the same coercion as a typed one: usage_view_value of 10450.5 lands in a number field as the number 10450.5, and a reading the field can’t hold is refused exactly as a typed value would be.
A variable with no value writes nothing. If the run doesn’t carry it (the event didn’t include that property, the store has no value for that detail) the field is left exactly as it was. It is never cleared. An absent reading is not zero and not an empty string, and blanking a field on one would destroy the very history you’re recording. Test runs report this as a skipped step naming the variable, rather than as a write. The builder only lets you pick variables the flow’s trigger actually provides. Point the trigger somewhere else afterwards and the step is flagged, because a variable that trigger never sends could only ever do nothing.

​
Writing is an event

This action goes through the same writer as the dashboard and the values API, which is what fires the Custom field changes trigger. So a populate step can start another flow, deliberately useful and bounded by two guards:
  • an automation never re-runs on the change it caused,
  • automation-to-automation chains stop after three hops.
Writing the value a store already has changes nothing and fires nothing.

​
Why write a field from a flow

Because a custom field is readable everywhere else. Set an onboarding stage from an install flow, or record the GMV that crossed a threshold, and you can segment on it, report on it, show it on the store profile, print it in an email, and read it from your app through the SDK.

​
Deleted fields

If the field is deleted after you wire it in, the step is marked and the flow can’t be activated until you pick another one.
Last modified on August 25, 2026