Agree the file contract before accepting customer rows
Start with one supported file format and representative fictional records. Define the delimiter, encoding, headers, required values and the meaning of an empty cell. Test Danish names containing æ, ø and å, identifiers such as 0017, a quantity written as 1,5 and an ambiguous date such as 03/04/2026. These are interpretation examples, not a claim that every Danish file uses one convention. Show the agreed parsed value instead of silently guessing. W3C's tabular-data model distinguishes a cell's source string from its interpreted value and describes datatype and format metadata; a .csv extension alone is not a data contract.
Use delivered administration as adjacent evidence
Reveal combines a Next.js application, browser extension and administration for users, roles and activity, supported by Hono, Drizzle ORM and PostgreSQL. Appster combines catalogue administration, semantic app discovery and prerendered public pages using Next.js and Supabase. These published cases demonstrate connected application surfaces and maintained records. They do not establish a delivered customer-import queue, preview-to-commit contract, rollback tool or a particular isolation audit. A Danish SaaS engagement would define and test those requirements against its own data model and operator roles.
Make the preview a reviewable proposed change
Separate receiving and validating a file from applying its changes. For each logical record, show the source reference, interpreted fields, proposed action and validation result within the operator's permitted account. Counts should distinguish proposed creates, updates, unchanged records and rejected rows; quoted multiline cells must not become extra records merely because they occupy more lines. Tie approval to the specific file, mapping and reviewed data state. If the file or mapping changes, the old approval should not silently authorize the new result. Previewing a file should not send invitations or trigger downstream business actions.
Define identity, duplicate and overwrite rules explicitly
Agree how an imported item matches an existing record: for example, the account, source system and non-empty source identifier together. A display name alone should not be treated as that contract. Define duplicates within one file separately from a row that matches a record already in the product. PostgreSQL supports uniqueness across a group of columns, while its default unique-constraint behavior treats null values as distinct. That illustrates why missing identifiers need an explicit policy. Constraints help enforce the chosen model; they do not decide which operator corrections an update should preserve or prove whole-job replay is safe.
Choose the commit boundary and explain partial results
Decide whether an invalid row blocks the batch or whether an approved valid subset can proceed. In PostgreSQL, a transaction groups database steps into an all-or-nothing operation. That property applies to the actual transaction boundary, not automatically to an entire chunked import, a file store or an external notification. Define which related records must succeed together, what a committed chunk means and how completed changes are recorded. If partial application is allowed, show applied, unchanged, rejected and unresolved outcomes separately. A later failure must not be described as a full rollback when earlier chunks remain committed.
Recover an interrupted confirmation from recorded state
The operator may lose the response after a database commit. Agree how the product finds the existing job and its recorded result before offering another confirmation. Reuploading the same bytes is not, by itself, a complete replay policy: mappings, permissions and target records may have changed. Test an item edited by another operator between preview and commit, and decide whether to reject the stale proposal, request a fresh preview or follow an explicitly approved conflict rule. Rows absent from a later file should not silently imply deletion. Any deletion, reversal of committed changes or downstream notification needs its own approved behavior.
Use a small acceptance packet before importing real data
For fictional account D-7, prepare batch B-12 with an update to existing record C-001, an invalid new record C-002 and a valid new record C-003. Pick either whole-batch rejection or an explicitly approved valid subset before running the exercise. The worksheet makes the expected evidence reviewable without pretending there is one correct policy for every product. All checks below are proposed for a new engagement, not observed Reveal or Appster behavior.
Proposed import acceptance worksheet: fictional account D-7 and batch B-12
1. Interpret the source values
- Ask
- How do 0017, 1,5, 03/04/2026 and a multiline note appear in the preview?
- Evidence to request
- The original cell, the approved field mapping, the interpreted value and a clear error where interpretation is unresolved.
- Tradeoff to record
- A strict template reduces ambiguity; supporting several source formats creates more mappings to maintain.
2. Reject or approve a valid subset
- Ask
- What happens to C-001 and C-003 when C-002 is invalid?
- Evidence to request
- The agreed batch policy, the visible proposed counts and the actual records changed after confirmation.
- Tradeoff to record
- Whole-batch rejection simplifies review; partial acceptance needs an understandable correction and retry path.
3. Change a record after preview
- Ask
- What happens when another operator edits C-001 before B-12 is confirmed?
- Evidence to request
- The reviewed target version, the conflict outcome and any fresh approval required before an overwrite.
- Tradeoff to record
- Blocking stale proposals adds another review step but protects changes the preview did not include.
4. Lose the response after commit
- Ask
- What does the operator see after reconnecting, and what happens if confirmation is repeated?
- Evidence to request
- The existing job reference, committed outcomes and a demonstration that the agreed retry does not duplicate C-003 or reapply an unintended update.
- Tradeoff to record
- A durable result lookup needs explicit job state; a timeout alone cannot tell the operator whether changes committed.
5. Keep account and deletion boundaries
- Ask
- Can an operator from D-8 inspect or apply B-12, and does an omitted C-001 disappear on the next upload?
- Evidence to request
- The current operator's permitted result, no disclosure of D-7 rows to D-8, and the separately agreed handling of absent records.
- Tradeoff to record
- Import, replacement and deletion are different scopes; combining them requires clearer review and recovery rules.
Start with one account model and a bounded import
Bring a fictional sample file, the target record definition, one existing record and the operator roles. A first release can support one file contract, an approved create/update policy and the B-12 exercise above. Agree file and record limits, who resolves rejected rows and how temporary files and diagnostics are retained. Continuous source synchronization, whole-platform migration and customer exports are separate scopes. Curiosive's AI-accelerated development starts from $2,000 per month, with scope, capacity and operating responsibilities agreed in writing. Work is remote; no Danish office, completed Danish import system or compliance certification is claimed.
