Current BPMS allow designers to specify processes in highly expressive languages supporting numerous control flow constructs, exceptions, compensation handling, complex predicates, policies, etc. The resulting specification can be anything from extremely flexible to extremely rigid, but there is an unfortunate trade-off: rigid specifications become a hindrance when unanticipated deviations occur, and too flexible specifications lack information about best practices and recommended order, because everything is possible. Both specifications are expressed exclusively in terms of hard constraints and even very clever specifications can only partially alleviate this. When the process designer writes the process as described by the business analyst, inevitably important intentional information is either abandoned or promoted to hard constraints. We argue that hard constraints are insufficient, and that they lead to either rigid (dictatorial) or support-less (anarchistic) process specifications. Soft constraints can make this trade-off less painful. If process designers can write soft constraints directly in the business process specification, the BPMS can accommodate unanticipated deviations while having enough information about best practices to guide the user through the process. As a consequence we suggest strongly to prefer soft constraints over hard constraints. Soft constraints can specify not only that some rules can be violated, but also by how much and how serious a concrete violation is. The BPMS should allow designers to easily specify soft goals and allow its users to immediately see the seriousness of their violations at runtime. We believe this provides a desirable combination of guidance and flexibility that is not otherwise attainable. To achieve this soft goals must be made explicit in the process model and be understood by the BPMS. We outline how this is done using a multi-criteria optimization problem formulation, and suggest some changes to the design methodology employed by process designers.