Glossary

Executable configuration

The materialization of the design on the platform: states, activities, forms, transitions, rules, related data, assignments and notifications.

The materialization of the design on the platform: states, activities, forms, transitions, rules, related data, assignments and notifications. Its governing rule is that every configuration decision must correspond to an architectural decision.

It is where the design is won or lost. Every decision not carried over from the design and taken here — a field made optional, a validation that got in the way — erodes the objective without anyone recording it as a change.

On this site: Dexon BPM platform →

Related terms

Architecture contract

The instrument governing implementation and deployment to ensure conformance with the defined architecture.

End-to-end test

A full validation that traverses the process from the portal request through to the report, covering execution, service levels, notifications, closure and survey.

Layout

The arrangement of fields through which an activity captures or queries data. It is not a data entry screen but a point of data governance: each field must correspond to a justified entity,…

Orchestration

The coordination of people, processes, data and information systems from the platform, so the process executes its design without requiring replacement of the existing technology ecosystem.

State and transition

How the executable process is implemented: states represent the situations a case can be in, and transitions the conditions allowing movement between them.