A row limit can make a database smaller. It cannot tell you whether the result still represents a useful customer, order, claim, or account.
That distinction matters in test data. Applications rarely work with isolated tables. A customer may depend on addresses, orders, payments, preferences, and support records. If a subset keeps some of those rows and loses the rest, the database may be technically valid but functionally useless.
Ark Business Objects describe the business shape that a test dataset must preserve.
What is a Business Object?
A Business Object is a reusable, versioned definition of a domain entity and the tables related to it.
For example, a Customer Business Object can define:
customersas its root table- orders and payments as related member tables
- country, status, or creation date as runtime parameters
- lookup tables that should be included
- optional tables that may be traversed when matching rows exist
- virtual foreign keys for relationships that are real in the application but missing from the database schema
Instead of asking Ark for “1,000 rows from each table,” a team can ask for “active customers created after this date, together with the records required to test them.”
How it works in Ark
Teams create or review a Business Object against a source profile. Ark can also use the schema graph and classification results to suggest likely root tables, member tables, parameters, and virtual relationships.
The published definition remains explicit and governed. When a test environment is requested, Ark compiles the selected Business Object with the supplied runtime values into an extraction plan. That plan determines the root filter, table roles, traversal rules, row limits, and relationships for that run.
Because definitions are versioned, a queued job cannot silently change when someone edits the Business Object later.
Masking stays governed by the source profile. Business Objects define which related records belong in the slice; the masking policy defines how sensitive values are protected.
What is it useful for?
Business Objects are especially useful when teams need:
- a small but complete customer journey for integration tests
- orders with their line items, payments, and refunds
- a claim with its policy, claimant, documents, and decisions
- tenant-specific datasets for SaaS testing
- repeatable domain slices across QA, CI, demos, and developer sandboxes
The practical benefit is consistency. Platform teams define the business scope once, security teams review it once, and developers reuse it with different parameters instead of maintaining separate extraction scripts.
Business Objects are the scope, not the scenario
A Business Object answers: Which business records should this environment contain?
It does not necessarily guarantee that the environment starts in a specific test state, such as an order ready to refund or an account locked after three failed attempts. That is where Ark Anchors™ fit: after Ark prepares the governed slice, Anchors can apply the small deterministic changes required by a test scenario.
Together, they turn subsetting from a generic sampling operation into a repeatable test-data workflow: Business Objects select the right business context; Anchors establish the exact starting state.