Sloose

Privacy policy · effective 8 September 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 for Zoho CRM, what we do with it, and how to get it removed. Questions go to hello@sloose.com; security reports to security@sloose.com.

1. The short version

2. What we collect

Account and organisation data

When you sign in through Zoho we receive your Zoho user ID, email address, display name, profile or role name, and your Zoho CRM organisation ID and name. We use these to create your Sloose account, map Zoho roles to Sloose permissions, and keep organisations separate.

Connection credentials

When an administrator connects an organisation, Zoho issues an OAuth refresh token. We store it encrypted at rest and use it only to read module and field metadata for your CRM (so the wizard knows your fields) and to keep that metadata current. Records are not read or written with it.

Configuration and job metadata

Field mappings, match rules, value translations, templates, helper libraries you push with the Sloose SDK, and per-job records such as module names, row counts, timings, outcomes and error messages. Job records describe what happened; they do not contain the row data itself.

Billing

Payments are handled by Stripe. We store your Stripe customer ID, plan, credit balance and invoice references. Card numbers never reach our systems.

AI assistance

When you ask Sloose to propose mappings or value translations, we send the column headings, the destination field definitions, and a small sample of values from the affected columns to our AI provider, then discard the request once the proposal is returned. Sample values may contain personal data if your file does; use AI assistance only on data you are comfortable sending.

Technical logs

Our hosting provider records request metadata (IP address, user agent, timestamps, status codes) for security and debugging. These logs are kept for a short rolling window and are not joined to your CRM data.

3. What we do not collect

We do not store the contents of files you import, the records you create or update, or Zoho data beyond the metadata described above. We do not use cookies for tracking; the only browser storage we use holds your session and unsent wizard drafts on your own device.

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).

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; data is stored in Cloudflare's distributed database and may be processed in any region where Cloudflare operates. 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. Administrators can disconnect an organisation at any time from inside Sloose, 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, credentials are encrypted at rest with a key held separately from the database, 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.