CRM data import and export, without the two-week consulting engagement.
Upload a CSV or Excel file, map fields in a visual canvas, resolve lookups by display name, dedup against the live tenant on save, download a row-level error report when things fail, and schedule outbound exports to any S3 or SFTP target. Salesforce and HubSpot migration helpers ship on day one.
The gap between a drag-and-drop uploader and a real migration.
Every CRM ships an import button. Most of them ship a drag-and-drop uploader that reads the first row as headers, assumes every column is a string, and silently drops anything that fails a type check. The actual job is harder. Imports have to accept CSV and Excel, map fields across inconsistent header names, resolve lookups by display name instead of ID, dedup against the live tenant without manual pre-cleaning, flag errors row by row, support partial rollback, and expose the full round-trip as a reproducible job that an admin can rerun next quarter without a consulting engagement. The checklist below is the one buyers should walk every CRM through before signing. Strkr ships all nine on every paid tier, no professional-services line item required.
CSV and Excel both
The two formats every team actually sends.
Your sellers export their pipeline to Excel. Your SDRs download lead lists as CSV. Your finance team sends renewals in XLSX with four tabs. The import engine reads both without conversion, autodetects the delimiter and quoting style, handles the UTF-8 BOM Excel loves to insert, and parses multi-tab workbooks into one job per tab. No tell-the-user-to-save-as-CSV workflow. No encoding-mismatch failures on files that opened fine in Excel but choke on upload. The spreadsheet goes in, the records come out.
Visual field mapping
The columns and the fields on one canvas.
Drop the file. The canvas shows your spreadsheet columns on the left and the Strkr fields on the right. Draw a line from source to target, or let the auto-mapper match by header name and data shape. Transform a column with a one-line expression (trim whitespace, title-case names, split a full-name column into first and last). Save the mapping as a named template so next quarter is a one-click rerun instead of a 45-minute setup.
Lookup resolution by name
Match on "Acme, Inc." when the ID is unknown.
Most spreadsheets have an Account Owner column with a display name, not a user ID. Most sheets reference an account by company name, not account UUID. The import engine resolves lookups by configurable key: display name, email, external ID, legacy Salesforce ID, legacy HubSpot ID, or a composite. If a lookup fails, the row flags with a specific "no account matched" message rather than silently inserting a null and corrupting the pipeline.
Dedup on save
Match-and-merge rules that fire before insert.
Point the import at an existing dedup rule, or write a new one inline: email case-insensitive, phone normalized, company name plus domain, or a weighted score across all three. Rows that match an existing record either update, skip, or create depending on the per-rule setting. No post-import cleanup pass with a dedup script. No "we accidentally created 4,000 duplicate contacts last Tuesday" incident. The merge decision happens in-flight, and the audit log shows every write.
Row-level error reporting
A downloadable CSV of exactly what failed and why.
An import run finishes. The job summary shows 4,712 rows accepted, 203 rejected. The reject list is a one-click download: the original row, the specific validation that failed ("phone number invalid: too few digits"), and a column pointing to the exact field. The admin opens the file in Excel, fixes the 203 rows, re-uploads. No cryptic "import failed" toast with no detail. No manual grep through CloudWatch logs.
Resumable jobs
A 100k-row import does not die on row 47,000.
The import engine processes in batches with per-batch checkpoints. If something fails midway (network blip, transient DB error, a single poisoned row), the job pauses, logs the batch, and offers a resume button. No "please re-upload the whole file" workflow. No partial state where the admin has to figure out which 23,000 rows actually made it in and which did not. Resume picks up at the last clean checkpoint.
Preview before commit
Dry-run the first 50 rows before touching the DB.
Hit "Preview" and the engine runs the full validation pass against the first 50 rows without inserting anything. The preview panel shows the parsed values, the resolved lookups, the dedup matches, and the row-level errors in a table identical to the live run. Admins can catch a bad mapping, a wrong dedup key, or a weird delimiter before any data touches production. The preview is instant and reversible by definition.
Audit trail
Every imported record is tagged with its job.
Records created or updated by an import carry a job ID and a timestamp. The audit log shows "created by import job #4821, 2026-10-04 09:12" alongside the admin who ran the job. If a bad import makes it through QA, a single bulk operation reverts every record touched by that job. The reverse is first-class, not a plea-ticket to support. Compliance review is a two-click export instead of a six-hour forensic query.
Partial-column uploads
Update a subset of fields without re-sending the row.
A sales ops lead needs to bulk-update the Renewal Owner on 3,200 accounts. The CSV has two columns: Account ID and Renewal Owner. The import engine understands "upsert by Account ID, update only the mapped field." It does not clobber the other 180 fields with blanks. Partial-column semantics are the default for update mode, not a hidden toggle. The result is that routine field-cleanup work takes minutes instead of a careful full-export, careful full-import ritual.
Field mapping, the detailed view
What the canvas does that a type-ahead dropdown does not.
A field-mapping screen is where most import tools quietly fail. The common pattern is a dropdown per spreadsheet column pointing at a flat list of CRM fields. That shape works for 20-field tenants and dies on 200-field ones. The Strkr canvas is a two-column visual with search, saved templates, inline transforms, type-check previews, lookup resolution rules, required-field warnings, and a conflict pane that lights up when a mapping would overwrite a different source. The result is that a 200-field migration is a 20-minute setup, not a two-day deliverable from a professional-services engagement.
Auto-mapper
Header names are matched before you touch the canvas.
The engine runs a header-similarity pass before the canvas opens. "First Name" matches firstName. "Account Owner Email" matches owner.email. "Deal $" matches amount. The admin opens the canvas with 80 percent of fields already connected and only the ambiguous ones left to resolve. Auto-mapping also learns from your saved templates, so the second import from the same source is nearly fully auto-connected.
Inline transforms
Trim, split, format in a one-line expression.
Click the arrow between source and target. A small expression box opens. "trim" strips whitespace. "titleCase" fixes ALL CAPS names. "split(name, 0)" and "split(name, 1)" break Full Name into First and Last. "lower" normalizes emails. "parseDate(mdY)" turns 10/04/2026 into an ISO date. The expression language is small on purpose, so admins do not need an engineer to run it, and it compiles to a safe sandbox so bad input cannot crash the job.
Lookup key picker
Pick which column resolves an account.
For every lookup field (owner, account, campaign), the canvas offers a key picker: user ID, email, external ID, legacy Salesforce ID, legacy HubSpot ID, display name, or composite. The default for migrations is "legacy Salesforce ID OR email OR display name, in that order." The default for routine CSVs is "display name only." Admins can override per field without a support call. The key picker is also what makes multi-source migrations clean, because the Salesforce column resolves on Salesforce ID and the subsequent HubSpot column resolves on HubSpot ID in the same job.
Required-field warnings
Catch missing mappings before the first row runs.
The canvas lights up every required target field. Required fields without a source line visible as red chips at the top. Non-null defaults with a configured default value show as yellow. Admins see the "you need to map these three fields or configure defaults" state before clicking Preview, not after a thousand rows fail. The warning respects per-type requirements, so lead has a different set from account, opportunity, and the custom-objects you have built.
Type-check preview
See one row rendered through the full mapping.
A side panel renders the first spreadsheet row through the current mapping. The admin sees the actual values Strkr would write: the resolved account, the parsed date, the trimmed name, the normalized phone. If a transform is wrong, it is obvious here before Preview mode even runs. The panel updates live as the admin drags lines, so iteration time on a tricky mapping is seconds, not minutes of upload-fail-fix cycles.
Saved mapping templates
Next quarters import is one click.
Save the current mapping as a named template: "HubSpot Contact Export" or "Weekly ZoomInfo Dump." Next time a file arrives in the same shape, the admin picks the template, confirms the preview, and runs the job. The template includes the field mapping, the transforms, the lookup keys, the dedup rule, and the error-handling policy. Templates are per-tenant and permission-gated, so an admin can share a tested template with the team without worrying about a junior user tweaking it.
Conflict detection
Flag two columns both mapped to one field.
If an admin accidentally drags both "Mobile" and "Phone" to the phone field, the canvas raises a conflict chip. The admin picks a priority or merges the two columns into a formatted combined value. The engine never silently uses one and drops the other. Over the lifetime of a 500-column migration, this one check prevents the single most common data-loss class in CRM imports.
Custom object mappings
Not just Account, Contact, Lead, Opportunity.
Any custom object you have built in Strkr is a valid import target. The canvas enumerates the fields on your custom object with the same shape as the native ones. If you have a Projects custom-object with a dozen fields and a lookup to Account, the import engine handles it with no additional configuration. Multi-object imports (contact + related activities + related opportunities) run in a single job with proper foreign-key resolution.
Field-level permissions respected
Importing cannot escape the permission model.
If an admin running the import does not have write permission on the Account Owner field, the mapping canvas disables that target. There is no "import as admin bypass" shadow pathway. The engine runs under the signed-in user with the same scopes as the UI, which means that security review of imports is identical to security review of the UI. One attestation covers both.
Dedup rules and lookup resolution
The two features that decide whether an import succeeds.
A big import succeeds or fails on dedup and lookup. Dedup decides whether row 4,217 creates a new record or updates the one that already exists. Lookup decides whether an owner column resolves to the right user or inserts null and silently loses the record. Most CRMs ship anemic defaults for both, and most admins only find out when a batch of duplicates lands in production. The Strkr dedup engine is composable, inspectable, and testable from the UI, and the lookup resolver is explicit about every match it makes.
Dedup rule builder
Compose match keys without SQL.
The rule builder lists the fields on the target object and asks for a key. Email case-insensitive. Phone normalized to E.164. Company name plus domain. Composite scores where email counts for 60 points and phone counts for 40, matching above 80. Each rule has a tested shape: match-and-skip, match-and-update, match-and-merge, or match-and-split. Admins preview the rule against a sample before using it in a real job, so there are no surprises on the live run.
Rule library
Reusable rules, not inline guesses.
Dedup rules are first-class library objects. An admin builds "Standard Contact Match" once (email case-insensitive first, then phone+last-name as fallback) and reuses it across every contact import, every API intake, every form submission. The library includes a changelog for each rule, so when a rule shifts from "match-and-skip" to "match-and-update" the audit shows exactly when, who, and why.
Explicit null handling
Null does not match null, by default.
A subtle but important default: a dedup rule on email treats a null email as unique, not matching every other null email in the tenant. The alternative silently merges hundreds of leads that happen to have no email on file. Strkr defaults to the safe behavior and offers an explicit "null matches null" toggle for cases where it is actually the intent, which is rare and worth being explicit about.
Lookup fallback chain
Try ID first, then external ID, then display name.
The lookup resolver walks a configured chain: match on the Strkr UUID if present, then on the legacy source ID (sf__c, hs__c), then on the display name or email. Each step is logged on the row. If row 1,042 resolved its account owner by display name instead of ID, the audit shows it. Reports showing "resolved by display name" are a one-click filter after the job, which is how admins catch the fuzzy-match tail without reading every line.
Lookup ambiguity
Two users with the same display name do not silently merge.
If "Chris Lee" matches two active users, the row flags with "ambiguous lookup" and does not pick arbitrarily. The admin resolves by picking the right one in the error-report UI and reruns the row. The alternative, picking the first match, is the single most common cause of ownership mix-ups in post-migration cleanup. Strkr refuses to silently guess.
Dedup across objects
A row can match a Contact OR a Lead.
The default is to run dedup within the target object. The optional cross-object pass checks: if this new Lead row matches an existing Contact on email and phone, convert the row into a Lead-to-Contact update instead of a new Lead. The convert path respects your lead-conversion configuration, so the audit shows the convert chain. It is the right default for teams that want one record per person regardless of which import pathway created it.
Error reporting that admins actually use
A row-level report, not a success-or-failure toast.
Most CRM imports surface a single toast at the end: "Import complete" or "Import failed." That shape is useless on a 50,000-row job. The admin needs to know which rows failed, why, and how to fix them. The Strkr error pipeline writes a per-row verdict (accepted, rejected, warned) with the specific validation message, the source column, and a reproducible fix path. The report is the one artifact that turns a mass import from a leap-of-faith into a repeatable workflow.
Downloadable error CSV
Original row plus failure column.
The error export is the original uploaded row with two added columns: _row_number and _error_message. The admin opens the file in Excel, filters by error message, fixes the 203 bad rows, saves, re-uploads. No reformatting, no re-mapping, no re-doing work. The reupload runs against the same mapping template that produced the first job, so the fix cycle is tight.
Grouped errors
Twelve rows failed the same validation, grouped.
The error summary groups by validation message. "phone number invalid: too few digits - 47 rows" is a single line. The admin fixes the systemic issue (one bad regex in the source export) and reruns the whole batch instead of fixing 47 individual rows. Grouped errors catch the shape of the problem, not just its symptoms.
Warnings vs errors
Soft issues do not block an import.
A warning (phone number was reformatted from a 12-digit local to E.164) does not block the row. An error (owner lookup unresolved) does. The engine distinguishes the two so admins see what was quietly fixed versus what needs a human. The warning stream is also a diagnostic for improving the next upstream export, because repeated warnings signal that the source system is drifting from the target shape.
Live progress bar
See where you are in a 100k-row job.
The run page shows live counts: 42,113 of 100,000 processed, 41,890 accepted, 223 rejected. The bar is accurate because the engine streams verdicts as it writes. Admins can leave the page and come back to a stable number, and the live view is the same shape as the final summary, so there is no transition at the end. The job finishes, the bar is full, and the download link appears.
Slack notification
A nightly import pings the owner.
Scheduled imports post a summary to a configured Slack channel: "Nightly ZoomInfo import done - 1,842 accepted, 7 rejected, link to error report." The ops team sees the number without opening the UI. If the rejects spike (120 instead of 7), they investigate. Routine runs stay routine. The pattern is the same as every other scheduled job in Strkr, so admins do not learn a bespoke notification shape.
Reproducible fixes
Fix once, apply to future runs.
If the error is "email contains invalid characters" and the root cause is that the source CSV has HTML entities in it, the admin adds a transform to the mapping template and the next run cleans the data automatically. Fixes propagate forward through templates, not backward through manual cleanup. The compound effect is that the error-rate on a given source trends to zero within three or four runs.
Export, not just import
Scheduled, filtered, GDPR-compliant, GDPR-logged.
Export is the other half of the data round-trip, and it is where most CRMs ship their weakest offering. The common pattern is a one-off CSV download from a report page, with no scheduling, no filtering beyond the report, no incremental mode, and no audit of who exported what. The Strkr export engine ships scheduled exports to S3 or SFTP, incremental mode (only rows changed since last run), full history for compliance, GDPR data-subject exports, and a full audit log that shows who exported what, when, and to where.
Scheduled exports
Nightly or weekly, to S3 or SFTP.
Define an export once (filter, columns, destination) and schedule it: nightly at 2 AM, weekly on Sunday, monthly on the first. The engine writes to the configured S3 bucket or SFTP endpoint using credentials you store once in the integration vault. Downstream data warehouses, BI tools, and finance systems pull a stable file every morning without a manual hand-off. The schedule has a status page showing last-run time, row count, and failures.
Incremental mode
Only rows changed since the last run.
A full daily export of 2M records is wasteful. Incremental mode exports only records that were created or updated since the last successful run. The warehouse applies them as upserts. Bandwidth drops, run time drops, and the downstream system still has the full current state. The engine tracks the last-run watermark per schedule so there are no gaps on retries.
Filtered exports
Export only what the downstream system needs.
Not every downstream consumer needs every field. Build a filter: contacts in the US, created in the last 90 days, with an opt-in on marketing email. The export writes only those rows, only the mapped columns. A finance system gets the renewal fields it needs. A marketing warehouse gets the engagement fields it needs. Nobody gets the raw everything that leads to review-by-committee on every new consumer.
GDPR data-subject export
One click, every table, correct format.
A GDPR Subject Access Request lands. Open the contact. Click "Export subject data." The engine walks every table that references the contact (activities, deals, notes, emails, call logs, custom-object child rows) and writes a single JSON archive with every row. The format is the shape the GDPR regulator asks for. The download is logged with the admin who ran it. Response time to a subject request drops from a two-day engineering ticket to a thirty-second UI click.
GDPR right-to-erasure
Delete across the full graph, log the operation.
A deletion request lands. Click "Erase subject." The engine deletes the contact, anonymizes referencing records (replacing personal fields with a tombstone), writes an audit entry, and emits a verification receipt. The receipt is downloadable so the privacy team has proof of execution for the regulator. The pattern is identical whether the request is one record or a batch of 10,000.
Export audit log
Who exported what, when, to where.
Every export writes to the tenant audit log with the admin, the filter, the destination, the row count, and the timestamp. If a departing employee ran a bulk export the week before leaving, security sees the entry. The log is immutable and queryable in the standard audit UI. The export shape is not a special subsystem with its own review workflow; it is one more entry in the same log the rest of the product writes.
Format options
CSV, Excel, JSON, Parquet.
Downstream systems want different shapes. Finance wants Excel. BI wants Parquet for S3. Partners want CSV. Replication tools want JSON. The export engine ships all four formats natively, with sensible defaults per format (ISO dates in JSON, Excel-friendly dates in XLSX, Parquet with typed columns). Format is a per-schedule setting, not a vendor-pick-your-poison choice.
Per-field redaction
Export the record without the sensitive columns.
A marketing warehouse does not need SSN, tax IDs, or bank data. A finance system does not need meeting notes. Each export schedule has a column-level allowlist and a per-column mask setting. Fields in the mask list come through as hashed or redacted values. The redaction is enforced at the export engine, so a misconfigured warehouse cannot accidentally pull raw sensitive data.
Retention policies
Export, verify, then clean up in Strkr.
For teams running "archive to S3 after 7 years" style retention, the export engine chains with a cleanup step: export the records, verify the file, then delete or anonymize the source records in Strkr with a full audit entry. The chain runs as a single reviewable job, not a sequence of brittle scheduled scripts. Compliance review becomes a single-page configuration instead of a cross-team ticket.
Salesforce and HubSpot migration helpers
The two migrations every new CRM has to handle.
Most prospects evaluating Strkr are leaving Salesforce or HubSpot. Both migrations have a specific shape: a long list of object types with field-mapping quirks, legacy IDs that need to persist for cross-system reconciliation, custom fields that live on the deprecated system but still matter, and user accounts with ownership and historical attribution that must survive the move. Strkr ships named migration helpers for both, with the field maps, lookup resolvers, and ID preservation already in place. The helpers do 80 percent of the migration work. The remaining 20 percent is per-tenant customization that the admin runs through the standard canvas.
Salesforce helper
Objects, fields, owners, legacy IDs.
Point the helper at a Salesforce export (via the connected app you authorize for read-only extract, or raw Data Loader CSVs). The helper enumerates Account, Contact, Lead, Opportunity, Case, Activity, and your custom objects. For each, it writes a default mapping that preserves the Salesforce ID in a legacy_sf_id field on the Strkr record. Lookups resolve on legacy ID first, so Opportunity-to-Account resolves cleanly even when the Account was imported in a prior pass.
HubSpot helper
Contacts, Companies, Deals, Engagements.
The HubSpot helper handles the four core object types plus notes, calls, and emails. It preserves the HubSpot ID in a legacy_hs_id field and resolves lookups the same way. HubSpot-specific fields (lifecycle stage, lead status) map to the Strkr equivalents by default. Teams migrating from HubSpot typically run the helper, review the field map once, and ship the full migration inside the same business day.
User mapping
Old owners become new owners, by email.
Both helpers run a user-mapping pass before the data pass: match Salesforce or HubSpot user records against Strkr users by email, and build a lookup table. The data pass then resolves owner fields through the table. If a legacy user does not exist in Strkr, the helper flags the records and offers to assign them to a configured fallback owner. The system never silently drops ownership.
Historical activity
Preserve the full engagement timeline.
Both helpers can bring over the activity history: tasks, calls, emails, notes, meetings. Each is written as a Strkr Activity record with the original timestamp, author, and body preserved. The post-migration timeline on each contact reads like it always lived in Strkr. For teams migrating with multi-year renewal cycles, preserving the history is non-negotiable, and the helpers ship it on day one.
Custom field detection
Enumerate every custom field in the source.
The helpers read the schema of the source system and enumerate every custom field with its type and label. The admin walks a two-column view: "Create matching field in Strkr" or "Skip." For custom objects, the helper offers to generate a matching Strkr custom object with the full field set and reference links. The admin reviews once and the full schema migrates with the data.
Incremental migration
Not a one-shot cutover.
Teams that cannot cut over in a single weekend run the migration incrementally: a weekly sync from Salesforce or HubSpot into Strkr for the pilot cohort, with a stable field map and legacy IDs preserved. When the full org is ready, the sync becomes the final cutover and the source system goes read-only. The engine supports this shape natively because every job is reproducible by design.
Three migration patterns the helpers handle well
What the move looks like on a real sales floor.
The demo video shows a chart. The product in production looks like three specific migration patterns teams run. These are the three Strkr customers run most often, with real timelines.
Salesforce to Strkr, 60-rep team
Weekend cutover, Monday standup unchanged.
A 60-rep team on Salesforce Enterprise exports Account, Contact, Lead, Opportunity, and three custom objects on Friday afternoon. The Salesforce helper imports everything by 8 PM Saturday. Admins spot-check a hundred accounts Sunday. Monday standup runs on Strkr with every legacy_sf_id preserved for finance to reconcile against the Salesforce reports. No lost history, no re-training week, no $200,000 consulting bill.
HubSpot to Strkr, 15-rep team
Half a day, same-day cutover.
A 15-rep team on HubSpot Professional runs the helper against a fresh export. The import finishes in two hours including engagement history. Reps log in after lunch, see every contact, every deal, every past email, and the day keeps going. The HubSpot subscription cancels the following Monday after a one-week overlap window. The time saved versus a vendor-led migration is a full week.
Dual-system period, 400-rep team
Six-week pilot, final cutover on schedule.
A 400-rep org cannot risk a weekend cutover. The Salesforce helper runs nightly, writing deltas into Strkr for a 40-rep pilot cohort. The pilot runs for six weeks while admins validate reports, custom object references, and ownership. At week seven, the sync becomes the final cutover and Salesforce goes read-only. The entire enterprise is on Strkr by week eight with zero lost deals in transition.
Strkr imports and exports ship on every paid tier. No professional-services line item.
Starter includes CSV and Excel import with the full field-mapping canvas, dedup rules, error reports, and manual export. Pro adds scheduled exports, SFTP and S3 destinations, and incremental mode. Scale and Enterprise unlock the Salesforce and HubSpot migration helpers plus GDPR subject-access and erasure workflows. The seat price is the data-mobility price. Open a trial and migrate your first object before lunch.
Does the Strkr importer handle Excel files, or do I have to convert everything to CSV?
Excel is a first-class input. The import engine reads .xlsx and .xls files directly, including multi-tab workbooks (each tab becomes its own job), merged cells, and the common date-format quirks Excel introduces. No convert-to-CSV step. The parser also handles the UTF-8 BOM Excel loves to insert on save, so files that opened fine in Excel do not fail on upload with a cryptic encoding error. CSV is of course also fully supported with delimiter autodetection, quote-style detection, and configurable encoding.
How does Strkr dedup work on a large import? Will I end up with 4,000 duplicate contacts?
Dedup runs before every write, not as a cleanup pass afterward. Admins pick a rule from the library (common defaults: email case-insensitive, phone normalized to E.164, company name plus domain) or build a new one in the UI without SQL. Each row runs through the rule in-flight. Matches either update the existing record, skip, or merge based on the per-rule setting. The default is match-and-update, which means re-importing the same CSV twice does not create duplicates. The audit log records every merge decision, and the job summary shows how many rows were new vs updated.
Can I migrate from Salesforce without buying a consulting engagement?
Yes. The Salesforce migration helper ships on Scale and Enterprise. Point it at a Salesforce export (via the connected app Strkr builds for read-only extract, or raw Data Loader CSVs) and the helper enumerates every standard and custom object, writes a default field mapping, preserves the Salesforce ID in a legacy_sf_id field, resolves owners by email, and brings over the full engagement history. Most teams under 100 reps complete the migration in a single weekend. Larger teams run an incremental sync for a pilot cohort over several weeks before cutting over. No external integrator required, no six-figure services contract.
What happens to the data in HubSpot when we migrate off?
That is up to you. The migration helper reads from HubSpot and writes into Strkr; it does not modify or delete anything in HubSpot. Teams typically run a one-week overlap period where Strkr is live and HubSpot is read-only, then cancel the HubSpot subscription at the end of the cycle. Historical engagement (notes, calls, emails, meetings) and legacy HubSpot IDs are preserved in Strkr so there is a persistent reconciliation path if you ever need to compare post-migration reports against the pre-migration shape. The HubSpot export file stays available for the lifetime of your HubSpot account.
How does GDPR data export work?
When a Subject Access Request lands, open the subject in Strkr and click "Export subject data." The engine walks every table that references the contact (activities, deals, notes, emails, call logs, custom-object child rows), writes a single JSON archive with every row, and logs the export in the audit trail with the admin who ran it. The archive format matches the shape regulators ask for under GDPR Article 15. For right-to-erasure requests under Article 17, click "Erase subject" and the engine deletes the contact, anonymizes referencing records with a tombstone, writes an audit entry, and emits a verification receipt your privacy team can hand to the regulator. Both flows ship on Scale and Enterprise.
Can I schedule exports to our data warehouse automatically?
Yes. Define an export schedule (filter, columns, destination) once and the engine writes to the configured S3 bucket or SFTP endpoint on your cadence: nightly, weekly, monthly, or custom cron. Incremental mode exports only records changed since the last successful run, which is the right shape for a warehouse ingesting upserts. Formats include CSV, Excel, JSON, and Parquet. The schedule has a status page showing last-run time, row count, and failures, and emits a Slack notification per run so the ops team sees the number without opening the UI. Scheduled exports ship on Pro, Scale, and Enterprise.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
We use cookies.
Essential cookies keep the site working. If you accept, we also enable Google Analytics
so we can see which pages help and which don't. Reject to opt out entirely. Details in our
Privacy Policy.
