Most VBCS apps start small — a couple of screens, a couple of business objects. The problems arrive when the app has grown to thirty screens and the business object model hasn’t kept pace. Here’s how to structure from the start.
Design the data model before the screens
It’s tempting to create business objects as you build screens — one form, one object. This produces objects that mirror UI forms instead of the actual data domain, which makes later changes expensive.
Before building your first page, map the entities and their relationships. An order management app has orders, order lines, customers, and products. Build those four objects first. Every screen is then a view over that model, not a duplicate of it.
Normalisation rules that actually matter in VBCS
Shared entities should be a single business object. If two screens both reference customer data, they should reference the same Customer business object — not two separate objects with the same fields. This sounds obvious but gets violated constantly when screens are built independently.
Keep calculated fields out of business objects. Total price = quantity × unit price is a calculation, not a field to persist. Compute it in a page function or an action chain, not stored in the business object. Stale calculated values are a persistent source of UI bugs.
REST-backed objects for Fusion data, local objects for UI state. REST-backed business objects sync with Fusion REST APIs and are authoritative. Local objects are fast and great for UI state — filters, selections, temporary input — but don’t confuse the two.
Naming conventions that survive team growth
Use entity-first naming: CustomerRecord, OrderLineItem, PaymentBatch. Avoid screen-first naming like OrderFormData — it implies the object belongs to one screen and makes it hard to reuse.
Fields: camelCase. Consistent casing prevents the subtle bugs caused by VBCS’s case-sensitive field references.
When to split a business object
Split when:
- An object has more than ~20 fields (usually a domain boundary)
- Two groups of fields are only ever accessed together on different screens
- You’re duplicating fields across objects — extract the shared group
Merge when you find yourself constantly fetching two objects together and mapping fields between them.