Memory: what Routario remembers

Think about what it would take for a new employee to start helping you on day one. They’d need to know who your customers are, where your sites are, which supplier ships which product. That context — built up over months — is what lets them act with judgment rather than starting from zero every time.

Memory is Routario’s version of that context. It is the connected picture of the things your business deals with, kept in one place so that automations can act on what you already know.

The card-and-lines picture

The easiest way to think about Memory is a stack of cards, each one representing a single thing your business cares about — a customer, a supplier, a delivery site, a signed contract. Each card carries facts: the name, address, industry, payment terms, whatever you know about that thing.

Cards are also connected by lines: this contact works at that company; this site belongs to that client account. Follow the lines and you can answer questions like “give me everything we know about Acme Ltd” — the company card, the contacts who work there, the documents filed against them, the sites they operate.

This is Memory: cards, facts, and lines between them.

Not a log of actions

Memory holds facts about what things are — names, locations, relationships, attributes. It does not hold a record of everything that happened — that lives in run history and audit trails. The distinction matters: Memory is “what we know about Acme Ltd today,” not “every email we ever sent them.”

Where Memory comes from

You rarely fill Memory in by hand. Routario assembles it from what you already have:

• Your contacts — when you add a contact or a company, the information lands in Memory automatically.
• Tables — records you store in Custom Tables become cards in Memory and are available to automations.
• Documents you drop in — upload a contract, a brief, or a supplier email and Routario reads it, identifies the people and companies it mentions, and adds what it learns to the relevant cards.

The result is that Memory grows as you work, not as a separate data-entry task.

Memory is derived, so it’s always safe to rebuild

Because Memory is assembled from your contacts, tables, and documents, it can always be rebuilt from those sources. Nothing in Memory is its own source of truth — it is a picture drawn from what you already have.

How automations use Memory

When a flow runs, it can reach into Memory to pull facts about the things it is working with.

A few examples of what this looks like in practice:

Personalising an email. A “silent customer” flow finds contacts who haven’t ordered recently. Before sending each email, a Get memory item step pulls what Routario knows about that contact — their name, their usual product category, who their account manager is — and the email step uses those facts to write something that sounds like it was written for them, not mass-mailed.

Routing a new document. A document arrives in your inbox. An Event trigger fires. A step looks up the company mentioned on the document and finds their account owner. The document gets filed and the owner gets a notification — without anyone lifting a finger.

In both cases the automation acts with context it got from Memory, not from a lookup the user had to set up in advance.

Ask Memory a question

Reaching into Memory from a flow is one way to use it. The other — the one people underuse — is to just ask. Open Memory and type a question the way you’d ask a colleague who has been with you for years: “what’s Acme’s payment term?”, “when did I say I’d get back to them?”, “who’s the technical contact there?”

Routario finds the answer in your own documents and shows it to you with the exact sentence it came from. Two things make this more useful than a search box:

It understands what you mean, not the exact words you typed. Ask “when did I suggest meeting them?” and Routario finds the line “let’s do the 14th” buried in an old email — even though none of those words match. You can ask in English about a note written in another language. You phrase the question however feels natural; Routario does the matching.

It only answers from what is actually there. Every answer is backed by a real quote from a real document. If Routario does not have the answer, it says so and points you at the closest thing it does know — it will never invent one. An answer it cannot trace back to a source is an answer it will not give.

Two shapes of answer

Ask about a thing — “tell me about Acme” — and you get a tidy summary of the card: its facts, its documents, who to contact. Ask about a single fact — “what’s their delivery deadline?” — and you get just that value, with the source sentence highlighted. Same box, two shapes of answer.

Where it shines: the stuff you never filed. You forwarded a supplier’s email weeks ago and moved on — you never made a card for it, never typed the details into a form. Today you ask “how long did that supplier want before starting?” Routario surfaces the exact line — “I’d like another two to three weeks” — and shows you which email it came from. That fact was never a field you filled in; it was sitting in the prose of a note you had forgotten, and Ask reached it anyway.

This is the difference between Memory as a filing cabinet and Memory as something you can actually interrogate.

Always-available facts

Some Memory values are available in every single run without any lookup step at all. These come in as template variables you can drop into any field:

• {{ workspace.name }} — the name of your workspace (useful in email signatures, report headers)
• {{ user.firstName }}, {{ user.email }} — the person who started the run

These are the simplest form of Memory: facts that Routario always knows, always in scope.

What Memory is not for

A few things that often get confused:

This belongs in Memory	This does not
A customer’s address	A log of every delivery made to them
A company’s payment terms	A history of every invoice sent
Who a contact works for	Every email you exchanged with them
A site’s location	Every visit or inspection record

Run history, audit logs, and activity feeds are separate. Memory is the stable, factual picture; history is the running record of what happened.

Working with contacts

Contacts is the primary surface for browsing and editing the people and companies in Memory. Changes you make there — adding a phone number, updating a company name, linking a contact to an account — flow back into Memory immediately and are available to every automation from that point on.

Where to go next

• Template variables — the full list of {{ workspace.* }}, {{ user.* }}, and other values always in scope during a run.
• Working with contacts — browse, edit, and link the people and companies in Memory.
• Get memory item — the step that reads a note or document from Memory and returns the facts and contacts it mentions.