Autofill
In the portal: Settings, then Atoms. You type a token straight into the words, in the same box as the rest of the copy.
What it is
A token is a marker in your copy that gets replaced with something the participant told you. You write this:
You said you wanted to {{ values.GOAL }} this week.
They read this:
You said you wanted to walk to the shops instead of driving this week.
A token has two parts: where the answer comes from, then which answer. values is
the where, GOAL is the atom's code, and the full stop joins them. A token carrying
only a code, like {{ GOAL }}, finds nothing and renders as nothing. Spaces inside the
braces make no difference, so {{GOAL}} and {{ GOAL }} behave the same.
Why it is worth the effort
The words on the screen become their words. A participant reading a plan they wrote is reading something nobody else could have written, which is a different experience from reading good generic advice.
It also makes if-then plans possible. An if-then plan only works if the participant meets their own trigger and their own response again later, at the moment it matters. You ask for both once, and the token brings them back.
Where the words can come from
There are three ranges and they answer different questions.
| Range | You write | It reaches |
|---|---|---|
| What they said earlier in this form | {{ values.GOAL }} | An answer from an earlier page of the same sequence, updating as they move through the pages |
| What they said on another day | {{ latestAtomResponse.<atom id> }} | Their most recent answer to that atom, whenever it was given |
| What you already know about them | {{ extras.coach_name }} | A value stored against the participant, named by the extra's id |
Only the first range names the atom by its readable code. The other two name it by the atom's id, which is the same value the condition picker writes, so quoting an answer from a previous day means copying that id rather than typing a code. Start inside one sequence wherever you can.
Extras are values already stored against a participant. A journey writes them as somebody moves through it, and you can read them back anywhere afterwards. See Actions for how they get set. Tags are different: a tag is a membership marker with no text behind it, so a tag cannot be quoted into a sentence.
Where a token works
You can put a token in five places. The last two do the most work.
| Where | What it does |
|---|---|
| An atom's label | The question itself carries their words |
| A content atom's body or markdown | The reading material is about them |
| An image's alt text | Accessible text stays accurate |
| An input's default | The box arrives already filled in, and they can edit it |
| An option's label | A choice list is made of their own answers |
A choice list made of their own answers is the one people do not expect. Ask for four
solutions across four pages, then put {{ values.SOL_1 }} through {{ values.SOL_4 }}
in the options of a single-select, and the participant picks between the four things they
typed rather than between "Solution 1" and "Solution 4". Without it they have to hold the
mapping in their head, which is where the flow loses people.
An option label fails differently from every other token site. Everywhere else a
missing value renders as nothing and the sentence closes over the gap. In an option label
an empty result falls back to the label as authored, because an empty row in a list of
four cannot be picked, while a dull label can. So write the option so its authored form
still works: 1. {{ values.SOL_1 }} reads as a bare "1." when that answer is missing,
where Solution 1: {{ values.SOL_1 }} stays pickable.
Only a string default interpolates. A numeric or boolean default is left exactly as
authored, so a token in a number field's default does nothing.
A button's own text is not one of the five. A button atom carries its words in a different field from everything above, and a token there is never resolved, so it reaches the participant with the braces still in it. Put the token in the card above the button instead.
The default fill is the one that saves the participant work. Instead of asking somebody to type their coping plan again in week three, hand it back already written and let them change the parts that no longer fit. It is a smaller ask and it produces a better answer.
What comes back when you quote a choice
A choice atom stores a short value and shows the participant a label. {{ values.SLEEP }}
hands you the label they read, not the value underneath it.
| The atom | {{ values.CODE }} gives you |
|---|---|
| Single select | The label on the option they picked |
| Multi select | Every label they picked, separated by commas |
| Yes or no | The label you wrote for that answer, or Yes or No if you wrote none |
| Everything else | Exactly what was stored, unchanged |
Copy written before 8 September 2026 needs no editing. A single select handed back the
stored value then and hands back the label now, so a card that read SOLUTION_3 reads
Solution 3.
If you delete an option somebody has already picked, their token falls back to the
stored value. They see SOLUTION_3 rather than a blank space.
When the label is not what you want
{{ values.CODE.value }} gives you what was stored. It works on every atom type, not
only the choices. Reach for it where your copy needs the value itself.
{{ values.CODE.answer }} follows a choice to another answer. Say you ask for four
solutions on four pages, coded SOL_1 to SOL_4, then offer a single select coded
CHOICE whose four options carry those four codes as their values. A card after the
choice can then quote what they typed rather than which slot they picked:
Your plan: {{ values.CHOICE.answer }} reads "Your plan: go back to the walking group",
where {{ values.CHOICE }} would have read "Your plan: Solution 1".
Write the sentence so it reads properly whatever they typed, because nothing capitalises or tidies what comes back. For the same reason, do not start a sentence with a token.
This is a different job from putting their words in the options. A token in an
option's label, as above, is for the screen where the choice is being made. .answer is
for a card afterwards that has to name what they chose.
Two things it will not do. It follows a single select only, because several picked values could name several atoms and there is no way to choose between them. And the atom it points at has to have been answered earlier in the same sequence: an answer given on another day is not reachable this way, and the token renders empty.
None of this reaches your conditions. A rule still compares the stored value, so a journey built on a condition behaves exactly as it did.
Personalised copy stays inside the app
Tokens resolve in atoms, which the participant opens on their device.
The four messaging actions send your text exactly as you typed it. notify,
sendEmail, sendSms and sendChatMessage are verbatim, so a token in any of them
reaches the participant as literal braces. Write those as plain sentences and put the
personal detail in the card the message points at. Nothing a participant has told you
travels out through an email, a push or a text message.
Three worked examples
1. Quote them back, then ask the next thing
The simplest pattern and the one that carries the most weight. Open the card with what they said, then ask.
**You said that {{ values.STRESS_TRIGGER }} is what sets this off.**
What is one thing you could do the next time that happens?
Stack two when the next question depends on both:
**You said that {{ values.STRESS_TRIGGER }} sets this off, and that
{{ values.WHAT_HELPED }} has helped you before.**
Let's turn that into a plan you can use on the day.
This is worth doing more than once in a sitting. An answer given on the first page can carry into every page that follows: when they rank a solution, when they weigh it up, and when they plan around it.
2. Build an if-then plan, then hand it back
Two questions asked once, then their own words returned to them as a plan.
| Atom | Code | Type | Label |
|---|---|---|---|
| The trigger | IF_TRIGGER | single_select | When are you most likely to skip your walk? Morning, lunchtime, after work, evening |
| The response | THEN_ACTION | text | What will you do instead, in that moment? |
Make the trigger a choice rather than free text. A typed answer reads more naturally in the card, but a choice is what lets a later card be scheduled against it, and the timing is where most of the value sits.
Then close the same sequence on a content atom carrying nothing but their plan:
**If {{ values.IF_TRIGGER }}, then {{ values.THEN_ACTION }}.**
That's your plan. Nothing to fill in.
To bring the same plan back on a later day, the token names the atom by its id rather than its code, and the card is scheduled for the time of day they chose. A card that said "remember to use your coping plan" would do nothing.
3. Hand back a plan for editing rather than re-asking
Use the default fill so the box arrives full.
| Atom | Code | Type | Default |
|---|---|---|---|
| Review the plan | THEN_ACTION_V2 | text | {{ values.THEN_ACTION }} |
Pair it with a label that says what you want:
Here is the plan you wrote earlier. Change anything that no longer fits.
People write very little into an empty box. Given their own sentence to work on, they usually add to it.
Four things to know before you write
A token with no answer behind it renders as nothing. If they skipped the question, the token disappears and the rest of the sentence stays. So write the sentence to survive that: put the token in its own sentence rather than mid-clause, or put a condition on the card so it only appears once the answer exists.
Codes are fixed once created, which is exactly what makes them safe to write into copy. They are capitals, numbers and underscores.
Read the code back before you publish. A token is typed straight into the copy, so check it against the atom it points at. A code that does not match renders as nothing, and the rest of the sentence still reads normally.
Then look at it on a phone. Set yourself up as a participant in the same tenancy, put yourself on the journey, and open the card. It is the only way to see what a participant sees: a token that resolves reads as a sentence, and one that does not leaves a gap you can spot straight away.
Next
- Writing copy for the rule that decides whether a screen earns its place at all
- Atom types for the codes and the fields each atom carries
- Actions for how a journey stores the extras you quote
- Conditions for showing a card only once the answer it quotes exists