Beta data handling

Do not put personal data in process variables during the private beta.

This is a limit of the beta itself, not a setting you can change. TinyConductor keeps every variable change in a record stream whose entries are never changed. They are removed only with the whole instance, once the tenant’s history retention has passed; the beta has no way yet to erase one person’s data before then.

What counts as personal data

Treat a value as personal data when it identifies, describes, or can reasonably be linked to a person. Examples include names, email or postal addresses, telephone numbers, government and employee identifiers, account numbers, health information, free-text case notes, and stable device or customer IDs. Pseudonyms and opaque tokens can still be personal data when the organization can reconnect them to a person. Do not assume that replacing a name with an ID is enough; have the beta’s privacy or security owner approve the data set.

Do not rely on a short history retention either. Until the retention removes an instance, its variable changes stay in the record stream, and they may also appear in search tables, exports, diagnostics and backups, which the retention does not reach. Removing a current variable does not erase its older recorded values.

Designing a beta process

• Keep personal data in a customer-controlled system of record. Where the process can operate on a genuinely non-personal case or order reference, put only that reference in TinyConductor. A token that the organization can map back to a person still needs privacy/security review and may make the process ineligible for beta.
• Prefer case, order, or workflow identifiers that are random and scoped to the integration. Do not use an email address, employee number, or other personal identifier as a business key, correlation key, variable name, or variable value.
• Have workers resolve opaque references only while they need the data. Do not copy the resolved data into task inputs, outputs, error messages, incidents, or completion variables.
• Use synthetic data for demonstrations, acceptance tests, and support reproductions. Masking a real record is not enough if it can still be linked back to a person.
• Review BPMN input/output mappings, worker logs, connector configuration, and failure paths before a process enters beta. These are common places for data to be copied unintentionally.

If a process cannot operate without placing personal data in variables, it is not eligible for the beta. Redesign it around opaque references or wait for the GA data-erasure capability.

Committed GA direction

For general availability (GA), the plan is to encrypt personal data so it can be made unreadable on request:

• Variable payloads will be encrypted with a key per tenant and per person (the data subject), at one single point in the engine.
• To erase a person’s data, the engine destroys that person’s key. The encrypted payload can then no longer be read. The records themselves stay in place, so the audit history remains complete. This technique is called crypto-shredding.

This is a plan, not a beta feature. Key creation, linking keys to people, rotation, destruction, recovery and rebuilding the encrypted views still need to be designed and built. Until that work ships and is verified, the no-personal-data rule stays in force.

The storage layout already prepares for it: each record and history variable keeps its tenant data in one column that can be encrypted later. A build check enforces that layout. It does not mean that payloads are encrypted today.