Data Model

A maintainable service can be changed with low risk. In the Designer, maintainability depends on the process model and data structures being easy to follow, custom code staying disciplined and small, and the people who didn't build the service being able to safely support or extend it later.

This page covers practical best practices for building strong data structures.

Use Strong Data Modeling

Stable services depend on stable data structures. Poor data models lead to fragile mappings, confusing validations, unstable interfaces, and hard-to-find runtime errors.

• Define data structures with clear business meaning, not just technical convenience.

• Use consistent field naming across forms, process data, mappings, and service interfaces (see also Naming Conventions).

• Differentiate required fields from optional ones explicitly - at least by their description.

• Initialize variables and attributes explicitly rather than relying on empty or default values — this avoids subtle bugs when a field is read before it's set. In the Designer, you can set default values on data model elements to initialize them.

• Keep interfaces as lean as possible and avoid passing oversized payloads when only a subset is needed.

• Version or evolve interfaces carefully when they are reused by multiple consumers.

• Once published, keep the service interface stable and clear — treat any change to a live interface as a deliberate decision, not a side effect.

• Introduce breaking interface changes only through semantic versioning (e.g. a new major version), never as a silent change to a live interface.

--> a clean, normalized, consistent structure

--> a denormalized, inconsistent structure with:

• customer fields duplicated instead of referencing Customer

• inconsistent property naming styles

Data Mapping Best Practices

• Validate inbound data before performing downstream processing (also see Validation and Error Handling for more).

• Use mapping diagrams, avoid Action Script or JavaScript for mappings (see Mapping Data Structures).

• Simplify data structures and only handle the properties you really need (see Handling Large Data Structures).

• Normalize data early if multiple sources provide different formats.

• Break up complex transformations into understandable intermediate steps.

Related Content