Skip to content

Save and reuse a template

An import has two halves. The recipe — which modules, how rows find records, which column feeds which field, what Tech means — is the same every month. The data is different every time.

A template is the recipe. Saving one is the difference between twenty minutes and two.

  • The modules this import feeds, and the order records are created in.
  • A recipe for each file, with the worksheet name and place the file had and the columns it held, so next month’s files each find theirs: by worksheet name first, then in the order you load them.
  • How each file was reshaped on Source — title and totals rows taken out, a column renamed, blanks filled down — so next month’s file is reshaped the same way, free (below).
  • Per module: whether rows may already exist, the field an existing record is recognised by and where its value comes from, and what happens on a match.
  • Every field mapping: columns, static values, formulas, search rules.
  • Value maps for picklists and lookups.
  • Filters: the row filter, module gates, update guards.
  • The run policy: dry run, what to do on an error, what to do when several match.
  • The connection it was saved from, when it names one. A template may name none — one pushed from a configuration repository never does — and then the connection is chosen when it is used.

Your rows. A template holds no rows: it is instructions — the column names its file had and the values its value maps translate, never the rows themselves — and the data arrives fresh each time. The file you import is kept with that import — until your plan’s history window has passed since it was last changed or run, or it is deleted — and what each run did record by record is kept with the run’s history; neither is ever part of a template.

That is worth knowing because it means a template is safe to share with the whole organisation in a way a saved spreadsheet would not be.

From a finished — or half-finished — import, open the template chip in the import bar, beside the import’s name. It reads No template until the import has one; choose Save as a template. When a run finishes, the Run step asks the same under After this: Keep this setup for next time?

The template takes the import’s name, so give the import a name that says what the file is, not what you did: Monthly accounts from Finance beats Import 3. You can rename the template later on its page under Templates.

Anyone who may change the import can save it. The template is private to you, and the import now points at it; sharing it with the organisation is a separate step — see Share with your organisation.

Saving mid-way is fine and often sensible. A template with the mappings done and the value maps still to come is a useful thing to hand to somebody else.

Nothing flows between an import and its template unless you ask. On an import that has a template, the chip names it and the version this import copied, says newer version when the template has moved on since, and offers Update the template with these changes, Take the latest version (when there is a newer one), Save as a new template and Detach from the template.

Press Start an import on Imports and choose the template under Start from — each template there says when a run last started from it — or press Start an import on the template’s own page. Its modules and recipe are copied into the import, and changing the import does not change the template. The import uses the connection the template names while that connection can still write; otherwise it takes the one Sloose would pre-select for any new import, or none, and you choose on Target. It opens on Target, which shows the template checked against its connection as it is today: whether the connection can still write, whether its modules are still there, and anything that changed under the template since — a mapped field the import can no longer write, a key on a field that has gone, a lookup that would find nothing. It says a module whose fields it has not read yet, rather than passing it, and while it cannot finish — the connections still being read, a module not read — its verdict is Not checked yet. The Modules stage says from the template while it still holds the modules of the version this import copied.

A file the template reshaped is reshaped again as it arrives, before anything else and with no AI credits: Reshaped as the template does, with Undo to load it as read instead. A row the reshape took out by its place — a title, a totals row — is found again by the end it was nearer and taken only if it still looks the same, so next quarter’s longer file loses its totals row and none of its data. When the file does not fit — that row is not where it was, or a column the reshape names is not there — none of the reshape is done: the file loads as read, says why, and Ask AI on Source can reshape it again.

Load this month’s file on Source, and the check reads it too: how many of the template’s mappings found their column by name, and how many by another name the field answers to; which have no column in this file; the columns it holds that the template does not read; and values its value maps have not seen. A template records the columns its file had when it was saved, so a column this month’s file has and that file didn’t is New in this file. Each Map columns part the template otherwise covers is to review until you open it, in case the column belongs there. A column the template’s file had and its mappings leave out is said as not read by the template, and never counted. A template saved before templates recorded their columns can’t tell the two apart, so every column it doesn’t read is said that way. A mapping whose column was found only by another name still reads the old one, so the check puts the column the file has on its part as a guess, free: the part is to review until you take the guess on Map columns or turn it down, and Validate stops the run while the mapping still reads the old column. A guess you turn down isn’t found again — the column is missing, as you said. A column the file lacks beside it still needs you, and Fill the gaps asks about it. A mapping from a column needs that exact header, as the import reads it: Account_No is not Account No, though a formula reading row.Account_No finds it. A formula that picks its column some way no name says — row[helpers.column], the whole row handed to a helper — is never checked: it is left for you to look at, and beside it no column is called unread. Source says the verdict — Fits, Fits, with small changes, or Doesn’t fit when so little is found it is probably the wrong file — with the way back to the whole check. A template is never Fits while the check says something has gone from under it.

When the file doesn’t fit, the check offers three ways out in place of Fill the gaps:

  • Choose another template lists the other templates you can use, best fit for the file on screen first (how many of each one’s mappings find their column here by name), then the most recently used. Taking one replaces this import’s recipe with its own; each file takes one of its recipes as a file arriving would.
  • Start without a template drops the template and its recipe and keeps your files and their cleaning. You choose the modules again, as for an import started from scratch.
  • Use this one anyway carries on with the template: the check then offers what it offers any file.

The ways out change the import, so they are offered to whoever may change it. Anyone else is told what doesn’t fit, and offered nothing in their place.

With several files, each is judged on its own, and the ways out are for the file on screen. When another file is the one that doesn’t fit, the check names it and offers Open to put it on screen, where its ways out are. Fill the gaps waits until no file is the wrong one, or until you use the template anyway.

The check shows what that makes of Map fields: each part the template covers, and the check verified against this file and this connection, is ✓ From the template without being opened; each part it leaves open says what is left, and a part it could not check says what any part says. With no file yet, every part waits on one. The check reads the template as this import copied it: a part you or a colleague have changed since is yours, not the template’s, and says what any part says. If that version can’t be read, the check says so and claims nothing — with Try again when Sloose couldn’t reach it just now, and plainly when it isn’t there to read. Fill the gaps drafts only those parts — the template’s own are neither checked again nor asked about, so nothing lands on them — and they land as guesses for you to review. A file added while it runs brings only what the check leaves open in it, the values it brings to translate included; a file the check hasn’t read yet is waited for. Stopped when the credits run short and carried on — after a reload too — it is still Fill the gaps, and AI activity heads it so. I’ll fill them myself goes to the first of them.

The template’s decisions stay as they are: the check changes none of them — what it finds by another name waits as a guess — and nothing the AI suggests replaces one.

Sloose does not take a template’s word that the CRM is as it was: every import started from one is checked against the connection as it is today, as above.

What that means in practice:

  • A field that has been removed is flagged, not silently dropped. The mapping is still there and still explains itself. See Discovery.
  • A field that changed type shows up at validation rather than at the row.
  • New fields are simply unmapped, as they would be in a new import.

The template is not invalidated by any of this. It tells you what needs attention and leaves the rest working.

A template saved by an older build of Sloose is brought forward to the current shape when it is read. You do not have to do anything, and nothing is lost.

The response says which migration steps were applied, so a client can tell you a template was written by an older build and will be rewritten in its current shape the next time its recipe is saved.

The one thing that is refused is a template from a newer build than the server running it — which can only happen in an unusual deployment situation, and is refused rather than guessed at.

Saves can be made conditional. A client that sends the updatedAt it last read gets a 409 if somebody else has saved in the meantime — and gets their version back with it, so it can show you the difference rather than quietly overwriting a colleague’s afternoon.

Without that, last writer wins.

From an import, Update the template with these changes never writes over a colleague: it is refused while the template has moved on since the import copied it. Take the latest version first, or save the import as a new template.

A private template is its creator’s: only they see it, and only they (as a builder or above) or an administrator can change it. A shared one is the organisation’s: any builder or administrator can update, rename, share or delete it. An operator can save an import as a new private template, but renaming, sharing, updating and deleting a template are a builder’s. See Share with your organisation.

Starting an import from a template is open to everybody who can see it: the import is a copy, and changing it changes nothing in the template.

Most are made here. Some arrive from a configuration repository, pushed by the SDK — those belong to the organisation rather than to a person, and re-pushing updates the same template instead of piling up copies. See Configuration as code.

A builder can also bring one in as a file: Import a template file… on Templates takes a file saved with Export as a file on a template’s page, or a repository’s templates/<name>.json, and the template it makes is private to you.

An agent can also read and write templates over MCP, under the same rules about who may see, share and change one — see Connect an agent.

Report a problem with this page