Use Case 11: Accelerate PoCs & pilots

Deliver privacy-safe datasets fast to validate ideas, integrations, and workflows.

Use this use case when you need to validate a new idea fast. This includes internal proof-of-concepts and external pilots.

The focus is speed and safe collaboration. You want data that behaves like production. You do not want production risk.

What problem this use case solves

PoCs and pilots often stall on data access.

Teams wait on approvals, exports, and manual data prep. When data finally arrives, it is incomplete or unrealistic.

You need a repeatable way to provision privacy-safe, production-like datasets. You also need to share them with stakeholders.

When to choose this use case

Pick this when speed is the primary constraint.

If you’re unsure, start with De-identify, keep scope to one “must-work” flow, and only mask fields validated by the app/API.

• You need a usable dataset in days, not weeks.

• You test one or two “must-work” workflows end-to-end.

• You collaborate across teams, vendors, or partners.

• Privacy rules block production copies.

• Run a PII scan before sharing outputs.

• Duplicate the workspace before big changes. See Duplicate a workspace.

When to avoid this use case

Skip this when you need a long-lived, governed setup.

• You need stable DTAP baselines for many teams. Use Use Case 1: Application & API Testing.

• You need stable, repeatable demo narratives for sales or pre-sales. Use Use Case 3: Demo Data.

• You need formal external data sharing approvals. Use Use Case 9: Data Sharing & Monetization.

• If you mainly need upsampling, focus on AI synthesize and performance tuning.

Recommended Syntho configuration

This setup is optimized for fast iteration with safe sharing.

You start simple. You get a working dataset. You then tighten rules where the PoC depends on them.

1

Prerequisites

Checklist

• “Must-work” workflow defined (1–2 flows).

• Sharing boundary defined (internal vs external pilot).

• Reset cadence defined (ad-hoc vs weekly).

• Use the Prerequisites checklist.

Quick start checklist: first 48 hours

Use this when you need momentum fast and you don’t want to over-design early.

Day 0–1 (get a first dataset):

• Choose one “must-work” flow (e.g., login → search → checkout).

• Agree on success metrics (example: “demo the flow with 0 PII leakage” and “refresh in <30 minutes”).

• Create a workspace via Create a workspace and run a first PII scan.

• Apply masking for validator-critical fields (emails, UUIDs, IBANs).

• Generate a small dataset first (smoke test), then scale up.

Day 1–2 (iterate with stakeholders):

• Review the dataset with the PoC team and privacy lead.

• Capture issues as a short backlog (missing tables, broken joins, unrealistic values).

• Duplicate the workspace before large changes. See Duplicate a workspace. This makes rollbacks easy.

2

Source & destination management

Create one workspace per PoC or pilot. Examples: poc-crm-integration, pilot-partner-x.

• Duplicate a working workspace before big changes. This gives you a rollback point.

• Use simple versioned names like v1, v2, baseline, or pilot-partner-x.

Baseline rules

• Keep the source stable. Prefer snapshots or back-ups.

• Avoid a live production source for iterative work.

• Keep the destination isolated. Never write into production.

• Keep schemas aligned between source, workspace and destination.

• Use views when you need only a subset of the original database.

Lifecycle rule of thumb

• Keep the source connection when you expect schema changes.

• Remove the source connection when you expect a new run only much later.

• Revalidate after schema changes. Use Validate and synchronize workspace.

Nuances for this use case

• For external pilots, treat the environment like an external share. Restrict access and default to stronger unlinkability.

• Don’t reuse a PoC workspace for a new initiative. Old generator decisions silently carry over.

• Clean up connectors and access after the pilot. Make it part of close-out.

• Create a workspace

• Duplicate a workspace

3

Configure generators

Workspace initialization mode

Choose a workspace mode. It applies baseline generator suggestions during workspace creation.

Recommended modes for this use case:

• De-identify when you start from a production-like copy and need fast, safe parity.

• Mock or mask all when you want stronger separation from the source but still need realistic formats.

• Mock all when you have no usable source data yet (early product work).

AI-generated synthesis

Use this when the PoC needs realistic distributions or more rows quickly, and you’re not asserting row-level parity.

Example (integration at scale): synthesize a poc_contacts_entity_view to generate 5× more contacts so you can validate connector throughput and UI pagination without using real identifiers.

Rule-based generation

Use this to guarantee the PoC has the exact scenarios stakeholders will test. Use Calculated columns to keep demos repeatable.

Example (must-have workflow states): assign a stable stage based on a numeric key so every stage appears across refreshes.

// New column: onboarding_stage (stable by id modulo)
SWITCH(MOD([customer_id], 3),
  0, "NEW",
  1, "IN_PROGRESS",
  2, "COMPLETED",
  "NEW"
)

Use an integer-like key column here. If your IDs are UUIDs, use a numeric surrogate key for the lab.

Masking

Use this when partner systems validate formats, and you need stable keys/joins during multiple PoC refreshes.

Example (API contract fields): mask email, phone, and external_id to valid formats, and enable consistent mapping for identifiers used across tables so the integration doesn’t break between runs.

Hybrid

Use this when you need speed plus just enough realism and governance to share safely.

Example (fast baseline + scenario control):

1. De-identify a production-like snapshot for quick parity.

2. Add calculated “scenario columns” that drive the PoC story (workflow stage, flags).

3. Publish a flattened stakeholder view and synthesize it if you need unlinkability.

A simple “demo label” trick that makes filtering obvious in UIs:

// New column: demo_account_label
CONCATENATE(PROPER(MOCK_COMPANY_NAME), " - ", [onboarding_stage])

Minimal configuration steps

1. Start with de-identification for parity (or mock-first if no source exists).

2. Mask only the fields the integration validates (emails, UUIDs, IBANs).

3. Add 1–2 calculated “scenario” columns to drive the PoC story.

4. Run a PII scan before sharing.

• Automatic PII discovery with PII scanner

• Manage personally identifiable information (PII)

4

Handle keys and relationships (relational schemas)

If your PoC uses a single table (no joins), you can skip this step.

PoCs fail on broken relationships.

Validate primary keys and foreign keys early. Add virtual keys if the schema is incomplete.

Use Manage foreign keys and add virtual foreign keys when the database schema is incomplete.

• Manage foreign keys

• Key generators

5

Validate and sync

Validate quickly on a subset.

Run the “happy path” scenario the PoC exists to prove.

Re-run validation whenever schemas or requirements change. Use Validate and synchronize workspace.

• Validate and synchronize workspace

6

Tune generation settings

Optimize for short feedback loops.

Keep settings stable so results are comparable across iterations.

Use View and adjust generation settings when runtime becomes the bottleneck.

• View and adjust generation settings

Common pitfalls & misconfigurations

Use-case specific pitfalls

• Starting the PoC without a clear success definition.

• Using real production data in pilot environments.

• Enabling consistent mapping for external sharing without a privacy review.

• Over-modeling the dataset.

  • Get the critical flows working first.

General pitfalls

These pitfalls show up in most projects:

• Running full-scale jobs before a small validation run.

• Skipping workspace validation/sync after schema changes. Use Validate and synchronize workspace.

• Breaking relational integrity (missing PK/FK setup, missing foreign keys, missing virtual foreign keys). Start with Manage foreign keys and virtual foreign keys.

• Leaving sensitive columns on Duplicate, or trusting the PII scan without reviewing false positives/negatives.

• Overusing Consistent mapping (it slows down data generation and increases linkability).

Governance, compliance, and automation

Governance, access control, and audit evidence

Keep the workspace configuration as a controlled artifact. Treat it like “test data release”.

Recommended roles

• Workspace Owner: data steward or privacy lead. Approves generator choices and sharing.

• Workspace Editor: data engineer or platform engineer. Implements configuration changes.

• Workspace Reader: testers, analysts, or trainees. Can run jobs but should not change rules.

See Workspace & user management and Share a workspace.

Access control checklist

• Use read-only access to the source database for day-to-day users.

• Restrict who can view source data in the UI. Don’t default to broad access.

• Use a dedicated destination per environment (dev, test, accept, sandbox).

• Keep external recipients in a separate workspace with stricter settings.

Evidence for auditors (lightweight but useful)

Capture these items per delivery or refresh:

• Workspace name, owner, and intended audience.

• PII scan results and the final list of “PII columns + applied generator type”.

• Any enabled privacy controls (e.g., rare category protection, free-text de-identification scope).

• Validation output and/or QA report (when applicable).

• Approval notes (ticket link, privacy board sign-off, or risk acceptance).

Automation and deployment (reference)

You can automate workspace setup, scans, and generation runs via the Syntho REST API.