Business Logic | Scheer PAS Documentation

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 a clean business model.

Model Business Logic Deliberately

The Designer supports model-based implementation, so the process model itself becomes an important quality artifact. A clean model improves implementation speed, testing, onboarding, and long-term support.

Keep Process Flows Easy to Read

Model one clear responsibility per process or subprocess (see Modeling Roles).
Use subprocesses to encapsulate reusable or complex logic.
Keep diagram size manageable so readers can understand it without excessive scrolling.
Use gateways only where actual business decisions exist.
Label activities and decision paths with business-meaningful names. This makes error analysis through the logs much easier.

Good practice: If a model cannot be understood quickly by a teammate unfamiliar with the implementation details, simplify the structure before adding more logic.

Design for Change

Expect requirements to evolve and avoid hard-coding assumptions into model elements.
Centralize configurable values such as thresholds, partner identifiers, or routing logic where possible.
Isolate external system dependencies behind dedicated service logic or adapter-facing steps.
Apply established design and integration patterns (e.g. adapter, mapper) instead of ad hoc, one-off solutions. A good pattern is to encapsulate those in libraries that can be reused.