Production readiness checks

Before launching your application, use this guide to validate the business operations your team relies on. Each check explains the relevant Pikbase capabilities, a practical test, and the result to look for.

Run the checks with your application's schemas, permissions, workflows, and expected data volumes. The passing results below are acceptance criteria for your application, not a certification or a substitute for your service agreement.

Acceptance checklist

Check	What to test	Passing result
Transactions	Create an order, its items, and reserve stock; deliberately fail one step.	Everything rolls back—no partial order or incorrect stock.
Concurrent updates	Two users try to reserve the last available item simultaneously.	Only one succeeds; stock never becomes negative.
Permissions	Try accessing another organization's records and restricted financial fields through the API—not just the UI.	Unauthorized reads and writes are blocked server-side.
Audit history	Change a price, approve an order, and delete a contact.	Records show who did what and when; ordinary users cannot alter the history.
Reporting	Build pipeline totals, monthly sales by customer, and stock balances using realistic data volumes.	Correct results, acceptable performance, and usable exports.
Workflow reliability	Interrupt an approval process; retry the same request or webhook.	The process can recover without duplicate orders, stock movements, or notifications.
Backup and recovery	Restore a backup into a test environment, including attachments.	Recovery works, and the documented recovery time and potential data loss are acceptable.
Exit / portability	Export records, relationships, attachments, and schema definitions.	Data can be reconstructed outside Pikbase without losing essential meaning.
Public surveys	Submit without an employee account; attempt to read other responses or reuse a restricted invitation.	Submission works without exposing CRM data, with appropriate abuse protection.
Commercial terms	Confirm pricing, limits, hosting region, support, and what happens when the subscription ends.	Costs and responsibilities are clear and acceptable.

Prepare your test workspace

• Use an authorized, isolated test workspace with production-like definitions and policies. Use two ordinary users in different organizations, a restricted finance user, an administrator for read-back, and an anonymous browser session.
• Use synthetic or approved anonymized data at the expected production volume. Disable real email, payment, and other external delivery, or use provider sandboxes. Do not inject failures into production or restore over a live workspace.
• Get your workspace administrator's approval before deleting test data or restoring a backup. Agree on the test scope and cleanup procedure before you begin.
• Record the build/runtime version, schema and policy version, target environment, actor role, test time, request IDs, expected state, actual read-back, and cleanup outcome. Redact credentials and personal data from evidence.
• Give each check an owner and one result: Passed, Failed, Not tested, or Not applicable with a reason. Set performance and recovery budgets before running the tests. Unmeasured or undocumented requirements remain Not tested, not passed.

Transactions

How it works. Entity Service supports nested graph saves. Backend functions and synchronous workflows carry transaction context across related Entity Service writes. Errors before a commit checkpoint roll back pending database changes. A manual Commit changes checkpoint makes earlier changes durable; separate browser requests are not one transaction. See Transactions, triggers, and commit control.

What to test. Record the initial stock and relevant row counts. In your backend order operation, create an order and multiple items, reserve stock, then deliberately fail validation or persistence after each stage in separate runs. Read all affected entities through a fresh request after the failure; include trigger-created records. Run the same operation without the injected error as a positive control.

Passing result. Every failed run leaves no order, item, reservation, or stock movement from that attempt and restores the initial stock. The successful control creates one consistent order graph. Do not treat an error response alone as proof of rollback.

Implementation notes. Keep the order, items, and stock reservation within the same transaction boundary, and test any triggers or commit checkpoints your operation uses. Database rollback cannot retract an email or payment; validate those effects with the workflow reliability check.

Concurrent updates

How it works. Calculated saves such as _CALC([quantity] - 1) evaluate against the stored row inside the save transaction, avoiding an application-side read/modify/write race. That does not establish an atomic stock-availability check or prevent a negative result. See Atomic calculated saves.

Implementation notes. Do not use GsbSaveRequest.filters as a compare-and-set guarantee. Your stock operation must check availability and record the reservation atomically on the server. Confirm that the backend operation you use supports this condition before relying on it to prevent overselling. Reading stock and then saving a new value in a separate request is not sufficient.

What to test. Set available stock to one. Synchronize two different users' requests so both reserve that item at the same time. Repeat from a reset fixture, and retry each request with its original operation identity. Read stock, reservations, orders, and movements after every run.

Passing result. Exactly one reservation succeeds; the other receives an explicit unavailable/conflict outcome. Available stock is zero, never negative, with one effective reservation and no duplicate movement on retry.

Permissions

How it works. Entity Service is the authorization boundary. Definition and operation permissions, row-policy queryStr, and property permissions govern access. Property read permission also applies to filters, sorting, grouping, aggregates, includes, and subqueries—not only returned columns. See Data tables, policies, and search and Authentication and tenancy.

What to test. Call the API directly using each test user's own session. Attempt another organization's known record ID, a query without the UI's organization filter, changed tenant/organization selectors, create with a foreign organization, update, delete, nested saves, and relationship changes. Test both organizations within one workspace and separate workspaces where applicable. Try reading and writing restricted prices, margins, balances, and payment fields. Also reference those fields in filters, aggregates, sorts, includes, and exports. Include authorized controls.

Passing result. No unauthorized values, rows, aggregate information, or side effects are exposed. Direct mutations are denied and privileged read-back confirms no changes. Inaccessible property references are rejected, rather than becoming an inference path. Verify access through the API even when the UI already hides the record or column.

Implementation notes. Configure and test policies for every business definition and backend function your application exposes. A client-side guard or a tenant code supplied by the caller does not replace server-side authorization.

Audit history

How it works. GsbAuditLog provides operation records; isTracked enables automatic field history in GsbTrackVersion; isVersioned enables entity snapshots in GsbEntityVersion. These controls serve different purposes. Workflow step logs and GsbWfInstanceHistory provide execution and human-decision history. See Entity versioning and Workflows.

What to test. Enable the intended logging/tracking policy, then change a price, approve an order, and delete a contact as named test users. Read the corresponding history using an authorized reviewer. Attempt to create forged history, edit actor/time/value fields, or delete history through the API as an ordinary user. Repeat through any exposed bulk or backend-function path.

Passing result. History retains the actor, action, timestamp, affected record, and the relevant before/after values or approval decision. Contact deletion does not erase its required audit evidence. Ordinary-user tampering is denied and read-back proves the history is unchanged.

Implementation notes. Confirm history retention, deletion behavior, reviewer access, and privileged administrator capabilities against your audit requirements. Entity snapshots and change history are not, by themselves, a guarantee of cryptographic tamper protection or write-once storage.

Reporting

How it works. QueryParams supports grouped and aggregate queries, date modifiers, relationships, and aggregate filtering. Shared tables can download CSV or JSON for the current page or fetch all matching pages. That export is assembled in browser memory and does not provide a consistent snapshot across pages. See Build queries with QueryParams and Advanced and extreme queries.

What to test. Use the expected production row counts and relationship cardinality. Build pipeline totals by stage, monthly sales by customer, and stock balances from opening stock plus movements. Compare with independently calculated fixture totals. Include canceled/refunded orders, returns, empty groups, multiple currencies, date boundaries, and one-to-many joins that could double-count. Define the business timezone and currency conversion rules. Test as a restricted user as well as a reporting administrator.

Passing result. Totals and row counts match the reference calculations without unauthorized data. Record repeated cold/warm timings and p95 latency against the agreed budget, data volume, and concurrent load. Download and reopen exports; verify pagination, encoding, numeric/date precision, totals, and spreadsheet formula safety.

Implementation notes. Set a response-time and export-size budget that suits your users. Measure with realistic concurrent load, and account for browser memory limits and records changing between export pages.

Workflow reliability

How it works. Workflows persist instances, tasks, and execution history and support configured error/retry actions. Starting a workflow twice can create two instances, so each business operation needs an explicit strategy for handling duplicate requests. Workflow persistence alone does not guarantee exactly-once external delivery. See Workflows.

What to test. Interrupt the order approval before a commit, after a commit, and after an external provider accepts a request but before its response is recorded. Resume the persisted instance, retry the approval, and deliver the same signed webhook again, including simultaneous duplicates. Send an invalid signature, an expired delivery, and the same operation key with changed input as negative controls.

Passing result. The process reaches the intended state or an explicit recoverable failure. One logical action produces one order, reservation/movement, and notification; duplicate retries reuse the durable outcome rather than repeat effects. Verify provider delivery records as well as database rows. Invalid/replayed unauthorized events cannot advance the process, and conflicting reuse of an operation key is rejected.

Implementation notes. Each integration must verify the raw-body webhook signature and timestamp before dispatch, persist event/request identities, authorize resumed actions, and define retry limits and recovery ownership. An in-memory deduplication flag or query-before-insert is insufficient under restart or concurrency. Where an external effect cannot join the database transaction, verify durable dispatch and provider idempotency or a documented compensation/reconciliation procedure.

Backup and recovery

How it works. Tenant backup tooling can list restore points, start an on-demand backup, and restore a completed backup with destructive-operation confirmation. Availability and retention depend on the plan. Git, entity snapshots, tenant backups, and resource packs are different recovery layers. See Tenant backups and restore.

What to test. Obtain approval and confirm the supported procedure for restoring the chosen backup into an isolated test environment. The documented restore command replaces the selected tenant; do not use it to clone a production backup into another tenant without confirming the supported procedure with your administrator or Pikbase support. Never restore over production as a test. Include linked attachments with known checksums, definitions, relationships, permissions, functions, and paused workflows. Keep restored integrations isolated until an operator authorizes them.

Passing result. The application opens, records and relationships reconcile, and attachments download with matching bytes and access controls. Record backup capture time, last recovered write, restore start, and time the application becomes usable. Compare observed recovery duration with the agreed RTO (recovery time objective) and the lost-write interval with the RPO (recovery point objective).

Implementation notes. Check attachment coverage as part of the restore drill, not just the backup's Completed status. Agree on numerical recovery targets, backup frequency, retention, region, and restore responsibilities for your plan.

Exit / portability

How it works. Entity queries and table CSV/JSON exports expose records; definition APIs and Git source synchronization expose schema resources. Resource packs can carry selected infrastructure and data between Pikbase workspaces. A resource pack or backup alone is not an independently usable export outside Pikbase. See Backend source control with Git, Schema Manager API, and CI/CD, deployment, and seeds.

What to test. Export all authorized rows with stable IDs and reference/junction IDs, not only display labels or one page. Export definitions, property types, enum values, relationship cardinality, and the business meaning of calculated/localized fields. Download attachment bytes through authorized file access and produce a record-to-file manifest with filenames, sizes, and checksums. Coordinate a write freeze or supported snapshot procedure so paginated exports describe one consistent dataset.

Passing result. Reconstruct the data in a separate non-Pikbase database/application. Reconcile row counts, relationships, key financial totals, timestamps/timezones, decimals, enum meanings, multilingual values, and attachment checksums. Preserve a schema/data dictionary and identify any platform-specific rules that must be rewritten.

Implementation notes. Plan separate exports for records, schema resources, and attachment files. Browser exports do not bundle all of these into a complete migration package, and platform-specific policies and workflows need adaptation for another engine. Confirm export permissions, size/cost limits, and the export window after cancellation before planning a migration.

Public surveys

How it works. Public access lets you design submission experiences for people without an employee account. Your survey still needs a narrowly scoped backend submission operation, validation, and abuse protection. Public-access settings alone do not provide a complete survey or single-use invitation service; confirm those capabilities for your application before opening the form to respondents.

What to test. Submit from a clean browser with no employee session. Attempt to list or read other responses, retrieve linked CRM contacts, modify/delete responses, inject ownership or approval fields, and access attachments. For invitation-only surveys, test expired, altered, wrong-survey, already-used, and simultaneously reused invitations. Exercise rate and payload-size limits and any configured bot protection.

Passing result. A valid submission succeeds with a minimal receipt and no CRM data disclosure. Only allowed fields are accepted. Unauthorized read/write paths are blocked; single-use invitations are consumed atomically and cannot authorize another survey. Abuse is rejected without side effects, and responses do not reveal invitation secrets.

Implementation notes. Do not enable broad public CRUD on CRM or response definitions to make submission work. A dedicated backend submission operation must validate the public payload, scope authority, and apply abuse controls. Restricted invitation tokens need cryptographic randomness, hashed storage, expiry, and atomic consumption. If those capabilities are not available in your submission operation, resolve them before launching the survey. These controls must run on the server, not just in the form.

Commercial terms

How it works. Your offer and service agreement define the commercial terms for your workspace. Review them alongside the prices, subscriptions, entitlements, and usage information available in your account so your team understands both the cost and the operating responsibilities.

What to test. Confirm your offer and service terms cover:

• Currency, taxes, billing interval, introductory and renewal prices, seats/identity populations, workspace editions, included capacity, and chargeable add-ons.
• API/compute, workflow, database, file, and egress limits; measurement units; hard caps versus overages; alerts; and what is rejected or suspended when a limit is reached.
• Primary data, attachments, logs, and backup hosting regions; residency commitments; subprocessors; and data-processing/security responsibilities.
• Support hours/channels, incident severity, response targets versus resolution targets, availability commitments, exclusions, and escalation ownership.
• Renewal/cancellation dates, failed-payment grace, read/write behavior after termination, the export window and fees, retention/deletion of live data and backups, and confirmation of deletion. Include ownership and continued use of exported schema/source assets.

Passing result. Your team accepts the written terms, and the order, invoice, entitlements, and applicable usage charges agree with them. Confirm cancellation and end-of-service behavior with Pikbase support or an authorized test. Make sure you know when access ends, how long exports remain available, and when data is deleted.

Implementation notes. Prices, hosting-region commitments, support levels, retention, and recovery targets depend on your agreement. Contact Pikbase support to clarify any open questions before launch; this checklist does not change your service terms.