What we collect, and why

Written to be read. Every section names the specific data involved and the reason it exists, because a policy that describes purposes in the abstract does not tell you what actually happens.

Last updated

1. Who this covers

This document distinguishes two relationships, because the obligations differ. When you visit this website or write to us, we decide what happens with your data — in DPDP terms we are the Data Fiduciary. When you run workflows on the platform and those workflows process your customers' data, you decide; we act on your instructions as a Data Processor and hold no independent purpose of our own for that data.

The distinction matters practically. A request from your customer about their data comes to you, not to us, and we support you in answering it rather than answering on your behalf.

2. What we collect and why

Each category below exists for a stated purpose. If we could not name the purpose, we would not collect the field.

  • Account details — name, work email, organisation, role. Purpose: authentication, access control, and knowing who approved what inside your workspace.
  • Billing details — entity name, GSTIN, billing address, payment reference. Purpose: invoicing and statutory tax records. We do not store card numbers; the payment processor holds those.
  • Workflow configuration — the steps, rules, thresholds, and connector scopes you define. Purpose: running the workflows, and reconstructing which rule version applied to a past run.
  • Execution records — run inputs and outputs, gate decisions, approver identity, timestamps. Purpose: the audit trail. This is the data that lets you answer a review question months later, which means it is retained deliberately rather than incidentally.
  • Support correspondence — what you write to us and our replies. Purpose: resolving the issue and recognising recurring faults.
  • Website analytics — page views and referrer, aggregated. Purpose: understanding which documentation people cannot find. No cross-site tracking and no advertising identifiers.

4. Personal data and AI steps

Where a workflow includes an AI step, redaction runs before the prompt is assembled: identifiers and credential-shaped strings are replaced with typed placeholders, and the mapping back to the original values stays inside your tenancy. The model receives the placeholders. A response is rehydrated locally, so a reply can reach your customer with their real name in it without the model having received that name.

Each AI step names its model and processing region in the workflow definition rather than inheriting an account default, so the region cannot be changed by a settings edit made elsewhere in your account.

We do not use your data, your workflow definitions, or your execution records to train models.

5. How long we keep it

Retention is set per category, and each period has a mechanism that enforces it rather than a policy that describes it.

  • Account details: for the life of the account, then 30 days.
  • Billing records: eight years, because Indian tax law requires it. This period overrides a deletion request for the records it covers, and we will tell you that rather than silently retaining them.
  • Execution records and audit trail: the retention period stated in your plan. Audit entries are append-only within that window, so correcting one adds an entry rather than editing the original.
  • Support correspondence: two years.
  • Backups: 35 days, after which restores can no longer reach that point.

6. Who else is involved

We use sub-processors for infrastructure, payments, email delivery, and model inference. Each is engaged under terms that pass through the obligations we owe you, and the current list is available on request with the category of data each one handles.

We do not sell personal data, and we do not share it for anyone else's marketing. We disclose data to a government or law-enforcement body only where legally compelled, and we notify you unless we are prohibited from doing so.

7. Where data is processed

Workflows pinned to an India region are processed in India, including their model calls. Where a workflow is deliberately configured to use a model hosted outside India, that is visible in the workflow definition rather than buried in an account setting, so the transfer is a choice you can see and audit.

Company operations — support correspondence and billing — may involve access from other jurisdictions where our team is located, under the same contractual terms.

8. Children

This is a business platform and accounts are for people acting for an organisation. We do not knowingly create accounts for anyone under 18, and we do not profile children, serve them behavioural advertising, or track them across sites — none of which the platform does for any user.

If you believe a child's data has reached us through an account, write to privacy@sentryflow.tech and we will delete it and tell you what was held.

Where your own workflows process a child's data, the obligation to obtain verifiable consent from a parent or guardian is yours, because you are the Data Fiduciary for it. We cannot verify a relationship we never see. What the platform gives you is the means to evidence the consent you obtained: the record of which rule version applied to a run, and who approved it.

9. Security safeguards

Data is encrypted in transit and at rest, credentials sit in an envelope-encrypted vault whose plaintext exists only inside a single execution step, production access is time-bound and logged, and the audit trail is append-only and hash-chained so alteration is detectable. The security document describes the architecture in full, and says plainly what it does not claim.

No safeguard makes a breach impossible, and we do not describe ours as though it did.

10. If there is a breach

Where personal data we hold is affected, we notify you and the Data Protection Board of India as the DPDP Act requires. Our notice states what we know, what we do not yet know, and what we are doing about it — an early notification that admits uncertainty is more useful to you than a complete one that arrives late.

We rehearse this. A notification process first exercised during a real incident fails during a real incident.

Where the breach affects data your workflows process, the duty to inform your own Data Principals is yours. We give you the run records and audit entries you need to establish scope, and we will not slow that down while our own review is running.

11. Your rights, and how to use them

You may ask for access to your personal data, correction of what is inaccurate, erasure where no legal obligation requires us to keep it, and a summary of the processing we carry out. You may nominate someone to exercise these rights on your behalf if you are unable to.

Requests go to privacy@sentryflow.tech and are acknowledged within 72 hours. That route exists separately from sales and support on purpose: a request with a statutory clock attached must not queue behind a commercial inbox.

Where we refuse a request we tell you why, naming the obligation that requires us to keep the data rather than citing policy in general terms. If you disagree with the outcome, section 12 explains how to escalate.

12. Grievance redressal

If you are unsatisfied with how we handled a request, raise a grievance with our Grievance Officer at privacy@sentryflow.tech. We acknowledge within 72 hours and respond substantively within 30 days; where a matter needs longer, we tell you why before the 30 days expire rather than after.

If our response does not resolve it, you may complain to the Data Protection Board of India. You do not need our permission to do that, and we will not ask you to exhaust our process first.

13. Changes

Material changes are notified at least 30 days before taking effect, with the previous version remaining available for comparison. Changes that narrow how we use data take effect immediately, since there is no reason to delay those.