Sloose Start free

Privacy policy · effective 18 October 2026

Your rows stay yours.

Sloose is made by Dinode Pty Ltd, Level 2, 11 York Street, Sydney NSW 2000, Australia. This policy explains what we collect when you use Sloose, what we do with it, and how to get it removed. Questions go to hello@sloose.com or 1800 DINODE (1800 346 633, within Australia); security reports to security@sloose.com.

1. The short version

2. What we collect

Account and organisation data

When you sign in with an emailed link, or the code that comes with it, we hold your email address; a display name is set only if you add one in Your account, or when your account is first made by signing in through Zoho. When you sign in through Zoho we receive your Zoho user ID, email address and display name, and an access token Zoho issues for the sign-in, which we use only during it — to read who you are and which organisation your CRM is, so that a Sloose tab inside that CRM can tell you apart — and delete when the sign-in is done, or within a day if it failed part-way. Each sign-in opens a session, which keeps the IP address and browser it was made from, the organisation it works in and, after a Zoho sign-in, the CRM organisation it proved with your user ID there; a session is deleted when you sign out, or a month after it expires. We use these to create your Sloose account and to keep organisations separate; your role in an organisation is set when you create it (its owner) or when you are invited, is changed only by its administrators on People, and is never read from Zoho. An organisation also keeps the email address of everybody it has invited, with what became of each invitation, and each request somebody has made to join it, with their name and email address.

Connection credentials

When an administrator connects a CRM to an organisation, Zoho issues an OAuth refresh token and tells us which CRM authorised it. We store the token encrypted at rest, and the short-lived access token Zoho issues from it encrypted too, and use them for two things. First, to read your CRM's module and field metadata and count its active users — the list of them is read and only how many is kept, for your plan's CRM-user band — when it is connected and whenever an administrator asks Connections to read it again, and, when it is connected, its time zone if your organisation has none yet. Second, acting as the administrator who connected, to read and write records of that connection's modules when somebody in your organisation asks, in the app or through our API: setting up or running an import, matching a row to a record, picking a record for a lookup field. Any member may do that, whatever their role — a role limits what they may configure, not which of the connection's records they may read or write. Records are read or written with it for no other reason, except by a named Dinode staff member giving support, who can view your organisation as one of its members: read-only, unless they record why and confirm your organisation's name, and every such view is written to our staff log.

Imports

The files you import — the rows as they were read, and the corrections you make to them — so that an import can be picked up again, by you or by anyone else in your organisation. They are stored in Cloudflare's Oceania region until your plan's history window has passed since the import was last changed or run, and for up to 30 days longer after a change of plan so that a downgrade does not delete history the shorter window would have; they are deleted then, or earlier when you delete the import. When your organisation is closed they are kept with the rest of its data until it is erased, within 30 days of closing, so that a closure made by mistake can still be undone through our support.

What each import run did is stored with it: for every record the run wrote or tried to write, whether it was created, updated, refused or went unanswered, the record's ID in your CRM, your CRM's reason when it refused one, and the values the record was matched and linked by; and for a row the run did not write, that it failed or was skipped, and why. A dry run keeps, for each row, whether it would have created or updated a record in each module — none of the values it would have written — beside the rows it would have failed or skipped, and why, which can quote a value. A retry keeps a copy of what the runs before it made of each file it reads as they read it, so that it writes none of that again. These are stored in Cloudflare's Oceania region with the run, for as long as its history is kept — your plan's history window, and up to 30 days longer after a change of plan — and deleted then, or earlier when the import is deleted or your organisation is erased. A run made through the API without an import keeps them for seven days after it ends, and one never closed is closed once nothing has been written under it for a day.

Files you upload

Documents, images and other files you choose for an import, or a folder or a zip of them, are stored by us in Cloudflare's Oceania region, in the same storage as the files you import, under a path made of your organisation's and the file's ids and never its name. Your browser reads the start of each file before it is sent and writes into the import's files sheet the file's name and folder, size, type, modified date, a fingerprint of its content (SHA-256) and, where the format holds them in its own header, facts such as a document's title, author and page count or a photo's dimensions and the date it was taken. That sheet is kept with the import like any other file you import. Our server reads only the first bytes of a stored file, to find its type from its content and to refuse a program. We do not scan files for malware. When you run the import, a file a record names is read from our storage and sent to your connected CRM through our API.

The contents of your files are never sent to our AI provider. The files sheet is imported data like any other and follows your organisation's AI data setting; the column that holds our ids for the files is never sent.

Configuration and run metadata

Field mappings, match rules, value translations, templates, helper libraries you push with the Sloose SDK, and per-run records such as module names, row counts, timings, outcomes and error messages.

Billing

Payments are handled by Stripe. We store your Stripe customer ID, plan, credit balance and invoice references. Card numbers never reach our systems. We also keep the notifications Stripe sends us about your payments, which can include invoice and receipt details such as your name, email address and billing address; these are kept with your organisation and erased with it. One that never resolves to an organisation of ours — Stripe telling us about something we do not recognise — is deleted after 30 days.

AI assistance

When you ask Sloose to propose mappings or value translations, or ask its AI a question, we send what you asked, the column headings, the destination field definitions, a small sample of values from the affected columns — for a question about a formula, also the rows you marked as coming out wrong with what you said each should be, and how many of the file's rows its current result writes in each shape, which is only how many shapes there are under the none setting or where a field or column is excluded from AI — and, for a question about a run, the last run's recorded totals and the modules it wrote to, if there is one, and the run as it would go (each file's name, its row count and the modules it writes), to our AI provider through our AI gateway (Cloudflare AI Gateway). To translate values into a lookup field it also sends the names of up to 400 of the CRM records the field can link to — names your browser has already read, with a second field of the record where two share a name — and only under your organisation's most permissive AI data setting, never for a field an administrator has excluded from AI. Under the masked setting every sample value we send is reduced to its shape, except that, to translate the values of a column mapped to a picklist or a multi-select field, we send that column's distinct values, without how often each appears: nothing else of the file, never a field an administrator has excluded from AI or a column named like one, never a lookup's values, which are the names of records, and never values a formula made, since a formula can read any column. Under every setting, the values of a field an administrator has excluded from AI, and of a column named like one, are never sent in any form, not even as their shape; the examples written for that field are sent in their place, as written. The gateway keeps a log of every request and its response, sample values and record names included, so that we can investigate problems; it holds the most recent 10 million requests and deletes the oldest as new ones arrive. Sample values may contain personal data if your file does; use AI assistance only on data you are comfortable sending.

When an administrator asks Sloose to fill in a module's fields, we send that module's field definitions from your CRM, what your organisation has already written about them, any values they paste for a field, and the values of up to 20 of that module's most recently changed records, each up to its first 200 characters, which we read from your CRM through your organisation's connection for that request, so that the AI can see what the fields hold and say which look personal. All of it follows your organisation's AI data setting, as sample values do: under its strictest setting no record is read, and the values of a field excluded from AI are never read at all. We store none of the records we read, and nothing of the request, and we ask the gateway to keep its metadata alone — the organisation's ID, the feature, a request ID, the model, its size, tokens, cost, status and timing — never what it carried, so the records are kept nowhere; what the administrator takes from the answer — a description, a format, examples, or that a field is excluded from AI — becomes part of that field's settings in your configuration. The examples it proposes are made up: one that is, or holds, a value read from your records, in any field and any spelling, is never offered.

The questions you ask about a proposal that are not kept with an import — conversations through our chat API, and Ask AI or Not quite… on an import's Map fields — its Which rows & existing or Map columns, all but Suggest columns — asked while a change of yours is still being saved, which is kept in your own chat history — are kept, because each is sent to our AI provider with the questions and answers before it. We store the questions, the answers, and the sample values sent with each question under your organisation's AI data setting, in Cloudflare's Oceania region; each question and its answer are deleted once your plan's history window has passed since the question was asked, and up to 30 days later after a change of plan, and all of them are deleted with the rest of your organisation's data when it is erased. A stored conversation is not rewritten when your organisation changes its AI data setting, but if the new setting is stricter, none of what was sent before the change is sent to our AI provider again.

The questions you ask about an import — Ask AI about a file on an import's Source step and on its Map fields' Which rows & existing, Map columns and Translate values, Not quite… on a proposed mapping, rule or value there, the formula editor's Ask AI about the expression it edits, what Draft everything drafts, Explain on a run's error group or on one of Validate's problems, Validate's own Ask AI about all of its problems at once, and Run's own Ask AI about its run, each asked in the app or through the API with the conversation it is kept in — are kept with the import while nothing of it is waiting to be saved, so that anyone in your organisation who can open it can read what was asked, and so that the next question there picks up from them. Asked while a change of yours is still being saved, a question on Which rows & existing or Map columns other than Suggest columns is kept in your own chat history instead, as the paragraph above says, and the others are not stored: their answers stay on your screen. For each question kept with an import we store the question, the answer, what the answer proposed and where (a row filter, a different way of reading the file, a change to the file's shape, or a generated sample, described by its columns and size and not by its rows; a column, a formula or a fixed value for a field, a column to leave out, how an existing record is found, which rows a module takes, when a record a row finds is updated, what one of your file's values becomes, and an expression written into the formula editor), the answer's notes (what it could not do, and what we refused of it), what of the file the answer was made from under your organisation's AI data setting, who asked it, and whether it was asked in the app, with an API token or by an agent. With a file an answer made, and with a guess an answer made on Map fields' Which rows & existing, Map columns or Translate values or one you turned down there, we keep which answer made it. The sample rows sent with a question are not stored with it, but an answer and what it proposed can quote values from your file, and so can its notes under your organisation's all-values setting — under the masked or none setting, no note we keep says a value of your file. Each question and its answer are kept for your plan's history window from when the question was asked, and up to 30 days longer after a change of plan, and are deleted then, or earlier: a question about a file with the file when it is removed from the import (a question about Translate values, about all of Validate's problems or about the run, and what Draft everything proposes for your values, is about no one file, and stays with the import), every question with the import when it is deleted or expires, and with the rest of your organisation's data when it is erased. The questions of a person who is deleted stay with the import, naming nobody. They are sent to our AI provider again, before a new question there, only while your organisation's AI data setting is no stricter than what they were made from.

Support requests

When you choose Contact support, Report a problem or Suggest an idea in Sloose, a form from Userback, the tool we answer support with, opens in the page; unless your diagnostics are on, or were earlier on the same page, as the next paragraph says, nothing of Userback's is loaded until you do. As it opens, Sloose tells Userback who you are — your Sloose user ID, your name and your email address — and Userback keeps that in our account's list of the people who have contacted us, whether or not you go on to send anything. What you send with the form goes to Userback with it: your message; your name and email address as the form shows them, which it fills in from your account and you can change; the organisation you were working in, by its ID and name, and your role in it; the address of the page you were on, which can include the ID of an import; which of Sloose's deployments the page came from, and the version of the code it was running; and your browser, system, and window and screen size. Sloose adds nothing else of yours or your organisation's — no file, row or record of an import. The form offers to take a screenshot of the page or a recording of your screen, and takes neither unless you press for it. A screenshot is of Sloose's page alone: inside a CRM tab, your CRM around it is not in it. It blanks the tables, panels, dialogs and lists that show an import's rows and your CRM's records — a run's question about a row and its report among them — and the box a file is pasted into, the sample values shown beside a column or a rule, what the AI was asked about an import and answered, what it is shown and proposes when it fills in a module's fields, the values typed or pasted to show it a field or to try a helper function, what a helper function gave back when tried, and the values a message about a problem quotes; anything else the page showed is in it, the words of a message about a problem included. A recording is a capture of whatever you choose to share in your browser's picker, so it shows what that showed, rows of an import included and, inside a CRM tab, your CRM around Sloose; nothing in it is blanked. Besides what this paragraph lists, a request carries the diagnostics the next paragraph describes, unless they are off. What you send is kept in our Userback account, in the United States, until we delete it, and a copy of it, with any screenshot or recording you sent, becomes an issue in our private GitHub repository, also in the United States, where we track the work it needs, until we delete it. Where Sloose offers no Userback form, Contact support writes an email to our support address instead, which reaches us as any email does.

So that we can find and fix the problem a request is about, a request you send from the Sloose app also brings diagnostics, unless they are off. They are: the messages the app wrote to your browser's console, which can quote a value from a file or a record when something went wrong; the address of each request the page made, with when, how long it took, its size and its status — not what it sent or received, nor its headers, though an address can include a value searched for in your CRM; where you clicked, and where you clicked over and over; and a replay of the last few minutes on screen, including what you typed, in which the tables, panels, dialogs and lists that show an import's rows and your CRM's records, and the box a file is pasted into, the sample values shown beside a column or a rule, what the AI was asked about an import and answered, what it is shown and proposes when it fills in a module's fields, the values typed or pasted to show it a field or to try a helper function, what a helper function gave back when tried, and the values a message about a problem quotes, are empty boxes and email and password fields are hidden. For them, Userback's script loads with the app once the page is ready rather than when you press, and keeps the last few minutes in your browser; none of it reaches Userback until you send a request, and Userback is not told who you are until you open the form. Diagnostics come only from the signed-in app, never from this site or the documentation. They are on unless you turn them off on Your account → Preferences, where the choice is yours in every organisation you are in, and an organisation's administrators can turn them off for everybody in it on Settings → Support and your data; while they are off, the app starts Userback only when you press and asks it to collect none of them. Turning them off stops the collecting at once on the page where you do it, and on any other page of Sloose you have open the next time it checks, or when you press there, whichever comes first; nothing collected before is sent. Userback's script, once loaded, stays in the page until you leave or reload it, collecting nothing. They are kept with the request in our Userback account, in the United States, and with its copy in our GitHub repository wherever Userback includes them, until we delete them, and are used for nothing but the request they came with.

On this site and in the documentation, Send feedback and Report a problem with this page open the same form from Userback, and nothing of Userback's is loaded until you press one. Nobody signs in there, so the form asks for your name and email address and you need not give either. What you send goes to Userback with it: your message; any name and email address you give; the address and title of the page you were on; which of Sloose's deployments the page came from, and the version of its code; and your browser, system, and window and screen size. No diagnostics are sent from these pages, and no screenshot is taken unless you press for one. What you send is kept, and copied to our GitHub repository, as a request from the app is.

When a page stops

When a page of the Sloose app stops with an error, the page sends us a report of four things: the error’s type, such as TypeError; which of a few kinds of failure it was, such as reading something that was not there; the version of Sloose it was running; and which kind of page it was on, such as an import or a settings page. It never sends the error’s message, the page’s address, a stack, your name or email address, an ID, or anything from your data or that you typed, and nothing in it says who you are or which organisation you are in. A page that stopped only because Sloose was updated while it was open is not a crash and sends nothing.

Technical logs

Our hosting provider records request metadata (IP address, user agent, timestamps, status codes, and the address requested — which, for a search of your CRM, includes the value searched for) for security and debugging. These logs are kept for a few days and are not joined to your CRM data.

An email with a sign-in link says roughly where the link was requested from — the city and country our hosting provider places the request in, and the browser and system it names — so that a link you did not ask for is easy to spot. It never includes the IP address, and we do not store it.

Analytics on this site and in the documentation. These two sites, and not the Sloose app, count visits in two ways. Cloudflare Web Analytics, which our hosting provider adds to these pages, is cookieless: it stores nothing in your browser and reports aggregate page views and performance without tying visits together. Google Analytics 4 runs under your choice. The first page you read shows a banner with Accept and Decline, and every one of Google's four consent signals (analytics storage, ad storage, ad user data and ad personalisation) starts denied. Before you choose, and if you decline, Google's tag is still loaded in that denied state: it stores no cookies and no identifiers in your browser, and sends only cookieless pings, which carry the address of the page and what any server you contact receives, your IP address and browser details, without tying visits together. If you accept, only analytics storage is granted: Google Analytics sets cookies (_ga and _ga_…) and records which pages you read, how you arrived, your browser and device, and an approximate location worked out from your IP address. The three advertising signals stay denied whatever you choose, Google signals and ad personalisation are off, and we use none of it for advertising. You can change your answer at any time from Cookie settings in the footer of any page here: declining removes the analytics cookies those pages can reach, and clearing your browser's cookies for sloose.com removes any that remain. Your choice is kept in your browser's local storage, on the device you made it on.

3. What we do not collect

We do not store the records you create or update in your CRM — beyond what section 2 lists of each run, for as long as the run's history is kept: a record's ID, what happened to it and the values it was matched and linked by — nor the records read from it: these pass through our API between the app, or your own API client, and Zoho, and are held only while each request is processed, apart from a search's value in the request's address, which the technical logs in section 2 keep for a few days. The one exception is the record names sent to our AI provider for a lookup field, which its gateway's log keeps as section 2 says. Nor do we store Zoho data beyond the metadata described above. The Sloose app sets no cookies for tracking; the only analytics cookies are Google Analytics's, on this site and in the documentation, and only if you accept them (section 2). Your browser keeps your session, your display preferences, such as the theme, and your answer to the analytics banner between visits, and nothing else — until you open Userback's form (Contact support, Report a problem or Suggest an idea), which may keep data of its own in your browser from then on. Templates, private or shared with your organisation, are stored by us and carry no rows.

4. Why we process it

To provide the service you asked for (contract), to bill you (contract), to keep the service secure and prevent abuse (legitimate interest), and to meet legal obligations such as tax records. AI assistance runs only on your instruction (consent, withdrawable by not using the feature). Google Analytics on this site and in the documentation sets cookies only after you accept (consent, withdrawable from Cookie settings in any page's footer); before that it sends cookieless pings, and Cloudflare Web Analytics is cookieless (aggregate counts of visits, our legitimate interest in knowing which pages help).

5. Where it goes

We use a small number of processors, each bound by their own data processing terms:

Sloose is hosted on Cloudflare's global network. Our database, the files you import and the files you upload are stored in Cloudflare's Oceania region, and the database keeps no copies elsewhere. Requests are processed wherever Cloudflare's network serves you. The meter for your plan is a Cloudflare Durable Object, which Cloudflare places near where it is first used. It keeps, for each run, who authorised it, when, how many rows it wrote and how it ended, for as long as your organisation exists; and while a run is being written it holds the IDs of the CRM records the run has made — and, for a record our database would not take, what happened to it, your CRM's error text and the values it was matched and linked by — until they are recorded with the rest of the run after it ends — the ID of an update your CRM never answered, until your organisation's next run an hour or more later, or until it is erased. Each import has a Durable Object of its own too, which knows who has the import open and how its run stands, and forgets both once nobody has it open and no run holds it. If you need a specific storage region, contact us before connecting your organisation. The full list of sub-processors and our data processing terms are in the Data Processing Addendum.

6. How long we keep it

7. Your rights

You can ask us to access, correct, export or delete the personal data we hold about you, or to restrict or object to its processing. You can delete your own account at any time from Your account in Sloose, as section 6 describes — unless you are the only owner of an organisation that is still open: close it, or make someone else an owner, first. An organisation's owner can close it at any time from their Sloose account, which triggers the deletion schedule above. Email hello@sloose.com and we will respond within 30 days. If you are in the EU or UK you may also complain to your local supervisory authority; in Australia, to the Office of the Australian Information Commissioner.

8. Security

Traffic is encrypted in transit, the credentials of your CRM connections are encrypted at rest with a key held separately from the database — and a sign-in's token is not kept past the sign-in — access to production is limited to named Dinode staff, and every API request is scoped to a single organisation. Report vulnerabilities to security@sloose.com.

9. Children

Sloose is a business tool and is not directed at people under 18.

10. Changes

We will post updates here and, for material changes, notify organisation administrators by email at least 14 days before they take effect.

This version, of 18 October 2026, says that a page of the app that stops with an error now sends us a short report, described under “When a page stops”. The version of 4 October 2026 added Google Analytics on this site and in the documentation, which sets cookies only after you accept, and says that Cloudflare Web Analytics there is cookieless (sections 2, 3, 4 and 5). The version of 3 October 2026 described what had changed since the version of 2 October 2026. The documentation and this site now offer a form for feedback, which section 2 describes. A question about a formula now also sends the rows you mark as coming out wrong, with what you say each should be, and the shapes its current result takes across the file's rows, counted — under the none setting, or where a field or column is excluded from AI, only how many shapes there are. A screenshot or replay sent with a request from the app now blanks the values a message about a problem quotes, as well as the tables, panels and lists it blanked before. And under your organisation's masked AI data setting, the values of a column mapped to a picklist or a multi-select field are now sent to our AI provider so they can be translated: that column's distinct values alone, nothing else of the file, never a field an administrator has excluded from AI and never a column named like one. A field excluded from AI, and a column named like one, is now never sent in any form, not even as its shape, and the examples written for it are sent in its place. And when an administrator asks Sloose to fill in a module's fields, we now read up to 20 of that module's records from your CRM for the request, under the same setting, and keep none of them anywhere: the gateway keeps such a request's metadata alone, never what it carried. And a screenshot or replay sent with a request from the app now blanks, too, what the AI is shown and proposes when it fills in a module's fields, the values typed or pasted to show it a field or to try a helper function, and what a helper function gave back when tried.