Every run of a Lodol workflow starts fresh. That's a good default: a run can't be thrown off by something the last one left lying around. But some jobs need a memory. Where did I get to last time? Did I already send that alert? How many of these have there been this month?
Now a workflow can keep the answer. New steps get, set, delete and increment a stored value: a named value that lasts from one run to the next. Keep one for the whole workspace or for a single workflow, and give it a default for the very first run, when nothing is stored yet. Here are the four jobs it's for.
Pick up where it left off
Many apps can tell Lodol the moment something new happens, and for those, a trigger is the right start. But some can't, or not for the thing you need, and then the usual answer is a schedule that checks every hour. The catch is that each hourly run has to know which records the last one already handled.
A stored value is that bookmark. The pattern is four steps:
- Read the bookmark. Get the stored value
last_seen: when the newest record handled so far was created. Give it a default, such as the start of today, for the very first run. - Ask for what's new. Search the app for everything created after that.
- Handle each one, oldest first. Add it to your sheet, open a ticket, post it to Slack: whatever the workflow is for.
- Move the bookmark as you go. After each record is done, set
last_seento when that record was created.
Each run picks up exactly where the last one stopped. Moving the bookmark after each record, rather than once at the start, matters on a bad day: if a run fails halfway, its place is saved at the last record it finished, so the next run carries on from there instead of skipping the rest or redoing what's done.
Say it once, not every hour
A workflow checks your Shopify stock every hour and posts in Slack when a best-seller falls below 20. Without a memory, it posts every hour until somebody restocks, and by the third message nobody reads it.
With one, it keeps a stored value called low_stock_alerted. It posts only when the value isn't already true, and sets it to true straight after. When stock is back above 20, it sets the value to false again. One alert per dip, however many hours the dip lasts.
Count without losing any
Runs overlap. Two requests arrive in the same second, and two runs each try to add one to a count. If each reads the count, adds one and writes it back, one of the two updates is lost and the count is wrong for good.
The new increment step doesn't work that way. Every increment is counted, however many runs make one at the same moment. Use it to give each request its own number, like REQ-1043, or to keep a running total of refunds approved this month, with a monthly schedule that resets it on the 1st. A stored value also keeps its type, so a count reads back as a number, ready to compare or add to, rather than as text.
Share it, or keep it to one workflow
Each stored value belongs either to the whole workspace or to one workflow.
- Workspace values are shared, so one workflow can set what others read. Someone posts oncall Priya in your ops channel, a workflow that starts on that Slack command word stores the name, and every alerting workflow reads it to know whom to mention.
- Workflow values belong to one workflow, so two workflows can each keep a bookmark called
last_seenwithout ever touching each other's.
You decide what a workflow can change
Stored values are Values too, kept in Secrets and Values beside the ones your team already set up there, and the same rules apply. A workflow can always read a value. It can change one that a person set up only if you allow workflow edits on that value in Secrets and Values. And a workflow can never write a secret.
That line matters. A workflow should be able to remember where it got to. It shouldn't be able to quietly raise the approval limit it's checked against, or overwrite an API key with whatever a step happened to produce.
What it's not for
A stored value is for the handful of facts a workflow has to carry from one run to the next: a bookmark, a flag, a count, a name. A list of every customer or a log of every order belongs where your team can read and sort it, like a Google Sheet or an Airtable base. And anything sensitive is a secret, not a stored value.
It also doesn't change what makes a Lodol workflow predictable. A stored value is read and written by steps you can see on the canvas, at the points you put them, and every run's record shows what it read and what it saved.
Also new this week
Also joining the catalog this week: Salesforce for leads, accounts, contacts and opportunities; Shopify and WooCommerce for products, stock and orders; Zendesk and ServiceNow for tickets, incidents and change requests; and BambooHR for your employee directory. Xero grew from 3 actions to 20, across invoices, quotes and contacts, and so did WordPress, across posts, pages and comments.
Give your busiest scheduled workflow a bookmark.
Add a step that reads a stored value at the start, and one that saves it as each record is done. The stored values guide has every setting, and you can start free if you don't have a workspace yet.