Save and reuse a project

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 project is the recipe. Saving one is the difference between twenty minutes and two.

What a project holds

• The modules this import feeds, and the order records are created in.
• The match rule per module, 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.

What it deliberately does not hold

Your rows. Source data is never stored on our servers — not in a project, not in run history, not anywhere. A project is instructions; the data arrives fresh each time.

That is worth knowing for two reasons. It is a real privacy property rather than a policy statement. And it means a project is safe to share with the whole org in a way a saved spreadsheet would not be.

Saving

From a finished — or half-finished — import, Save. Give it a name that says what the file is, not what you did: Monthly accounts from Finance beats Import 3.

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

Loading, and pointing it at a new file

Open the project, load this month’s file, and go. The mappings attach to columns by name, so a file with the same headers needs nothing further.

If the headers changed, the mappings pointing at a missing column show as unmapped and you fix those — rather than starting again.

When the CRM has changed since you saved

A project records the registry version it was saved against, so Sloose can tell that the configuration has moved on.

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 project is not invalidated by any of this. It tells you what needs attention and leaves the rest working.

Old projects are migrated, never refused

A project 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 project was written by an older build and will be rewritten in its current shape on the next save.

The one thing that is refused is a project 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.

Two people editing the same project

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.

Who can change it

The creator, and any administrator. Everybody else can load and run it.

That is deliberate: running somebody’s project is safe, and editing it under them is not.

Where projects come from

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

An agent can also read and write projects over MCP, under exactly the same rules — see Connect an agent.