Liquid is where Bento goes from "email sending tool" to "smart, dynamic, personalized automation engine."
We've been building toward this.
In the Events & Flows Overview lesson, I mentioned magic splits.
In the Managing Subscriber Data lesson, I teased "fancier approaches using comma-separated field values and Liquid parsing."
This lesson covers what Liquid is, how to get help writing it, and the patterns I use most.
The Bento Liquid Template Guide has the full reference for every tag, filter, and helper available.
I'll link to it throughout so you can go deeper on anything.
What Is Liquid?
Liquid is a templating language originally created by Shopify.
It's used by many email platforms (including Bento) to insert dynamic content, run conditional logic, and transform data inside emails and automations.
If you've ever written {{ visitor.first_name }} in a Bento email, you've already used Liquid.
The syntax has two core pieces:
Output tags - double curly braces {{ }} - insert values:
Hey {{ visitor.first_name | default: "there" }},
Logic tags - curly-brace-percent {% %} - run logic (conditionals, loops, variable assignments):
{% if visitor.tags contains 'customer' %} Thanks for being a customer! {% endif %}
That's the foundation.
Everything else builds on these two patterns.
Where To Get Help Writing Liquid
Liquid can get complex fast, especially when you're doing date math or nested conditionals.
Here are the resources I reach for:
Bento's Liquid Template Guide
The Liquid Template Guide is your primary reference.
It covers every tag, filter, and helper available in Bento, including Bento-specific ones like environment variables, ecommerce cart rendering, and Stripe/Shopify coupon generation.
Bento's Liquid Tester
Bento has a built-in Liquid tester where you can paste an expression and see the output before using it in a live email or flow.
To find it, hit Cmd+K (or Ctrl+K on Windows) inside Bento and search for "Liquid tester."
Very useful for debugging before you deploy.
LeadTables Liquid Assistant (My GPT)
I built a Liquid Assistant GPT that I originally made for a different project, but I use it for Bento Liquid all the time.
Choose the "Small Liquid Qs" mode and describe what you're trying to do.
It handles most Bento Liquid patterns well.
Tanuki
Tanuki can help with basic Liquid questions, but per Jesse, it's not great at complex Liquid yet.
For simple personalization (defaults, conditionals), it's fine.
For date math or nested logic, I'd reach for the GPT or write it manually.
One note though is that I already sent Jesse all the training docs etc. from that liquid GPT, so Tanuki might be a better first-destination with the GPT as the fallback if you're struggling to get what you need.
Quick Liquid Primer
You don't need to learn all of Liquid to get real value from it.
Here are the patterns that cover most of what I use day-to-day.
Personalization With Defaults
Always use the default filter when referencing fields that might be empty:
Hey {{ visitor.first_name | default: "there" }},
If first_name is blank, the subscriber sees "Hey there," instead of "Hey ,"
Conditionals
Show or hide content based on subscriber data:
{% if visitor.plan_type == 'enterprise' %} Your dedicated account manager is available at... {% elsif visitor.plan_type == 'pro' %} Priority support is available for your plan. {% else %} Upgrade to Enterprise for dedicated support. {% endif %}
Or, if you want to simply hide that line for everyone else:
{% if visitor.plan_type == 'enterprise' %} Your dedicated account manager is available at... {% endif %}
Event Data In Flow Emails
When a flow email is triggered by an event, you can reference the event's details:
Thanks for purchasing {{ event.details.product_name }}!
We covered event details vs. fields in the Events & Flows Overview lesson.
Environment Variables
Bento lets you store site-level variables that you can reference in any email or flow:
{{ ENV.company_address }} {{ ENV.current_promo_code }}
ENVs are great for values you'd otherwise hardcode into multiple emails: your mailing address, the current promo offer, spots remaining in a launch, etc.
Change the ENV once, and every email referencing it updates automatically.
We'll see ENVs used extensively in the Real Life Use Case Examples section.
Filters
Filters transform values. Chain them with the pipe | character:
{{ visitor.first_name | capitalize }} {{ visitor.order_count | plus: 1 }} {{ visitor.bio | truncate: 100 }}
The Liquid Template Guide has the full list of available filters.
Magic Splits
In the Events & Flows Overview lesson, we introduced two types of flow splits: standard splits and magic splits.
Here's the practical breakdown.
Standard splits use Bento's point-and-click UI: pick a tag, field, or segment condition, and the flow branches.
Magic splits use a Liquid expression that evaluates to true or false.
Jesse's take when I asked him if it's okay to route you to the magic split preferentially:
"Old split is dead to me. VIVA LA MAGIC SPLIT." 😂
Why magic splits are preferred:
- Faster execution. Standard splits can add a processing delay of ~5 min per split. Magic splits process almost instantly. Nifty for something like a welcome email that you want going out immediately.
- More flexible. You can write any condition Liquid supports: string comparisons, numeric thresholds, checking multiple fields at once.
- Tanuki uses them. When you ask Tanuki to build a flow, it scaffolds magic splits by default.
A magic split expression is any Liquid that outputs true or false:
{{ visitor.plan_type == 'enterprise' }}
{{ visitor.order_count > 5 }}
{{ visitor.tags contains 'Flag - Customer - ProductA' }}
You can combine conditions:
{{ visitor.plan_type == 'free' and visitor.signup_date < '2025-01-01' }}
If the expression evaluates to true, the subscriber takes the "true" path. Otherwise, the "false" path.
That's it. Same Liquid you'd write in an email conditional, but used to route people through your flows.
Advanced Liquid Examples
Here are some advanced liquid patterns I use regularly:
Example - Logging To Comma-Separated Custom Fields
This is a pattern I use when I want to build up a running log on a subscriber's profile.
The use case: you want a custom field that accumulates values over time, like a list of newsletter slugs they've received, or products they've interacted with.
The challenge: if the field is empty, you don't want a leading comma.
If it already has values, you need to append with a comma separator.
Here's the pattern:
{% if visitor.newsletters_received == blank %} {{ event.details.newsletter_slug }} {% else %} {{ visitor.newsletters_received | append: ',' | append: event.details.newsletter_slug }} {% endif %}
You'd put this in the value of a "Set field" action in your flow.
If newsletters_received is empty, it sets the field to just the slug (e.g., welcome).
If it already has values like welcome,week-1, it appends to get welcome,week-1,week-2.
Later, you can split this field in Liquid to check whether a subscriber has received a specific item:
{% assign received = visitor.newsletters_received | split: ',' %} {% if received contains 'week-3' %} You've already received this one. {% endif %}
This pattern works well, but it does add complexity to your automations because you need Liquid to parse the comma-separated data downstream.
For simpler cases, separate fields or tags might be cleaner (as we discussed in the Managing Subscriber Data lesson).
I use this pattern for my evergreen newsletter system. That worked example is still being prepared, so start with How the real-life examples work for the examples that are available now.
Example: Wait Until Next Business Day
This is a real Liquid snippet I wrote for scheduling delay nodes in flows.
The problem: you want to send an email on the next valid business day at a specific time, but you also need to enforce a minimum wait period.
If someone opts in Thursday at 9am and you set a 1-day minimum wait with Monday-Friday sends at 2pm UTC, they get their email Friday at 2pm. Straightforward.
But if someone opts in Thursday at 11pm, Friday at 2pm is only ~15 hours later - not a full day.
So the snippet skips to Monday at 2pm instead.
The snippet has three configurable values at the top:
{% assign minimumDaysToWait = 1 %} {% assign sendableDaysOfWeek = '1,2,3,4,5' %} {% assign sendHourUtc = 14 %}
minimumDaysToWait- how many full 24-hour periods must passsendableDaysOfWeek- ISO weekday numbers (1=Mon through 7=Sun)sendHourUtc- the fixed UTC hour to send at
One important implementation detail: all date comparisons use Unix timestamps (%s format) instead of date strings.
Liquid can behave unexpectedly when comparing date-looking strings; Unix timestamps guarantee numeric comparisons.
The full annotated version is below.
It's long because every step is commented; the actual logic is only about 20 lines.
{% assign minimumDaysToWait = 1 %} {% assign sendableDaysOfWeek = '1,2,3,4,5' %} {% assign sendHourUtc = 14 %} {% comment %} This formula finds the next valid send datetime according to: 1. A minimum waiting period (N days after opt-in) 2. A set of allowed send weekdays 3. A fixed send time (e.g. 14:00 UTC) {% endcomment %} {% assign nowTs = 'now' | date: '%s' | plus: 0 %} {% assign minimumDelaySeconds = minimumDaysToWait | times: 86400 %} {% assign earliestAllowedTs = nowTs | plus: minimumDelaySeconds %} {% assign earliestDate = earliestAllowedTs | date: '%Y-%m-%d' %} {% assign candidateDateTime = earliestDate | append: ' ' | append: sendHourUtc | append: ':00:00 +0000' %} {% assign candidateTs = candidateDateTime | date: '%s' | plus: 0 %} {% comment %} If the configured send time on the earliest allowed date has already passed (e.g. opt-in at 11pm, send time is 2pm next day), start searching from the following day instead. {% endcomment %} {% if candidateTs < earliestAllowedTs %} {% assign searchStartTs = earliestAllowedTs | plus: 86400 %} {% else %} {% assign searchStartTs = earliestAllowedTs %} {% endif %} {% assign finalTs = 0 %} {% comment %} Search up to 30 days for the first valid weekday match. {% endcomment %} {% for i in (0..30) %} {% assign dayOffsetSeconds = i | times: 86400 %} {% assign candidateBaseTs = searchStartTs | plus: dayOffsetSeconds %} {% assign candidateDate = candidateBaseTs | date: '%Y-%m-%d' %} {% assign candidateDayOfWeek = candidateBaseTs | date: '%u' | plus: 0 %} {% assign candidateDayString = candidateDayOfWeek | append: '' %} {% assign candidateDateTime = candidateDate | append: ' ' | append: sendHourUtc | append: ':00:00 +0000' %} {% assign candidateTs = candidateDateTime | date: '%s' | plus: 0 %} {% if finalTs == 0 and candidateTs >= earliestAllowedTs and sendableDaysOfWeek contains candidateDayString %} {% assign finalTs = candidateTs %} {% endif %} {% endfor %} {{ finalTs | date: "%Y-%m-%d %H:%M:%S %z" }}
Keep the annotated version while you learn and maintain the logic. Test it with realistic dates before using it in an active flow. If whitespace matters in the final output, make a minified copy only after the readable version works.
Advanced tooling note
For long Liquid blocks, keep a readable, commented version as your source of truth. Paste clean logic into Bento when the output is simple.
Minification (stripping whitespace and comments) only matters when whitespace-sensitive output could leak into an email body or when a very long expression is hard to manage in the editor. Flow nodes like magic splits usually tolerate normal formatting because the output is just true or false.
If you outgrow copy-paste, any text minifier or a small local script works. Readable Liquid you can maintain beats a brittle pipeline you never touch.
Now that you have Liquid in your toolkit, the Advanced Flow Branching lesson puts magic splits and event dispatching into practice.
After that, Test and ship your flows covers operational patterns, and Imports, Backfills, and Bulk Operations closes out Intermediate Skills before the real-life examples section.
When To Move On
- You understand what Liquid is and the difference between output tags (
{{ }}) and logic tags ({% %}) - You know where to find help: Bento's Liquid Template Guide, the Liquid tester page, the LeadTables GPT
- You understand magic splits and why they're preferred over standard splits
- You've seen the comma-separated field logging pattern and know when it's useful vs. when tags or separate fields are simpler
- You've seen the wait-until-next-business-day snippet and understand what it does at a high level
Video transcript
Welcome back. In this lesson, we're going to talk a bit about Liquid, which is the kind of pseudo-code language that powers Bento's email builder, and like most email service providers' email builders, and also Bento's magic splits and things like that. So basically, any situation where you want to either inject some subscriber data into an email or do some conditionals, so if this then that kind of things in emails, or using magic splits in your flows to transform data, or even events in flows, passing data to other events, all of these things use Liquid. Liquid's a bit scary at first, especially if you're not a developer, but fortunately for you, it's easier than ever to produce good Liquid code thanks to AI.
So, with this lesson, I think I'm not going to walk you through every single thing that I have typed, since reading it on the page is a little bit easier, but I'll point you to the shape of things and make sure that you're set up on the right foot to take advantage of this. So, this section here, where to get help producing your Liquid code, this to me is the most important part of the video aspect of this lesson. First up, the Liquid template guide is really useful. Jesse's published this, and you can copy and paste this page into any LLM that you're talking to, to give it some context about Liquid.
I personally use the Liquid tester all the time, which you can find by just doing the Command+K global search thing and type Liquid tester. You can see it here. What I like about it is that, number one, it gives you this little place where you can type some Liquid and see how it outputs for a specific subscriber. So, this default one that's here, the visitor greeting is a default Bento field.
But if we did first name, this user doesn't have a first name, so it'll say nothing. And then this one here, the first name is in there as Z. So if we do this, it'll say, "Hi, Z." And the reason this page is so useful is that throughout the page itself, it gives you a bunch of go-to snippets that people need to use. And if you scroll further down, I feel like somewhere in here.
Yeah. It shows you all the custom fields you have and how to easily paste them in Liquid. So if you have plan type, you could just click copy and then paste it up here, render Liquid, and now you see they're on the professional plan. So, this page is so nifty because it's almost like this little scratch pad where I'll test some stuff I'm playing with, and then once it looks good here, then I'll move it into my actual flow or email or whatever.
And then a couple of other ways to write it in the first place or learn it. Tanuki can help with basic stuff, first off, so use Tanuki within Bento when you can, because it's simple. If you are a ChatGPT user, I made this Liquid assistant GPT for my own software tool, not Bento, so ignore the column context thing. My software tool is almost like a lead spreadsheet manager kind of thing.
So if you're using it for Bento, I always just go in here and click the small Liquid questions one, and I can just have it write different expressions for me. So I'm like, "I'm trying to do blah, blah, blah. Can you help me write it?" And it'll write nicely commented out code for you to understand. And when I say commented out, that's coder lingo where basically you can write what's called a comment, which will not actually be processed as code.
It's just there as an internal note to self. And so when I say comment, here's an example. So this is the Liquid syntax for comment. They actually have a couple ways to write comments.
This is what's called a multi-line comment. So anything after this, so squiggle percent comment, squiggle percent, and then before the end comment, all of this is not going to actually be run. So this right here is a very complicated one. We'll get to that in a minute.
But in any case, if you go in here, I was just having it produce a little example for you. This one doesn't have comments, this one does. So if you were to copy and paste this into the Liquid tester, and then render it, you see that it's using, "Hey, visitor first name, thanks for joining us." And if we were to grab this second one, it should render exactly the same. Although it might have some empty spaces.
Yeah, so you can see it's still rendered all of the times that you hit enter between the comments. So if we do this, it's going to remove four spaces. See? And that'll come into play in a moment when I talk to you about minifying.
But again, I don't want to get super advanced if you don't want to get super advanced. So the main thing, if you're just doing basic stuff like if they have a first name, do this, if not, do this. If they're in the pro plan, do this, otherwise do this. For that kind of stuff, you don't really need to go much further in this video than this moment.
Just get some help from Tanuki, get some help from ChatGPT, whatever, and leverage the Liquid tester to make sure your stuff will work. My rule of thumb is that if I'm using Liquid for an if else, or for some kind of injection, I want to try to test all the different possible combinations that it could render in to make sure they all work correctly and look good. If you've done that, then you're good to go. If you just write the Liquid without testing it first, that's how you end up with emails where there are just empty spaces where clearly the person was trying to inject a variable and they didn't.
And I think that's most of the Liquid mistakes I see. It's just because people didn't actually test the Liquid that they wrote. So here on this page you're on, I have a few of the basic common examples of Liquid that you will use quite often. So one of these is the concept of a default.
Whenever you see a pipe like this in Liquid, this is a pipe character. It's basically used for separating built-in Liquid functions, as it were. So this here, the concept of default is a Liquid function. So what this function does is if this is blank, it's going to output whatever you put as the default.
But there are a bunch of other Liquid functions. There's one for lowercasing it, there's one for doing a find and replace. There's one for adding [lips smack] a currency conversion or something like that. I've done some interesting stuff with currency before.
Here are some other ones. So capitalize, adding one, truncating something to the first 100 characters. All of these are examples of what I just called functions, but maybe they're actually called filters. My bad.
And then I have a couple of examples of conditionals. You can also in Liquid do else ifs. So in this case you have if else endif, but I'm pretty dang sure you can do an else if. Let me just double-check real quick.
Yeah, you can. So this would be the syntax for it. So it doesn't have the E after else, but otherwise this is how it flows. So that's useful, and you've already played with this direct injection a bit.
One other nifty thing about Bento that I really, really, really love is the ability to set environment variables. So for anything that you want to just globally use for all your emails, or for not necessarily all your emails, but a lot of your emails, but that is perhaps subject to change, and when you do change it, you'd want to change it across the board, an environment variable is so, so, so useful. So within your Bento dashboard, if you go to the settings and then you click environment, you can create a new variable that's like, so let's just say we call this Zach test. "Hey, bruh." So let's say that's our new environment variable.
Which by the way, environment variables can hold HTML, they can hold text, I think they can hold maybe even other environment variables. I've not tried that. [chuckles] But you can do Liquid within them. So, I like to do it for footer address, promo unsubscribe. I've done it before when I have a limited number of seats available for a promo that I'm running, where I'll go in and manually update the count so people can see the seats getting smaller without me having to remember to change that number in a million different emails.
So now if we were to go to the Liquid tester, I'll probably have to refresh it. If I just paste this environment variable, render Liquid, look at that. And then if we wanted to, we could even do the old [lips smack] first name thing, just so you can see. So instead of bruh, what if bruh is just the fallback?
So it would say, "Hey, bruh," if they didn't have a first name set, but if they did, it would show their first name. So once again, I'm going to just copy it from here, paste it. So for this person... Oh, interesting.
So this might be one limitation of the [lips smack] Liquid tester, because I can tell you for sure that in a proper email, this would work. Let me just double-check, though. Yeah. So in a proper email, it does work.
So this one shows, "Hey, bruh," but if we were to preview it as [notification sound] this guy with the Z, you can see that it does indeed say, "Hey, Z." So that's just one note for the Liquid tester itself, but within an actual email, it works fine. So before we get into the advanced stuff, which you can leave for if you just want the simple stuff, a final thing I wanted to talk about is magic splits. So I mentioned before that I really like magic splits over the normal splits because they evaluate much more quickly. So if you do a normal split, it takes about often five minutes in order for it to get processed.
So for something like a welcome email or a thanks for purchasing email or whatever, you don't want somebody to have to wait five minutes. And so if you just made a normal split, this would make them wait five minutes, and you don't want that. So what you can do is do a magic split, and what a magic split does is it evaluates a Liquid expression to choose its path. So I found that you don't actually have to output false if you don't want to.
False is just a fallback, and it says that up here. The main thing that's important is that you have some Liquid that evaluates to true. So in the Liquid assistant thingy, I had it make this little example output for us. So what I wanted is something where if the target date is in the future, it'll output true, otherwise it'll output false.
In a moment, I'll talk about the minification. I'm not sure how this will work in the Liquid tester here with all these spaces, but we'll see. So right now, there's a lot of code here, but I tried to make it set up in a friendly way. So right now, it's outputting false because July 22nd, today is July 22nd, so it's not in the future.
But if I change this to 23rd, it should output true, and it did. Amazing. And so this is a great example of how a pretty complex Liquid expression could be used in a magic split. And so this would essentially be like if we are still in pre-launch.
Let's say that your product launches on August 1st. And if we're still in pre-launch, you would want to go down this true path where you send all these hyped-up emails, like, "Yeah, it's coming soon." And then if we're not still in pre-launch, we wouldn't send those. We'd send something else. That's what this magic split would do.
So you can do all sorts of things, like anything you could ever think about that can render in Liquid, you can do here, and there are some really amazing possibilities as a result of this. So from here, I want you to lean on the text on the page. I'm just going to skim over to let you know what's here and paint the shape. So a few advanced things that I regularly like to do.
One of them is I like to log stuff to comma-separated custom fields sometimes. So in the example section of this course, you'll see me show how my evergreen newsletter/shadow newsletter works. Basically, I have every newsletter I create, I make a little slug for it, like a friendly name with lowercase, no spaces, that kind of stuff. And whenever someone receives one, what I do is I append it to a field that's just this gigantic field of all the newsletters they've gotten.
But the problem is you can't just always add a comma before something, and you can't always add a comma after, because if you always add a comma before, the first one looks bad because there's this leading comma, and if you always add a comma after, the last one looks bad because there's a trailing comma. So I use this little Liquid expression when setting the field. So I'm pretty dang sure, yeah, this is in a set field. So what you could do if you were doing this, let me find it.
So you can go Attributes, Update field, and then newsletters-received, and then paste this big-ass expression. But for doing something like this, this is where it becomes important to think about minifying, as it's called, your code. Because in this case, notice all these spaces that the line breaks are transformed into. What this'll do is it'll literally be setting the field to have these spaces in the field value, which is bad.
You don't want that. So if we were to skip forward to this part, I coded up this little tiny minifier thing, which if you're a non-developer, this, I'm sure, will be a little bit overwhelming, but if you give this page context to AI, it can help you with it. But basically, I made a little minifier that takes long-form Liquid and compresses it. Let me show you an example.
All right, so here's one. This project's a little bit unorganized, but basically within my code tool, I have a runner that runs my minification scripts on anything I paste into this file, and it just renders it out here. So here's the original stuff pasted in here. Notice all these line breaks and extra spaces and stuff like that.
This is the unminified version. It outputs to this. So very minimal spaces, like between tags, no spaces, stuff like that. So it creates something that's very safe to just copy and paste into something like one of these set field ones without worrying about the spaces getting set.
So that's an important thing if you're going to mess with crazy stuff like this where you're setting a custom field to a very complex Liquid expression. Where the spaces don't seem to matter is with the magic split that we looked at a minute ago. The spaces were just fine there. Another one I wanted to show you that is so nifty that I'm using in one of my welcome sequences right now that I super love is this one.
This is a real-world example of where complicated Liquid is really useful for doing something that would be hard to do otherwise. I have this function that essentially waits until the next business day. And so at the top of this function, you can configure it. So in this case, we're saying Monday, Tuesday, Wednesday, Thursday, Friday, one, two, three, four, five are the sendable days a week, and we want to send it at 2:00 PM UTC, which is, I think, 10:00 AM Eastern.
And then we can set the minimum days to wait. So basically, in practice, whenever I am adding a delay within the welcome sequence flow where I'm using this, I am just changing this one value. And what this does is it is essentially just outputting a timestamp of when it should wait until. So you can essentially just plop this into a delay node.
So if we go in here and we add a delay, by default, it's going to wait a certain amount of minutes, but you can change it so that it's Liquid. And so see how this placeholder says visitor.webinarat? So this is showing an example of outputting an actual timestamp here. And so if we wanted to, no, not that.
Where did I put it? Here. We could take that minified one, since it's quite a complex situation, and do this. And what this'll do is delay them until the next business day that is a minimum of X days apart.
As always, it's smart to test this. So this is a really good example of before when I said that I like to test things for users before deploying them. This is one that required a lot of testing first. So let's say, test the date delay.
Let me save this and show you a test real quick. So let's say I do this. Let's set it to three days to wait because today is a Wednesday. So three business days, we're expecting one for Thursday, two for Friday, and then Monday.
So we're expecting that Monday is when it's next eligible. I, for these kinds of things, will usually make sure I have some kind of node after the delay because I feel like, and I could be wrong, but I feel like I had an experience once where if there's a delay without anything after it, Bento doesn't even bother to run it because it can tell there's nothing to do after it anyway, but I could be wrong about that. But anyway, I'm paranoid, so I just [chuckles] typically, in real life, you wouldn't have a delay with nothing after it anyway, so I always just add something after it, but I could be totally wrong. So I've pulled up a subscriber who I want to test this on.
So I'm just going to create an event for that trigger event, and once the flow processes, what we should see is that they will be in here waiting until that date, and it already processed it. Amazing. So July 27th. So today is the 22nd.
Let's find out what Monday is. So 23rd, Thursday. 24th, Friday. 25th, Saturday.
26th, Sunday. 27th, Monday. Oh my God, it worked. So that's an example of a really nifty and complex piece of Liquid doing stuff that would be impossible to do without it.
I can't think of any native way with drag and drop Bento nodes to do this. Maybe you can, but this is what, to me, felt the easiest way to do it. So I think that's the overview. Nice thing for Liquid is that because it's used in Shopify, it was made by Shopify, there's a lot of information about Liquid online.
So I don't always use the LLM, like that ChatGPT assistant or Tanuki or whatever. I often just go to Google and I'm like, "Liquid code language lowercase." And often the Liquid documentation will show you the little filter to do that, and that's quite simple too. So good luck, enjoy, and I'm excited to see, well, I probably won't see, but I'm excited to know that you will probably, hopefully build some cool stuff.