Data residency and cross-border transfers in FlowTux

Where your support data physically lives is a compliance question, not just an engineering one. Some countries restrict moving personal data across borders, some require certain categories to stay in-country, and procurement teams increasingly ask before they ask about features.

FlowTux runs three data regions — United States, European Union, and India — chosen when the workspace is created. This post covers what that actually guarantees, what still crosses a border regardless, and how to pick. It describes how the product works and is not legal advice.

These get used interchangeably in procurement questionnaires and they mean different things, which is why vendors and buyers so often talk past each other.

Residency is about where data is stored and processed at rest — a technical placement guarantee. Sovereignty is about whose law can compel access to it, which is a function of the provider's corporate nationality and applicable legislation, not of where the disk sits. Localization is a legal requirement that specific data must not leave a country at all, which only a few regimes impose and usually only for particular sectors or categories.

FlowTux offers residency. If your requirement is genuine sovereignty — no possibility of a foreign legal process reaching the data — that is a much stronger requirement and you should test any vendor's answer against it carefully, including ours. Being clear about which of the three you actually need saves a lot of wasted evaluation.

At workspace creation you choose a primary storage region. Ticket content, attachments, and indexed code context stay in that region for processing and at-rest storage, and backups stay within the same regional boundary. Once set, data is not silently relocated.

The infrastructure behind each region is published rather than implied. The United States and European Union regions run on Google Cloud Platform — Google LLC for the US, Google Cloud EMEA Limited for the EU — and the India region runs on Microsoft Azure. The current list, including purposes and scope, is on the DPA page.

Choose deliberately, because moving later is a migration rather than a setting. A region change means relocating ticket history, attachments, the codebase map, and backups, which is a coordinated exercise rather than a toggle. Teams that expect to expand into the EU within a year are usually better off starting there.

Any vendor claiming a region pin makes cross-border questions disappear is overselling. Four things deserve checking on every tool, including this one.

First, the systems you connect yourself. Slack, GitHub, Sentry, Jira, and Teams have their own regions and their own data terms, and a ticket that originated in a Slack thread already exists in Slack's infrastructure wherever that is. Your region pin governs our copy, not theirs.

Second, optional integrations. WhatsApp notifications route through Meta Platforms in the United States and are only in scope if you enable them — which is exactly why they are listed as a sub-processor with that condition attached rather than bundled into a general statement.

Third, support access. When our engineers troubleshoot a workspace at your request, that access is governed by contract and access controls rather than by geography, and any vendor that tells you support never touches data is describing a product that cannot be supported.

Fourth, your own users. A workspace pinned to the EU whose engineers travel and log in from elsewhere is still processing in region, but the access pattern is worth documenting for your own record of processing.

The EU and EEA under GDPR, and the UK under UK GDPR and the Data Protection Act 2018, permit transfers only under an adequacy decision or appropriate safeguards — Standard Contractual Clauses for the EU, the International Data Transfer Agreement or the UK Addendum for Britain, in both cases alongside supplementary technical measures. Neither requires localization; both require a documented mechanism.

India's Digital Personal Data Protection Act, 2023 works on a blacklist model: transfers are permitted except to countries the government restricts, and sector regulators can impose stricter rules on top — which is why financial services and health teams in India often have requirements that go beyond the Act itself.

Canada under PIPEDA and Australia under the Privacy Act and the APPs both permit transfers while keeping you accountable for the recipient's handling — meaning the obligation is contractual diligence rather than geography. Brazil's LGPD tracks the GDPR structure closely. The United States has no federal transfer restriction; the questions there come from state privacy laws and from sectoral rules, and increasingly from customer contracts rather than statute.

For a support tool specifically, the practical upshot is that almost nobody needs localization and almost everybody needs a documented mechanism plus a sub-processor list they can hand to a reviewer.

The cheapest way to handle cross-border risk is to move less data in the first place. Personal identifiers are stripped and tokenized from code context before indexing, and fields you mark as sensitive are excluded from analytics and from AI prompts entirely.

Retention is the other half and it is the one teams leave at defaults. A shorter clock on attachments than on ticket text is usually right, because attachments are where unexpected personal data accumulates — screenshots, exports, log bundles — and they are rarely needed after resolution. Deciding this once at rollout is far easier than reconstructing it during an access request.

If most of your users and obligations sit in one jurisdiction, pin there and document why. Multi-region teams should generally pin to the strictest regime they answer to — usually the EU — because SCC-backed transfers outward from the EU are well-trodden, while pulling EU personal data into a weaker region after the fact is the harder problem to solve.

Two exceptions worth naming. If you have an Indian sector regulator with in-country requirements, pin to India regardless of where the rest of the company sits. And if your buyers ask for sovereignty rather than residency, resolve that question before choosing a region at all, because the answer may rule out categories of provider rather than particular regions.