1. Roles
You are the controller of personal data contained in the files you import and in your Zoho CRM. Dinode is a processor acting on your documented instructions, which are: to provide Sloose as described in the Terms and the Privacy Policy, and any further instruction you give through the product's settings.
2. Scope of processing
| Category | Data | Where processed |
|---|---|---|
| Import rows, and the CRM records members of the organisation read or write through its connections — in an import, to match and link rows, for lookup fields, or through the API | Whatever your file contains, which may include customer names, contact details and business data; the records from your CRM that members read or write, in any of a connection's modules | In your browser while you work, through Dinode's API in transit, and in Zoho CRM. The files you import and their corrections are stored by Dinode (Cloudflare, Oceania region) until the plan's history window has passed since the import was last changed or run — up to 30 days longer after a change of plan — and deleted then, or when the import is deleted, or with the organisation's other data within 30 days of its closing. The CRM records read are not stored, except the names of up to 400 records sent to the AI model to translate values into a lookup field, which the AI Gateway's log keeps (below). What each run did is stored by Dinode (Cloudflare, Oceania region) with the run's history — the plan's history window, up to 30 days longer after a change of plan — or seven days after the run ends for a run made through the API without an import, which is closed, if nobody closes it, once nothing has been written under it for a day: for each record written or attempted, its outcome, its CRM record ID, the CRM's error text and the values it was matched and linked by; for each row not written, that it failed or was skipped, and why; for a dry run, whether each row would have created or updated a record in each module, and none of the values it would have written; and for a retry, a copy of what the runs before it made of each file it reads as they read it. The meter for the organisation's plan, a Cloudflare Durable Object placed near where it is first used, keeps for each run who authorised it, when, the rows it wrote and how it ended, for as long as the organisation exists; and while a run is being written it holds the IDs of the CRM records it has made — and, for a record the database would not take, its outcome, the 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 the CRM never answered, until the organisation's next run an hour or more later, or until it is erased. |
| User identity and sessions | Email, display name; Zoho user ID when signed in through Zoho; for each session, the IP address and browser it was made from, and after a Zoho sign-in the CRM organisation it proved and the person's user ID there | Dinode (Cloudflare). A session is deleted at sign-out, or a month after it expires. The access token a Zoho sign-in returns is used only during the sign-in, to read who the person is and which organisation the CRM is, and deleted when the sign-in is done, or within a day if it failed part-way. |
| Organisation | Organisation name, members' roles, the email addresses it has invited and the requests made to join it; for each connected CRM, its organisation ID, encrypted OAuth tokens and metadata | Dinode (Cloudflare) |
| Configuration and run metadata | Mappings, rules, templates, helper libraries, run outcomes and error text | Dinode (Cloudflare) |
| AI samples and questions about proposals | The question the member asked, column headings, field definitions, a small sample of values; for a question about a formula, the rows the member marked as wrong with what they said each should be, and how many of the file's rows its current result writes in each shape (only how many shapes there are under the none setting, or where a field or column is excluded from AI); to propose how a module's fields are described, that module's field definitions with what the organisation has written about them, values a member pastes for a field, and the values of up to 20 of that module's records read from the organisation's CRM for the request and kept nowhere (the AI Gateway keeps that request's metadata alone, never its contents), each value up to its first 200 characters — all under the organisation's AI data setting, and never the values of a field excluded from AI; for a question about a run, the last run's recorded totals and the modules it wrote to, if there is one, and each file's name, row count and modules in the order the run would take them; to translate values into a lookup field, the names of up to 400 of the CRM records it can link to, with a second field where two share a name — only under the organisation's most permissive AI data setting, and never for a field excluded from AI; under the masked setting, to translate the values of a column mapped to a picklist or multi-select field, that column's distinct values alone, without their counts — never a field excluded from AI or a column named like one, never a lookup's values, and never values a formula made; for a question asked about a proposal that is not kept with an import (the chat API, or 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 the member's is still being saved), also the questions and answers before it in that conversation, and the sample values sent with each question under the organisation's AI data setting | Cloudflare AI Gateway, which keeps a log of each request and its response, sample values included, until it is no longer among the most recent 10 million requests — except a request to propose how a module's fields are described, of which it keeps 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; Anthropic, transient. Questions asked about a proposal are also stored by Dinode (Cloudflare, Oceania region): each question and its answer until the plan's history window has passed since the question was asked — up to 30 days longer after a change of plan — and deleted then, or with the organisation's other data within 30 days of its closing. A later change to the organisation's AI data setting does not rewrite a stored conversation; a stricter setting stops what was sent before the change being sent to the model again. |
| Questions asked about an import | For each question asked with an import's Ask AI (about a file on its 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, and 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) while nothing of the import is waiting to be saved — asked while a change of the member's is still being saved, a question on Which rows & existing or Map columns other than Suggest columns is kept as a question about a proposal (above), and the rest are not stored: the question, the answer, what the answer proposed and where (a row filter, a different reading of the file, a change to its shape, or a generated sample described by its columns and size, 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 the file's values becomes, and an expression written into the formula editor), the answer's notes (what it could not do, and what Dinode refused of it), what of the file the answer was made from under the organisation's AI data setting, the member who asked, and whether 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 turned down there, which answer made it. No sample rows are stored with a question; an answer and what it proposed can quote values from the file, and so can its notes under the organisation's most permissive AI data setting — under the others, no stored note carries a value of the file. | Dinode (Cloudflare, Oceania region), with the import, readable by the members who can open it: each question and its answer until the plan's history window has passed since the question was asked — up to 30 days longer after a change of plan — and deleted then, or, for 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 the draft's proposals for the import's values, are about no one file, and stay with the import), with the import when it is deleted or expires, or with the organisation's other data within 30 days of its closing. A member who is deleted leaves their questions with the import, naming nobody. Sent to the AI model again, through the AI Gateway (above), before a new question at the same place, only while the organisation's AI data setting is no stricter than what they were made from. |
| Billing | Stripe customer ID, plan, invoices | Stripe |
| Support requests | Sent when a member chooses Contact support, Report a problem or Suggest an idea: their message, name and email address, the address of the page they were on (which can include the organisation's ID or an import's), which deployment of Sloose and which version of its code the page came from, their browser, system, and window and screen size, and, if they choose to take one, a screenshot of Sloose's page alone — inside a CRM tab, the CRM around it is not in it — in which the tables, panels, dialogs and lists showing import rows and the 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 blanked but anything else the page showed is not, or a recording of whatever they choose to share in their browser's picker, which can include import rows and, inside a CRM tab, the CRM around Sloose, and in which nothing is blanked. With them go the member's Sloose user ID, and the organisation they were working in, by its ID and name, with their role in it; the member's user ID, name and email address reach Userback as the form opens, before anything is sent, for its list of the people who have contacted Dinode. Nothing of an import's files, rows or records is added, besides what the diagnostics in the next row can show. The documentation's Report a problem with this page and sloose.com's Send feedback open the same form for anybody, signed in or not: what is sent from there is the message, any name and email address the person gives, the address and title of the page, which deployment of Sloose and which version of its code the page came from, and their browser, system, and window and screen size — no diagnostics, and a screenshot only when they press for one. | Userback, in Dinode's account (United States), until Dinode deletes it; a copy of each request, with any screenshot or recording sent, as an issue in Dinode's private GitHub repository (United States), until Dinode deletes it |
| Support diagnostics | Sent with a support request from the signed-in app — never from the marketing site or the documentation — unless the member has turned them off, or the organisation's administrators have for everybody in it, so that Dinode can find and fix the problem the request is about: the messages the app wrote to the browser's console, which can quote a value from a file or a record; the address of each request the page made, with its timing, size and status, but not its body or headers, though an address can carry a value searched for in the CRM; where the member clicked, repeated clicks included; and a replay of the last few minutes on screen, including what they typed, in which the tables, panels, dialogs and lists showing import rows and the 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. While diagnostics are on, Userback's script loads with the app and keeps the last few minutes in the browser; none of it reaches Userback until a request is sent, and Userback is told who the member is only when they open the form. While they are off, the app asks Userback to collect none of them. | With the request: Userback, in Dinode's account (United States), and its copy in Dinode's GitHub repository wherever Userback includes them, until Dinode deletes them |
3. Dinode's obligations
- Process personal data only on your instructions, unless the law requires otherwise, in which case we tell you first where we can.
- Ensure staff with access are bound by confidentiality and limited to what their role needs. A named Dinode staff member giving support may view an organisation as one of its members: read-only, unless they record why and confirm the organisation's name, and every such view is logged.
- Maintain the security measures in section 5.
- Assist you with data subject requests, impact assessments and regulator enquiries, at reasonable cost where the work is substantial.
- Notify organisation administrators without undue delay, and in any case within 72 hours, of a personal data breach affecting your data, with what we know at the time.
- Delete or return personal data at the end of the service on the schedule in the Privacy Policy, except where the law requires retention.
- Make available the information needed to show compliance and allow audits, on reasonable notice and no more than once a year unless a regulator or breach requires otherwise.
4. Sub-processors
You authorise the sub-processors below. We will post changes on this page at least 30 days before a new sub-processor handles your data; if you object on reasonable data protection grounds and we cannot resolve it, you may terminate the service and receive a pro-rata refund of prepaid fees.
| Sub-processor | Purpose | Location |
|---|---|---|
| Cloudflare, Inc. | Hosting, database (D1), object storage for imported files (R2), Durable Objects, edge network, AI Gateway, email sending and routing | Global network; United States headquartered |
| Anthropic, PBC | AI model for mapping and value suggestions, and for proposing how fields are described | United States |
| Stripe, Inc. | Payments and invoicing | United States, with EU and Australian entities |
| GitHub, Inc. | Tracking the work support requests need: a copy of each, with any screenshot or recording sent | United States |
| Userback Pty Ltd | Support requests, problem reports and ideas sent from Sloose's menu, and the diagnostics sent with them; feedback sent from the documentation and sloose.com | Australia; hosted in the United States (Amazon Web Services) |
| Zoho Corporation | CRM platform, API access, optional sign-in | Data centre matching your Zoho account region (US, EU, India, Australia, Japan, Canada, UK, Saudi Arabia, UAE or Singapore) |
5. Security measures
- TLS for all traffic; HSTS on all Sloose hostnames.
- CRM connection credentials encrypted at rest with a key stored outside the database; the token a sign-in returns is deleted when the sign-in is done, or within a day if it failed part-way.
- A records request reads or writes only the modules of a connection, as its discovery read them. Dinode never deletes a CRM record itself; an update is sent to the CRM as the import or API client wrote it, and the CRM decides what it changes — for a multi-select lookup, or a subform sent through the API (an import never sends one), that can mean removing entries.
- Per-organisation scoping on every API route; organisation API tokens are hashed and revocable.
- The backoffice is limited to named Dinode staff, each with a second factor; an administrative token for scripts and first set-up is held, like every secret, in Cloudflare's secret store, never in source control.
- Automated checks that no customer identifiers enter the product codebase.
- Logging of administrative actions; request logs kept for a few days for security review, including the address requested — which, for a search of the CRM, includes the value searched for.
6. International transfers
Where personal data leaves the EU, UK or Australia it is transferred under the sub-processor's standard contractual clauses or an equivalent lawful mechanism. On request we will enter into the EU Standard Contractual Clauses (module two, controller to processor) and the UK Addendum with you; this DPA then incorporates them.
7. Liability
Liability under this addendum is subject to the limits in the Terms of Service, to the extent the law allows.
8. Contact
Data protection enquiries: hello@sloose.com. Security: security@sloose.com. Dinode Pty Ltd, Level 2, 11 York Street, Sydney NSW 2000, Australia.